What can you do with this server?

This server provides an LLM agent-driven pipeline for film production, managing everything from initial planning and look development to rendering, quality control, and final assembly. It offers 14 tools across these areas: Plan & Lock * plan_shots: Convert a plain-language brief into a structured shot plan (type, move, duration, action, etc.) * lock_campaign: Define and lock the campaign's visual style (aspect ratio, film stock, color palette, elements, audio rules) for consistency across shots * palette_from_image: Extract a HEX palette from a moodboard or still * reference_prompt: Deconstruct a reference image into a ready-to-use prompt Generate & QC * gen_still: Generate a still image using a 6-layer prompt * qc_still: Automated style-drift QC scoring intent, look, and character (0–100) with a pass/fail verdict and fix suggestion * animate: Convert a still to video (img2vid) with optional direction or hero prompt * train_character: Create a character model from 3–5 photos * upscale: Final-polish upscaling for images or video Assemble & Utility * assemble: Build a cut manifest (shot order, durations, audio notes) * cut: Concatenate rendered clips into a single mp4 via ffmpeg * list_models: List available image/video models for routing * project_status: Report which pipeline stages (plan/lock/QC/manifest) are complete for a project Grounded Knowledge * craft_lookup: Query a cited craft knowledge base for expert advice on stocks, lenses, lighting, and prompt structure The server is LLM-provider agnostic (any OpenAI-compatible endpoint) and can be driven via direct tool calls, a web-based grading bay console, or an orchestration graph with retries and human gates.

Which integrations are available for this server?

Enables the MCP server to use OpenAI's models as the LLM backend for planning, QC, and assembly tools.

How do I use studio-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@studio-mcp Plan 5 shots for a coastal slow-burn film project 'MARÉA'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

studio-mcp

by rishbjain1

Overview Schema Related Servers Score Discussions

Python

Local

studio-mcp

The block-method film pipeline as agent-callable MCP tools.

An MCP server that lets an LLM agent drive a full brief → shots → render → QC → cut workflow by calling tools — instead of clicking through generation UIs by hand. Plan-then-generate, never reverse: every shot is planned (type, move, duration) before any pixel is made, and every still is QC'd against a locked look so the piece stays on-model.

MARÉA shot 1 — Higgsfield Soul Cinema, 21:9, QC-passed

Above: one shot from the brief "MARÉA — wordless coastal slow-burn" — planned, rendered on Higgsfield Soul Cinema at 21:9, and passed by the style-drift QC (intent 80 / look 84 / character 90). The agent re-rolls anything that fails.

Why

Single-tool MCP servers (one model, one call) are common. This is the layer above: it orchestrates across your generation stack with a block-method planner and a style-drift QC gate — the part nobody ships.

Related MCP server: uploop-vided MCP Server

Three ways to drive it

As an MCP server — connect to Claude Desktop / Claude Code and the LLM calls the 14 tools directly (stdio, or --transport streamable-http for web clients).
The web console — a cinematic "grading bay" UI over the server: browse instruments, invoke them from schema-driven forms, stream long renders, and brief the Director (an LLM that drives the instruments for you). Live demo: https://console-pied-eight.vercel.app · console/.
The orchestration graph — Planner → Generation ⇄ QC → Assembly as an agent graph with retries, human gates, and replayable per-run traces (studio_mcp/orchestration/).

Plus Langfuse tracing + an offline benchmark suite for evaluating the pipeline (eval/). CI runs tests on 3.10–3.12 and builds the package on every push.

Tools (14)

Plan & lock

Tool	What it does
`plan_shots(brief, project, n_shots)`	brief → block-method shot plan (type · move · duration · lighting · lens · time · hold · vibe)
`lock_campaign(project, aspect, camera, day_stock, hex_palette, elements, …)`	lock the look once — every shot's prompt inherits it
`palette_from_image(image)`	extract a HEX palette (dominant/secondary/accent) from a moodboard/still
`reference_prompt(reference, swap_subject)`	break a reference image into a ready 6-layer prompt (build from a ref)

Render & QC (via Higgsfield CLI)

