The resolve-mcp server provides programmatic control over DaVinci Resolve Studio, enabling AI-driven editorial and media management tasks directly inside Resolve. Key capabilities:
Session & project management: Check connection state, Resolve version, current project/timeline (get_status); list available projects (list_projects); open a specific project by exact name (open_project); create .drp backup snapshots (snapshot_project).
Media pool operations: Import files and image sequences (import_media); list clips with offline state (list_media); inspect clip properties, metadata, markers, and time bounds (inspect_clip); batch update clip metadata (set_clip_metadata); organize media by creating nested bins and moving clips (organize_media); relink offline clips to new paths (relink_media).
Escape hatch: Run arbitrary DaVinci Resolve scripting‑API Python code (run_python) with resolve, project_manager, project, and timeline pre‑bound in the namespace, returning the last expression's value and captured stdout.
All tools return structured JSON and echo context (project/timeline) for confirmation.
Enables interaction with DaVinci Resolve Studio, providing tools to manage projects and timelines, create snapshots, and run Python scripting API commands for editorial automation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@resolve-mcp open project 'Docu' and snapshot before render"
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.
An MCP server that gives Claude Code hands inside DaVinci Resolve Studio — so the musical and editorial reasoning happens in Claude and the mechanical work happens in Resolve.
Build contract: issue #22 (closed — the build is complete).
v0.1.0 — the spec #22 build, complete: all four pillars (foundation, titling, the style-driven concert cut, the transcript-driven rough cut), 40 tools. The fake tier, mypy strict and ruff gate every PR; the live smoke tier last ran fully green against Resolve Studio on the Windows 11 box (32 passed, 6 skipped, 2026-08-11).
The tools below are the mechanics. How an edit session actually runs — what the
director hands over, the analysis prep, the mandatory self-reviews, the review rounds —
is process, and lives in docs/agents/concert.md (the concert
pillar) and docs/agents/rough-cut.md (the rough-cut
pillar); the taste the concert cut is measured against lives in styles/.
Tool | What it does |
| Connection state, Resolve version, current project + timeline, fps |
| Project names in the current database folder |
| Loads a project by name; the result echoes the new context |
| Writes an opaque |
| Imports files and image sequences into a bin, still-duration workaround applied |
| Summarises media pool clips, with offline state; spills big listings to disk |
| One clip in full: properties, metadata, audio mapping, markers, dual-time bounds |
| Batch metadata writes, each field routed by what the clip reports |
| Batch bin operations: create nested bins, move clips |
| Points offline clips at media that moved (folder relink or file replace) |
| Timelines with version, duration, fps and track stack; names the newest cut |
| One timeline at a chosen detail and range, in dual time; |
| Markers in record time, narrowed by colour and range |
| Batch marker writes; an existing marker is never overwritten unless asked |
| Writes a timeline out as OTIO, FCPXML or DRT |
| Materialises a new timeline from such a file — never overwrites one |
| The cut-file contract, its annotated example and the validation rules |
| Dry-runs a cut file: every error and warning at once, with fix hints |
| Builds a cut file into a fresh |
| Flips a built segment to one of its |
| Reads a cut file back as the words it will contain — the rough-cut self-review, run before every version ships |
| The titles-file contract, its annotated example and the validation rules |
| Dry-runs a titles file before the Titles track is touched |
| Places Text+ and PNG titles from |
| Reads the Titles track back: what each placed title says and which inputs it exposes |
| Fixes one placed title in place — its words or its exposed params, neighbours untouched |
| Grabs chosen moments on a clip as JPEGs (≤1568px) the agent reads off disk |
| Job: catalogs where a clip changes shot, gist inline and the full list on disk |
| Job: scores how much of an angle a near-field body blocks, and returns the windows to keep a cut out of |
| Job: scores an angle for sharpness, exposure, clipped highlights and stability, and returns the windows that miss the floors |
| GPU stem separation: mix → 4 stems, drums → kick/snare/toms/ride/crash, and on |
| Job: word-level transcript of a source clip or the timeline mix, with confidence and measured silence spans |
| Job: beats, downbeats and energy of a mix WAV |
| Job: tune boundaries from applause, gated by musical pulse; |
| Job: drum fills from the separated drum stems, confidence-gated |
| Job: phrase boundaries in the soloist's stem |
| Job: measures a cut against the music it was cut to — beat/transient offsets, bar position, tune, who's out front, per shot. Reports; never judges |
| The project's render presets, spelled the way |
| Renders a timeline or a range of one as a background job |
| Polls one background job: progress, result, or a structured failure |
| Lists jobs newest first — how a restarted session finds what it started |
| Escape hatch: runs scripting-API Python in the server process |
Bin paths are slash-separated from the media pool root (Concert/Angles) and
case-sensitive. A clip counts as offline when it has a file path that is not on
disk — Resolve's scripting API exposes no offline flag.
Interchange is the structural escape hatch. The scripting API cannot cut a transition,
so a dissolve is made by exporting the cut to OTIO, editing the transition into that
document, and importing it back. An .otio or .fcpxml import is given a name no timeline
in the project answers to — colliding names walk the <base> v<N> convention. A .drt is
Resolve's own document and accepts no import options at all, so it names its own timeline;
what holds there is the check on the way out. Either way the cut already in the project is
never the thing that gets written over.
Three fields read null on any timeline that is not the one open in Resolve: a track's
enabled and locked, and a shot's takes. Resolve answers those from editor state and
reports False/0 for every other timeline — no error to catch, just a plausible wrong
number — so the server reports "unknown" rather than passing it on. The currency block in
the reply names them, and make_current switches to the timeline for the read and switches
back when you want the real values. It is opt-in because the switch is visible in the
Resolve window. ADR 0004
has the sweep that established which getters this covers, and which are proven safe.
Editing is declarative and split across two files that never mention each other. The
cut file owns the cut and materialises as a new <name> v<N> timeline every build.
titles.json owns the titles, and apply_titles owns the topmost video track named
Titles — every apply clears that track whole and re-places from the file, so the same
file always produces the same track. Title positions are offsets from the blue marker
naming their song rather than timeline frames, which is what lets one titles file be
re-applied unchanged to every rebuild.
Each event picks one of two routes, and both land in the same pass. Text+ places an
instance of a GUI-authored template and writes its words and its fade into that instance's
Fusion comp — clip-level fades are not exposed to the scripting API at all, so the fade is
an opacity spline. PNG places a designed card exported to frames with alpha, its words
and its ramps already in the pixels; the server consumes cards, never generates them. A
card is imported once into 04_Assets/Text/<song> and found rather than re-imported on
every later apply, and gets the one-time out-point write that makes Resolve honour the
requested length instead of dropping every image at the default still duration.
A typo is the exception to all of that. edit_title writes new words or new exposed
params straight into one already-placed Text+ instance — no clear, no append, no rebuild —
and proves it reached only that one by reading every other title on the track before and
after the write. list_titles is how you find the title and see which Fusion input ids it
exposes, since a media-pool template has no comp to ask. The edit changes the timeline
and not titles.json, so the next apply_titles puts the old wording back: fix the file
too whenever the change is one worth keeping.
Heavy work runs as a background job: every starter replies {"job": record} immediately —
one shape whichever starter it was — get_job
polls it, and results are cached under the cache root against the media and the parameters,
so an unchanged rerun is instant. Job records live on disk, which is what lets list_jobs
recover after a restart — a job that was still running when the server went down comes back
failed with code job_interrupted. Audio acquisition is internal to the starters: a
timeline is exported through Resolve's render queue (the only route that captures the
timeline mix, 48 kHz/24-bit WAV), a single source clip is extracted with ffmpeg unless its
audio mapping says the audio is linked or offset away from the file.
Seeing the picture takes two routes, both reading the file on disk rather than rendering
anything. grab_frames is not a job — a seek and one frame is faster than a poll would be,
so it runs inline and hands back JPEG paths at or under the client's 1568px image cap, cached
against the media all the same. detect_scene_cuts decodes the whole clip, so it is a job:
the catalog of every cut and shot goes to the cache in dual-time JSON and only a gist (how
many cuts, the shot lengths, the first few times, the path) comes back inline.
analyze_occlusion answers the question that comes before either: is anyone's head, hat or
back between this camera and the stage? It samples a range at about a frame a second, scores
each sample on near-field blocking, and returns the windows — the stretches to keep a cut
out of — with the whole per-sample curve on disk behind them. analyze_quality is its
sibling and answers the other half: not whether something is in the way, but whether the
picture the camera got is worth cutting to. Four readings a sample — sharpness, exposure,
clipped highlights and stability — three floors that decide what is unusable, and windows in
the same shape, each saying which floor it missed. A steady pan scores as stable and a cut is
unmeasurable rather than unstable; the floors are calibrated on real deliverables
(docs/reference/image-quality-calibration.md). correlate_timeline takes a scan of a
rendered cut and puts the four readings on that cut's own shots.
Deliverables come off one timeline the same way: render_timeline renders with a preset
— what a preset renders was decided in the Deliver page and saved there, so the server
overrides only where the file goes and which frames it covers. Name none and the configured
default is used (H.265 Master, a Resolve built-in; RESOLVE_MCP_DEFAULT_RENDER_PRESET
points it elsewhere), and the job says which preset ran and whether it was the default or
explicit. An unknown name is refused with the list of names that exist, never swapped for a
near-enough preset. On top of that goes an optional half-open
[start, end) range in the timeline's own frames, the numbers inspect_timeline and
list_markers report. That is a per-song file out of a concert set. Without a target_dir
the file lands in the cache's renders folder, which the server replaces freely on a
re-render; a directory you name is yours, and a file already sitting there is refused until
you pass refresh.
Related MCP server: DaVinci MCP Professional
Windows 11, DaVinci Resolve Studio 21.0.3 (external scripting must be enabled: Preferences > System > General > External scripting using = Local)
CPython 3.12 x64 installed from python.org — not a uv-managed interpreter. See ADR 0001: the Resolve scripting library crashes the process outright on a standalone build, so the server refuses to attach on one. uv still manages the venv and the lockfile.
Resolve running, with a project open, before the first Resolve-touching tool call
ffmpeg on PATH for per-clip audio extraction, frame grabs and scene-cut detection
(RESOLVE_MCP_FFMPEG points at it elsewhere). Timeline-scope audio goes through Resolve's
own render queue and needs none. The analysis extra's torchcodec decodes through the
FFmpeg shared DLLs (the avcodec-*.dll family), which the static executable does not
carry — a separate install; winget install Gyan.FFmpeg.Shared puts them on PATH.
python-audio-separator on
PATH for separate_stems (pip install "audio-separator[gpu]", or
RESOLVE_MCP_AUDIO_SEPARATOR points at the executable). It is run as a subprocess, not
imported, so it can live in its own environment and its torch/CUDA stack never loads
into the server. The two model files download on first use.
uv sync --extra analysis for transcription and music analysis. The extra carries
faster-whisper and the CUDA 12 runtime it needs (~1.3 GiB): the transcriber takes the
GPU by default, and a runtime nobody installed is the one thing that breaks it. No
hand-installed wheels, no PATH set before launch — the server puts the venv's own copy
within reach. A box without an NVIDIA card still transcribes; set
RESOLVE_MCP_WHISPER_DEVICE=cpu and expect it to be slow. The extra also carries the
music stack (#37): beat_this (a git dependency — it has no PyPI release), torch,
torchcodec, soundfile and panns_inference. On Windows torch, torchaudio and
torchcodec come off the CUDA 13.0 wheel index rather than PyPI, which ships a CPU-only
Windows wheel (#245); a box with no NVIDIA card still installs and imports them, and
the beat and applause jobs warn that they are running on the CPU.
PANNs weights hand-placed in ~/panns_data/ — class_labels_indices.csv and
Cnn14_DecisionLevelMax.pth (327 MB), the two files panns_inference would fetch on
first use via os.system('wget …'), which Windows does not have. The two fetches it
would run: the weights from
https://zenodo.org/record/3987831/files/Cnn14_DecisionLevelMax_mAP%3D0.385.pth?download=1
(saved as Cnn14_DecisionLevelMax.pth) and the labels from
http://storage.googleapis.com/us_audioset/youtube_corpus/v1/csv/class_labels_indices.csv. No test tier can see this stack break —
ADR 0002 injects the models,
so the fakes stay green while real inference dies at import. The receipt that the
installed stack works is uv run pytest tests/test_live_analysis.py -m live.
uv venv --python "C:/Users/<you>/AppData/Local/Programs/Python/Python312/python.exe"
uv syncuv sync alone will pick a uv-managed interpreter, which runs the unit suite fine but
cannot attach to Resolve.
uv run resolve-mcpThe server speaks MCP over stdio and logs to stderr only. Register it with Claude Code:
claude mcp add resolve -- uv --directory C:/Users/Daniel/repos/resolve-mcp run resolve-mcpZero-config by default; every path has an environment override.
Variable | Default | Purpose |
|
| Scripting API root (holds |
|
| Scripting library |
|
| Cache root: snapshots, job records, cached results, acquired audio, grabbed frames, analysis catalogs, separated stems, model weights |
|
| ffmpeg executable used for per-clip audio extraction, frame grabs and scene-cut detection |
|
| python-audio-separator CLI used for stem separation |
|
| A separator whose torch is the CPU build ( |
|
| Pass one: the 4-stem model (vocals, drums, bass, other) |
|
| Pass two: the drum decomposition model (kick, snare, toms, ride, crash) |
|
| Render preset |
|
| Device faster-whisper transcribes on: |
|
| Precision: |
|
| Log level for the stderr logger |
| unset | Bypass the interpreter check (see ADR 0001) |
uv run pytest # unit suite — runs with Resolve closed, against the fake seam
uv run pytest -m live # live smoke tier — needs real Resolve running, on a python.org interpreter
uv run mypy # type check
uv run ruff check . # lintTests exercise external behaviour only: they call the tool functions in-process (no stdio transport) against a fake Resolve API object substituted at the connection singleton.
Report connection state, Resolve version, and the current project and timeline.
Call this first in a session, and again whenever you are unsure what Resolve has open. The result — like every result from this server — echoes context: connected, Resolve version, project, timeline and fps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 discloses the output behavior—echoing context with fields like connected, version, project, timeline, and fps. It does not explicitly state the tool is read-only, but the nature of a status report implies safe, non-mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, and each sentence adds value: what it reports, when to call it, and what the result contains. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple status tool with no parameters and no annotations. The description explains the purpose, usage timing, and output content. An output schema exists, but the description already covers the returned fields, so it is complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the input schema is empty. The description adds no parameter-level details, but the baseline for 0 params is 4, and the description sufficiently explains what the tool reports.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' and identifies the resource: connection state, Resolve version, project, and timeline. This clearly distinguishes it from sibling tools like list_projects and open_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first in a session, and again whenever you are unsure what Resolve has open.' This provides clear when-to-use context, though it does not mention when not to use it or alternatives, which is less critical for a status check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the project names in Resolve's current database folder.
Use it to find the exact name to hand to open_project — names must match exactly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that it lists names from the current database folder and adds value by noting the exact-match requirement. The verb 'list' implies read-only, but it does not explicitly state what happens if no projects exist or whether it might be slow. Still, it provides sufficient transparency for this simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences convey the purpose and key usage guidance without any wasted words. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no complex behavior) and the presence of an output schema, the description fully covers what the agent needs: purpose and how to use it in context with open_project. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. No parameter descriptions are needed, and the description adds no irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists project names in Resolve's current database folder, using the specific verb 'List' with a defined resource. This distinguishes it from siblings like open_project, which performs a different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use it: to find the exact name to pass to open_project, emphasizing exact match. This provides clear contextual guidance and implies not using it for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the named project, making it the one every later tool call acts on.
The name must match exactly; list_projects shows what is available. The result echoes the new context, so you can confirm the switch landed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It clearly discloses the key side effect (all later calls act on the opened project) and the output behavior (echoes the new context for confirmation). It does not mention error behavior or reversibility, but the most critical behavioral trait is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, prerequisites, and output behavior with no filler. The main action is front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter context-switching tool, the description covers the use case, how to get valid input, and how to verify success. An output schema exists, so return details need not be spelled out. The description is sufficient without being verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'name' as a required string with no description. The description adds essential semantics: the name must match exactly, and list_projects provides the available names. This fully compensates for the 0% schema coverage and makes the parameter's meaning unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('named project') and immediately clarifies the tool's actual function: making the project the target of every later tool call. This distinguishes it from siblings like list_projects and snapshot_project, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the name must match exactly and points to list_projects as the way to discover valid names, providing clear prerequisite context. It does not explicitly contrast with other sibling tools, but the context-switching purpose is clear enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run DaVinci Resolve scripting-API Python in the server process.
Prefer the real tools: they wrap known API footguns, echo context, and return structured results. Reach for this only where no tool fits — an API corner the catalog does not cover yet, or a one-off inspection.
The namespace has resolve, project_manager, project and timeline pre-bound.
The returned value is the trailing expression, or a result variable if you set one;
stdout is captured and returned alongside it. Long values are truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pre-bound namespace objects, return value semantics (trailing expression or result variable), stdout capture, and truncation. However, it does not warn about the potential side effects of running arbitrary code in the server process, which is a significant omission for a code execution tool. With no annotations, the description carries full burden, so this gap caps the score at 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful paragraphs with no filler. Purpose, usage guidance, and behavioral details are each covered efficiently, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, return behavior, and truncation, but omits error handling (e.g., what happens on exceptions), state persistence across calls, and side-effect warnings. For a complex and potentially destructive tool like arbitrary code execution, these are notable gaps, making the description not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'code' has no schema description (0% coverage). The description adds context by explaining the execution environment (pre-bound namespace) and return behavior, but it does not explicitly describe what the code parameter should contain in terms of format, examples, or constraints. It adds some meaning but not enough to fully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run DaVinci Resolve scripting-API Python in the server process' with a specific verb and resource. It also distinguishes itself from sibling project management tools by positioning as a fallback for API corners not covered by the catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Prefer the real tools' and 'Reach for this only where no tool fits.' Specific use cases are named—'an API corner the catalog does not cover yet, or a one-off inspection'—clearly delineating when to use this vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write an opaque .drp backup of the open project, and return where it landed.
Take a snapshot before any big operation — a build, a bulk media change, a risky escape-hatch script — so a mistake is a restore rather than a rebuild. Without a path, the snapshot goes to a timestamped file in the cache directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: the backup is opaque, and without a path it goes to a timestamped file in the cache directory. It does not cover potential errors or side effects, but the main behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-sentence action followed by a usage scenario paragraph. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one optional param), the description adequately covers purpose, default behavior, and usage scenarios. An output schema exists, so detailed return value explanation is not required. It lacks information about failure modes but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter, but the description explains that without a path, the snapshot goes to a timestamped cache file, giving meaning to the optional path parameter. It could be more explicit about what path should be, but it effectively compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an opaque .drp backup of the open project and returns the location. It distinguishes itself from siblings like list_projects and open_project by focusing on creating a backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use: 'before any big operation' such as builds, bulk media changes, or risky scripts. It does not explicitly mention when not to use or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_statuslist_projectsopen_projectrun_pythonsnapshot_projectEach tool has a clearly distinct purpose: listing projects, opening a project, snapshotting, running arbitrary Python, and reporting status. Even run_python is explicitly positioned as an escape hatch, not as a competing operation.
All five tools follow a consistent verb_noun pattern in snake_case (list_projects, open_project, snapshot_project, run_python, get_status), making the action and target immediately clear.
Five tools is a well-scoped count for a focused server. Each tool covers a core need without redundancy, and the number fits comfortably within the typical 3-15 range.
The server covers project listing, opening, status, and backups, with run_python filling gaps for operations like project creation or timeline edits. The absence of create/delete project tools is a minor gap, but the deliberate escape hatch keeps the server usable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielbaldwin47/resolve-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