Tool	What it does
`gen_still(project, shot_id, note, model)`	6-layer Soul prompt → render; `note` re-rolls with a QC fix; per-shot `model`
`qc_still(project, image, shot_id, threshold)`	vision style-drift QC vs shot intent + lock; pass/fail + fix_suggestion
`animate(project, shot_id, still, model, direct, hero)`	img2vid — `direct` = DP persona reads the frame & directs the move; `hero` = full Seedance timecoded/lip-sync prompt
`train_character(project, name, photos)`	soul-id self-clone from 3–5 photos
`upscale(media, kind, model)`	final-polish image/video upscale

Assemble & utility

Tool	What it does
`cut(project)`	ffmpeg-concat the rendered clips into one `<project>_cut.mp4` (offline, free)
`assemble(project, clips)`	cut manifest — order, durations, diegetic-audio notes
`list_models(kind)`	list available image/video models so an agent can route per shot
`project_status(project)`	what stages exist for a project

Ground (via creative-rag)

Tool	What it does
`craft_lookup(question, top_k)`	query the craft knowledge base for a grounded, cited, verified answer (stocks/lenses/lighting/prompt structure) — use while planning/locking so prompts trace to the real library, not generic guesses. Needs creative-rag running (`CRAG_URL`, default `http://127.0.0.1:8000`).

Integration — the studio trio

studio-mcp is one of three interlocking pieces; see INTEGRATION.md.

ai-content-pipeline skill — the method (block plan → lock → stills → animate → cut). It maps each stage to the studio-mcp tool that executes it and calls craft_lookup to ground prompts.
studio-mcp (this repo) — the tools that execute the method.
creative-rag — the cited craft KB behind craft_lookup.

Smoke-test the full chain (skill method → craft_lookup → creative-rag):

python scripts/smoke_chain.py        # needs creative-rag on :8000

Provider-agnostic

The LLM layer talks to any OpenAI-compatible endpoint — Anthropic, OpenRouter, OpenAI, or a local server — chosen entirely through env config. No provider is hard-coded.

cp .env.example .env   # set STUDIO_LLM_BASE_URL / _MODEL / _API_KEY

Install

python3 -m venv .venv && source .venv/bin/activate
pip install -e .

Run

studio-mcp        # stdio MCP server

{
  "mcpServers": {
    "studio": {
      "command": "/path/to/studio-mcp/.venv/bin/studio-mcp",
      "env": { "STUDIO_LLM_API_KEY": "sk-..." }
    }
  }
}

Example flow

plan_shots("MARÉA — wordless coastal slow-burn, 90s", project="marea")
lock_campaign("marea", aspect="21:9", day_stock="Kodak 500T, soft handheld",
              hex_palette=["#1b2a3a","#c8a15a"], elements=["the woman in grey"],
              audio="diegetic SFX only, no music")
# render a still (v1.1) → then:
qc_still("marea", image="assets/shot1.png", shot_id=1)   # pass/fail + fix
assemble("marea")                                         # cut manifest

State lives under STUDIO_ROOT (default ~/studio-projects/<project>/) as plain JSON — human-inspectable, and a clean contract a future console can read.

License

MIT

Available Tools

5 tools

assembleA

Build the cut manifest — shot order, durations, and audio notes.

Uses the plan for order/timing. If clips (e.g. [{"shot_id":1,"path":"..."}]) are provided (v1.1+), they are attached per shot. The actual NLE cut stays manual in v1; this is the edit blueprint.

Args: project: project name. clips: optional rendered-clip refs keyed by shot_id.

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes
`clips`	No

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses that the tool is a blueprint and the NLE cut is manual. It mentions optional clip attachment but does not describe side effects like overwriting or append behavior, permissions, or rate limits. The absence of destructive/read-only hints means the agent must infer behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with no wasted sentences. It front-loads the core purpose and includes a standard Args block. Minor improvement could be separating the background info from parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no output schema, the description covers purpose and parameters adequately. However, it does not describe the return value (the manifest structure), error conditions, or explicitly state that a plan must exist beforehand.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% coverage (no parameter descriptions), but the description adds meaning: 'project: project name' and 'clips: optional rendered-clip refs keyed by shot_id.' This clarifies the purpose of the clips parameter far beyond the schema's anyOf definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool builds a cut manifest with shot order, durations, and audio notes. This specific verb+resource combination distinguishes it from sibling tools like plan_shots or lock_campaign.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the tool uses a plan for order/timing and that clips are optional. It also clarifies that the actual NLE cut remains manual in v1, providing context on when this is an intermediate step. However, no explicit when-not-to-use or alternative tools are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lock_campaignA

Lock the campaign look so every shot stays on-model.

Args: project: project name. aspect: aspect ratio, e.g. "2.39:1" or "9:16". stock: film stock / look, e.g. "Kodak Vision3 500T, soft handheld". hex_palette: HEX colors defining the palette, e.g. ["#1b2a3a", "#c8a15a"]. elements: recurring elements/characters to keep consistent. audio: audio rule (default: diegetic SFX, no music).

ParametersJSON Schema

Name	Required	Default
`project`	Yes
`aspect`	Yes
`stock`	Yes
`hex_palette`	Yes
`elements`	Yes
`audio`	No	diegetic SFX only, no music; lip-sync where dialogue

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as idempotency, side effects (e.g., overwriting existing locks), or error conditions. The term 'lock' implies a mutation, but no further context is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a concise summary, followed by a structured list of arguments. It is not overly long, but slightly verbose with the 'Args:' block. Still, it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The parameter descriptions are thorough, but behavioral context (e.g., what happens on repeated calls, return value) is missing. With no output schema and no annotations, the description leaves gaps in understanding the tool's full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% coverage, so the description fully explains each parameter with examples (e.g., aspect ratio '2.39:1', hex palette example). This adds significant meaning beyond the schema's titles and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Lock the campaign look so every shot stays on-model.' This is a specific verb-resource combination that distinguishes it from sibling tools like 'assemble' or 'plan_shots'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for locking a look but provides no explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or alternative tools are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_shotsA

Turn a brief into a structured block-method shot plan.

Plans every shot (type, camera move, duration, action) before any pixel is generated. Saves to the project's plan.json and returns it.

Args: brief: plain-language description of the spot/scene. project: project name (scopes all state, e.g. "marea"). n_shots: target number of shots.

ParametersJSON Schema

Name	Required	Description	Default
`brief`	Yes
`project`	Yes
`n_shots`	No

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that the tool saves to plan.json and returns the plan. However, it does not mention idempotency, overwrite behavior, or required permissions. The description adds some context but lacks comprehensive behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with a clear summary sentence followed by details. The Args section is structured but could be more readable with bullet points. Overall, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters and no output schema, the description adequately covers purpose, parameters, and side effects. It explains what the tool does and returns. Lacks error handling details but sufficient for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description includes an Args section that explains each parameter's meaning: brief (plain-language description), project (scoping), n_shots (target number). This adds significant value beyond the schema's minimal titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: turning a brief into a structured block-method shot plan. It specifies actions like planning shots and saving to plan.json. This distinguishes it from sibling tools (assemble, lock_campaign, etc.) which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by saying 'before any pixel is generated', but does not explicitly state when to use this tool versus alternatives or provide any exclusions. There is no direct guidance on when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_statusA

Report what stages exist for a project (plan / lock / QC / manifest).

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. 'Report' implies a read-only operation, but the description does not disclose side effects, required permissions, or return format. Minimal but not misleading.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description hints at the return value (list of stages) but does not specify format (e.g., array, string) or additional context like stage order. Adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the 'project' parameter lacks any description in the schema. The tool description does not elaborate on the parameter beyond its name, failing to compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: reporting the stages (plan/lock/QC/manifest) for a project. The verb 'report' and specific stage names distinguish it from sibling action tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for checking stage progression but gives no explicit guidance on when to use this tool versus alternatives or when not to use it. Context from sibling names helps but is not provided in the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

qc_stillA

Style-drift QC on a generated still against the shot intent + locked look.

Vision model scores intent / look / character (0-100). Pass requires every score >= threshold. Saves the verdict and returns it. An agent re-rolls the still when pass is false, using fix_suggestion.

Args: project: project name. image: local path or http URL of the still to review. shot_id: which shot in plan.json this still is for. threshold: minimum passing score per dimension.

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes
`image`	Yes
`shot_id`	Yes
`threshold`	No

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions saving the verdict but does not specify where or if any state is modified, what authorization is needed, or whether the operation is read-only. This lack of detail leaves potential side effects ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loading the purpose and then providing necessary details in a structured bullet-style Args section. No extraneous sentences, though the formatting could be slightly more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no annotations, the description covers the key aspects: what it does, how scoring works, pass condition, and post-QC action (re-roll with fix_suggestion). It lacks detail on the return structure but is adequate for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite the input schema having 0% parameter descriptions, the description includes an Args section that explains each parameter (project, image, shot_id, threshold) with sufficient meaning. The default value for threshold is noted. This compensates for the schema's lack of documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs style-drift QC on a generated still, scoring intent/look/character on a 0-100 scale and returning a verdict. This verb-resource combination distinguishes it from sibling tools (assemble, lock_campaign, plan_shots, project_status), which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that an agent re-rolls the still when pass is false, using fix_suggestion, implying when to use this tool. Although it doesn't explicitly exclude usage scenarios or compare with alternatives, the context makes the appropriate use case clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 20, 2026
- First observedassemble
- First observedlock_campaign
- First observedplan_shots
- First observedproject_status
- First observedqc_still

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a distinct purpose: assemble builds the cut manifest, lock_campaign sets the visual look, plan_shots creates the shot plan, project_status reports stage completion, and qc_still performs quality control. There is no overlap or ambiguity between them.

Naming Consistency3/5

Tool names are not perfectly consistent: 'assemble' is a bare verb, while others follow verb_noun (lock_campaign, plan_shots) or noun_noun (project_status) patterns, and 'qc_still' uses an abbreviation. The naming is understandable but lacks a uniform convention.

Tool Count4/5

With 5 tools, the count is appropriate for the domain of film production planning and quality control. It covers the main workflow stages without being too heavy or too sparse, though a few more specialized tools could be added later.

Completeness4/5

The tool set covers the core stages: planning, look locking, assembly, QC, and status tracking. Notable gaps like actual rendering or exporting are intentionally omitted per v1 scope. The surface is fairly complete for its intended purpose.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Valmera — agentic AI video editorOAuth
io.valmera
Agentic video editing on real footage: cut, caption, reframe, score, and export at full quality.
Multimedia Processing Image & Video Processing Audio Processing
1
mcpcut
io.github.musyta-labs
A real timeline video editor for AI agents: journaled edits, FFmpeg/MLT rendering, exports
Multimedia Processing Image & Video Processing
1
studioOAuth
io.kaitoi
Build and run visual creative-production workflows from your AI agent.
AI & Machine Learning Design Tools App Automation
2
limnerOAuth
us.limner
AI visual generation agent: multi-pipeline rendering, prompt crafting, and image composition.
AI & Machine Learning Image & Video Processing
21

Related MCP Servers

Eversince MCP Serverofficial
Image & Video Processing Audio Processing AI & Machine Learning
eversince-ai
A
license
Not graded
quality
C
maintenance
A creative agent that plans and executes across image, video, and audio. Uses 30+ tools, orchestrates 20+ AI models, and does agentic timeline editing.
Updated 4 months ago (2026-04-25 13:20 UTC)
MIT
uploop-vided MCP Server
Multimedia Processing Image & Video Processing AI & Machine Learning
iuploop
F
license
Not graded
quality
A
maintenance
AI-native video composition and VFX engine that exposes its capabilities as MCP tools, enabling AI agents to act as directors and create videos programmatically.
Updated a month ago (2026-08-02 04:09 UTC)
-
manim-storyboard MCP Server
Image & Video Processing Testing & QA Tools Developer Tools
Tarunls
A
license
Not graded
quality
C
maintenance
Enables LLM agents to generate labeled contact sheets of Manim animations, scaffold storyboards from renders, and validate rendered steps against expected intents via MCP tools.
Updated 19 days ago (2026-08-18 02:13 UTC)
MIT
FaceLink
Design Tools App Automation Image & Video Processing
xuebazhou-blip
A
license
B
quality
B
maintenance
Enables LLMs to plan and stage editable Blender scene animations via a typed ShotSpec, with a safe stage/review/apply workflow, scene scanning, locomotion planning, and MCP integration for Codex/ChatGPT clients.
Updated 13 days ago (2026-08-24 16:46 UTC)
17
GPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rishbjain1/studio-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

studio-mcp

Why

Three ways to drive it

Tools (14)

Integration — the studio trio

Provider-agnostic

Install

Run

Example flow

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Eversince MCP Serverofficial

Latest Blog Posts

MCP directory API