Codex DaVinci Resolve MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between resolve_get_state and resolve_health, both providing status information. Descriptions help differentiate them.
Naming Consistency4/5
All tools use the 'resolve_' prefix and mostly follow verb_noun naming (e.g., resolve_add_marker). However, 'resolve_production_preflight' is a noun phrase rather than a verb, breaking the pattern slightly.
Tool Count4/5
27 tools is on the higher side but appropriate for a comprehensive video editing server covering project, timeline, media, color, and render operations.
Completeness4/5
Core workflows are covered (project CRUD, timeline editing, media import, rendering). Missing tools for deleting projects or timelines, and audio-specific operations, but the surface is largely complete for editorial tasks.
Average 3.4/5 across 27 of 27 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on July 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as side effects, required permissions, or whether the operation is reversible. Annotations only indicate it is not read-only, not idempotent, and not destructive, but the description adds no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, which is concise but lacks structure. It does not break down information into sections or use lists, but it is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 and an output schema, the description is insufficient. It omits details on how to specify the timeline, the meaning of idempotency_key, and what the return value contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the individual parameters. It only hints at media IDs and names, but fails to clarify timeline_id, timeline_name, idempotency_key, or the structure of the clips array.
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 appends or precisely places clips on a timeline using media IDs, names, or allowed paths. This distinguishes it from sibling tools like resolve_add_marker or resolve_create_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, preferred use cases, or when not to use it, despite having many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description's 'insert' is consistent but adds no additional behavioral context. It does not disclose any side effects, permissions required, or other traits beyond what annotations provide.
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 a single sentence that front-loads the core action. It is concise and avoids unnecessary words, though it could be structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no schema descriptions, the description is too brief. It does not explain how to use timeline identifiers, the text parameter, or idempotency key. The output schema exists but the description does not reference it.
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%, so the description must compensate. It only explains the 'kind' and 'timecode' parameters, leaving out text, template, timeline_id, timeline_name, and idempotency_key. This is insufficient for a 7-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inserts a title (standard or Fusion) at a timecode. It specifies the verb 'insert' and the resource 'title', distinguishing between standard and Fusion types. However, it does not differentiate from sibling tools that might also insert media, but no sibling directly inserts titles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or related tools. The agent is left without context to decide between this and other resolve tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the tool is non-read-only and non-destructive, consistent with annotations, but provides no additional behavioral details such as error conditions when a track already exists, cost, or rate limits. The description adds little beyond the annotations themselves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks sufficient structure. While it efficiently states the core purpose, it omits critical details, making it borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters with no schema descriptions and a complex domain (timeline management), the description is too sparse. It fails to explain parameter interactions or usage context, leaving significant gaps for an AI agent.
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?
With 0% schema description coverage, the description should compensate by explaining parameters. However, it only mentions 'name' as optional and ignores other key parameters like index, audio_type, timeline_id, timeline_name, and idempotency_key, leaving the agent without necessary context.
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 action ('Add'), the resource ('track'), and specifies the types it supports ('video, audio, or subtitle'), which effectively distinguishes it from sibling tools like resolve_append_clips or resolve_set_track_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites, or alternatives. For example, it does not mention that a timeline must exist, nor does it contrast with other track-related tools like resolve_set_track_state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, destructiveHint=false. The description adds that only 'allowlisted' properties are editable, which is useful behavioral context. However, it does not disclose side effects, required permissions, or what happens with invalid edits, so the added value is limited.
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 a single sentence, concise and front-loaded with the verb. However, it could be structured to separate the two modes (properties vs. enable/name) for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested objects) and the presence of an output schema, the description lacks important context such as how to identify items, error handling, return values, or the fact that timeline_id or timeline_name are optional. It is not complete enough for an agent to use correctly.
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 coverage is 0% and the description does not explain any parameter meaning. While it hints at editing properties or enable/name, it does not map to the specific parameters like edits, timeline_id, or the nested ItemEdit fields. The complex structure is left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits 'allowlisted transform/crop/composite properties or enable/name timeline items', providing a specific verb and resource. It distinguishes from sibling tools like resolve_add_track or resolve_append_clips by focusing on editing existing items, but the term 'allowlisted' is somewhat ambiguous and not explicitly contrasted with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or compare with sibling tools such as resolve_set_track_state or resolve_add_marker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations lack behavioral hints; description does not disclose side effects, permissions, or behavior for duplicate files. The idempotency_key parameter is ignored.
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?
One sentence with no extraneous words, but lacks necessary detail for proper usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits details on input formats, error handling, and prerequisites for media roots, making it incomplete for a tool with 3 parameters.
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 coverage is 0%; description vaguely mentions bin_name but not paths format or idempotency_key, leaving agents to infer parameter usage.
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 imports files from configured media roots into a media-pool bin, distinguishing it from sibling tools like resolve_verify_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the source timeline is preserved, which aligns with the non-destructive annotation. However, it does not cover other behavioral aspects like required permissions or state changes. The annotations already indicate non-readonly and non-destructive, so the description adds moderate value.
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 redundant information. Every word is necessary and contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no schema description coverage, and an output schema, the description is too sparse. It does not explain return values, parameter interactions, or edge cases, leaving significant gaps for proper tool invocation.
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%, and the description only hints at a version-named revision (new_name) but does not explain the other four parameters like timeline_id, make_current, etc. This leaves the agent with minimal guidance on how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'saved, version-named timeline revision' while specifying that the source is preserved. It distinguishes this tool from siblings like resolve_create_timeline, which creates a new timeline without duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., resolve_create_timeline). It does not mention prerequisites, context, or what to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (idempotentHint true, destructiveHint false) indicate safe modifications. The description adds specific actions (rename, enable, lock) not fully captured by annotations. However, it doesn't disclose potential side effects (e.g., behavior if track is already locked) or success conditions.
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?
A single, front-loaded sentence with no redundant words. It efficiently communicates the core actions without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no parameter descriptions, the description is too brief to guide an agent. It omits explanation of required identifiers (track_type, track_index) and optional timeline specifiers, as well as how multiple actions can be combined. The output schema exists but is not referenced.
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 coverage is 0%, so the description must compensate. It hints at parameters name (rename), locked (lock/unlock), and enabled (enable/disable) but does not map actions to parameters or explain identification fields (track_type, track_index, timeline_id, timeline_name) or their role. This leaves significant ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs (rename, enable/disable, lock/unlock) and identifies the resource as 'existing timeline track'. It clearly states the tool's purpose and distinguishes it from siblings like resolve_add_track which adds new tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., resolve_add_track for new tracks) or conditions for use (e.g., track must exist, required identification parameters).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the marker is placed at an exact frame and custom data is private and optional. Annotations are minimal (all false), so description adds some value but does not cover behavior on duplicate frames, error conditions, or idempotency implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (12 words) and front-loaded with the core action, but for a 9-parameter tool it is overly terse and could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (9) with no schema descriptions, and no guidance on output or error cases, the description is insufficient. Sibling tools are listed but not compared. The presence of an output schema is not leveraged.
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%, so the description must fully compensate. It only hints at 'custom_data' (private/optional) but ignores 8 other parameters including required 'frame'. This is inadequate.
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 action (add a timeline marker) and key constraint (at exact frame) with optional custom data. It is distinct from sibling tools like resolve_add_track or resolve_append_clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description does not help the agent decide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal behavior hints (readOnlyHint=false, destructiveHint=false). The description adds that it creates a new file without overwriting, but lacks details on authorization, error handling, or what 'verified' and 'private' mean operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 13-word sentence, concise but without structure or separation of concerns. It is not verbose but lacks effectiveness in conveying information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and an output schema, the description is too sparse. It does not explain what a DRP backup is, how parameters affect behavior, or provide context on file location/naming, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but does not explain any of the three parameters (output_file, idempotency_key, with_stills_and_luts). It only mentions 'backup' generically, adding no semantic value beyond the schema.
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 uses specific verbs 'Save and export' and identifies the resource as a 'verified, private DRP backup'. It also adds a constraint ('without overwriting an existing file'), which clearly differentiates it from siblings like 'resolve_save_project' and 'resolve_export_timeline'.
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 the tool is for creating backups without overwriting, but it does not explicitly state when to use it versus alternatives or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false; the description adds minimal behavioral detail beyond stating export to an allowed path, without discussing side effects like file overwrites or path restrictions.
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 a single concise sentence, front-loaded with the main action. However, for a tool with five parameters, it could benefit from more structure like bullet points or brief parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical context: how to specify the timeline, allowed file paths, export subtypes, and their meanings. This is insufficient for a five-parameter tool.
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?
With 0% schema description coverage, the description adds no parameter-specific meaning. It does not explain the role of export_type, output_file, timeline_id/timeline_name, or export_subtype, relying solely on schema titles and enums.
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 verb 'Export' and the resource 'selected timeline to an allowed interchange file path', which distinguishes it from sibling tools like resolve_queue_render or resolve_export_project_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or recommended scenarios. The description is a single sentence without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only (readOnlyHint false) and is idempotent (idempotentHint true). The description adds that saving happens 'by default' and is controlled by the save_current parameter. This clarifies the side effect but does not disclose failure cases or authorization needs.
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 a single concise sentence with no extraneous words. It is front-loaded with the main action. Slightly more structure could help (e.g., separating the two steps), but it earns its length.
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 tool with an output schema (not shown), the description explains the basic operation. However, missing details like error handling (if project not found), prerequisites (project must exist), and the effect of save_current=false limit completeness. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'save current project by default' which correlates with the save_current parameter's default value. However, it gives no detail about the required 'name' parameter (e.g., must be an existing project). This adds partial value but leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves the current project and then opens an existing named project. It distinguishes from sibling tools like resolve_create_project (create new) and resolve_save_project (only save) by combining both actions. The verb 'open' and resource 'project' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as resolve_create_project or resolve_save_project. The description only states what it does, not when to choose it. An agent would have to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnlyHint false, no safety hints), so the description should compensate. It confirms a mutation but does not disclose side effects, prerequisites (e.g., open project), or idempotency behavior. The term 'strictly located' hints at precise placement but lacks detail.
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 a single sentence with no waste, but it is overly brief. It could be expanded without losing conciseness to cover key parameters and usage context.
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 output schema exists and siblings are listed, the description is moderately complete for a create tool. However, it lacks detail on when to use versus alternatives and does not explain the return value, relying on the output schema.
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?
With 0% schema description coverage, the description must explain parameters. It only mentions 'clips with frame ranges', ignoring 'name', 'make_current', 'idempotency_key', and the full ClipSpec structure. The meaning of 'strictly located clips' is vague and does not clarify the many ClipSpec fields.
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 creates a timeline, with optional clip placement using frame ranges. It distinguishes from siblings like resolve_append_clips (which appends to existing) and resolve_duplicate_timeline (which duplicates), making the purpose specific and unambiguous.
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 when creating a new timeline with or without clips, but it does not explicitly state when to use this over siblings (e.g., resolve_append_clips for adding clips to existing timelines). No exclusions or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool returns a one-use token with a five-minute expiry, which adds value beyond the annotations. The annotations (readOnlyHint=true, destructiveHint=false) align with the description of a preview/validation operation.
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 a single clear sentence with no extraneous words. It is appropriately concise but could be slightly improved by structuring the key outcomes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a required enum action and a complex arguments object), the description is insufficient. It lacks details on available actions, required argument fields, and the output format, despite an output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage (0%), yet the tool description provides no explanation of the 'action' enum or the 'arguments' object fields. The agent is left without any guidance on parameter values.
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: 'Validate and preview an exact delete request' and what it returns: 'a one-use five-minute token'. It distinguishes from sibling 'resolve_execute_destructive_action' which presumably uses the token.
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 it should be used before a destructive action, but does not explicitly mention when to use it vs alternatives, nor provides any 'when-not-to-use' guidance. With many sibling tools, more explicit context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'without changing jobs', which reinforces but does not add new behavioral traits beyond what annotations provide.
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?
Description is a single, concise sentence that clearly states the tool's purpose and non-destructive nature. No unnecessary words or repetition.
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 simple tool with one optional parameter and an output schema, the description is adequate but lacks details about the return format or what status/progress information is provided. The output schema exists, so return values are documented elsewhere, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter (job_ids) with 0% schema description coverage, meaning the schema provides no textual description. The tool description also fails to explain the parameter's meaning, purpose, or expected format, leaving the agent without guidance on how to use it.
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?
Description uses specific verb 'Inspect' and resource 'render queue records and authoritative status/progress', making purpose clear. It explicitly states non-modification ('without changing jobs'), distinguishing it from sibling tools like resolve_queue_render or resolve_configure_render.
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?
Description implies usage as a read-only inspection tool but does not explicitly state when to use this tool versus alternatives (e.g., resolve_queue_render for starting renders). No exclusions or usage conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds the behavioral detail 'then save', which is not captured by annotations. However, it does not disclose behavior on invalid settings (e.g., rejection vs. silent failure) or whether settings are applied immediately.
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 concise sentence, front-loaded with the verb 'Apply' and resource 'settings'. Every word adds value; no redundancy.
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 presence of an output schema (not shown) and the tool's simplicity (one parameter), the description adequately covers main functionality and key behavioral detail (save). It could be more complete by mentioning validation of settings, but it is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the burden is on the description. It provides examples of valid keys ('frame rate', 'resolution') and hints at an allowlist. This adds meaning beyond the generic schema (object with any properties). However, it does not specify value formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'apply' and the resource 'allowlisted project settings', giving examples like 'frame rate and resolution'. It distinguishes from siblings such as resolve_save_project (save only) and resolve_configure_render (render settings). However, it could be more precise about what 'allowlisted' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It does not mention prerequisites, context for use, or situations to avoid. The agent is left to infer from the name and examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description ('configure a render') aligns with idempotent configuration and non-destructiveness but adds no further behavioral context beyond the annotations.
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 a single concise sentence with no wasted words. However, given the tool's complexity, a bit more detail could be added without harming conciseness.
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 tool has an output schema (not shown) which partially reduces the burden, but the description omits what the tool returns. It also lacks guidance on the complex 'settings' parameter. Overall, it is adequate but not comprehensive.
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%. The description only mentions 'format/codec values and an allowed output directory', covering 3 of 7 parameters. It provides no details on preset, settings (which has many sub-properties), custom_name, or mode.
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 it configures a render using discovered format/codec values and an output directory. This distinguishes it from sibling tools like resolve_queue_render and resolve_get_render_options, making its purpose specific and actionable.
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 after discovering format/codec values (likely via resolve_get_render_options) but does not explicitly state when to use this tool vs alternatives, nor provide any when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description aligns with these. It adds value by listing the specific elements inspected (project, timelines, tracks, items, markers, media), which is helpful beyond the annotation flags.
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 a single sentence, concise and front-loaded with the key action. However, it could be more structured to include parameter hints or usage context.
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 output schema exists (not shown), the description need not detail return values. It covers the general scope but lacks parameter semantics, which is a gap for an otherwise complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The description fails to explain any parameters (max_items, include_media, include_timeline_items), leaving the agent without guidance on their meaning or impact.
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 'Inspect the current project, timelines, tracks, items, markers, and optionally media,' which is a specific verb ('Inspect') and resource (project state). It distinguishes from mutation siblings like resolve_add_marker and other read tools like resolve_health.
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?
No explicit guidelines on when to use this tool vs alternatives. The read-only nature is implied by annotations and sibling tool names (mostly mutators), but no direct comparison or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (idempotentHint=true, readOnlyHint=false, destructiveHint=false) are consistent. Description adds detail about one-based color node indexing and allowed LUT constraint, providing context beyond annotations.
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?
Single sentence of 14 words is concise and front-loaded. However, the brevity sacrifices essential details that could be included without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical context: no explanation of output, error handling, prerequisites (e.g., timeline open, items selected), or behavior when item_ids or node_index are invalid. Has output schema but description does not hint at return format.
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%, so description must compensate. Only lut_path and node_index are partially explained via the description; item_ids, timeline_id, and timeline_name are not described. Important parameters lack semantic context.
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?
Description clearly states verb 'Apply', resource 'allowed local LUT file', and target 'to a one-based color node on selected timeline items'. This specific verb+resource+target distinguishes from sibling tools like resolve_edit_items or resolve_configure_render.
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?
Implies usage context (items must be selected, LUT must be allowed) but does not explicitly state when to use this tool vs alternatives. No exclusions or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (all false), the description reveals that the tool creates and opens a project and optionally applies settings. However, it does not clarify what 'allowlisted' means or disclose side effects like overwriting or conflict handling.
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?
A single sentence that succinctly conveys the core action without extraneous words. Well front-loaded with the main 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?
While an output schema exists, the description omits important context such as behavior when a project already exists, what 'allowlisted' settings are, and prerequisites. Adequate for a simple tool but lacking for its complexity (5 parameters, nuanced behaviors).
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?
With 0% schema description coverage, the description only hints at the 'settings' parameter via 'optionally applying allowlisted timeline/color settings'. It does not explain 'name', 'media_location', 'reuse_existing', or 'idempotency_key', leaving most parameters ambiguous.
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?
Clearly states the verb 'Create and open' and resource 'project', distinguishing it from sibling tools like resolve_open_project. Mentions optional settings, which adds specificity.
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?
Implies usage for creating and opening projects, and the optional settings hint at customization, but no explicit when-to-use or when-not-to-use versus alternatives like resolve_open_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly, leaving description to carry behavioral burden. Description discloses that it adds a job and optionally starts it, which is truthful. However, it does not elaborate on side effects like state changes or behavior of repeated calls, but overall adequately describes the action.
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?
Single sentence, no wasted words, front-loaded with the core action. Every word serves a 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 an output schema exists, return values are covered. However, the description lacks context about prerequisites (e.g., having a project open or render settings configured) and does not explain the idempotency_key field. It is adequate but not 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%, so description must compensate. Only the 'start' parameter is partially explained ('optionally start only that job'), but 'idempotency_key' is not addressed. The description adds minimal value beyond the schema.
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 adds a render job from current settings and optionally starts it, using specific verb 'add' and resource 'render job'. It distinguishes from sibling tools like resolve_configure_render (configuration) and resolve_render_status (status check).
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 after configuring render settings but does not explicitly state when to use this tool versus alternatives like resolve_configure_render or resolve_render_status. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions verification but doesn't elaborate on failure behavior or state changes beyond what annotations already convey (idempotentHint=true). No additional context beyond annotations.
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 extremely concise with no wasted words. It front-loads the core action and verification.
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 zero parameters, annotations, and an existing output schema, the description covers the essential behavior. Missing specifics about failure modes, but acceptable for a simple save action.
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?
No parameters exist, so the description doesn't need to add parameter info. Baseline for 0 parameters is 4, and the description is appropriate.
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 action ('Save') and resource ('current Resolve project'), and adds verification of success. It distinguishes itself from siblings like resolve_create_project or resolve_open_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or when not to use it. The description simply states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true. Description adds behavioral details: token must be exact, one-time use, and failure conditions (mismatched, expired, replayed). This goes beyond the annotation, though it could mention side effects or required permissions.
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?
Single sentence, no redundancy, front-loaded with the core action. Every word carries meaning.
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?
Output schema exists but is not shown; description does not mention return value. Tool is destructive with many parameters; description lacks prerequisites (e.g., must call prepare first). Given complexity, more completeness is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'action' enum or the complex 'arguments' object. It only indirectly addresses the 'confirmation_token' by stating failure conditions. With 11 properties in arguments, the description fails to add any semantic value beyond the schema's mechanical definitions.
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?
Description explicitly states 'Execute the exact prepared delete once', clearly indicating the verb (execute) and the resource (delete action). The sibling tool 'resolve_prepare_destructive_action' implies a two-step process, distinguishing this as the execution step.
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?
Description mentions that mismatched, expired, or replayed tokens fail, providing a critical condition for use. It implicitly guides the agent to use this only after preparation, but does not explicitly state 'use after prepare' or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds specific context about what is retrieved (formats, codecs, etc.), which is beyond annotations. No contradictions.
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?
Single sentence, only 10 words, front-loaded with active verb 'Discover'. No wasted words.
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?
With output schema present, description does not need to detail return values. However, the parameter is unexplained, which is a gap. Overall, it covers the tool's purpose but not the full input semantics.
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%, and the description does not explain the purpose of the single optional parameter 'format'. The description adds no guidance on how to use the parameter, leaving the agent to infer from the schema alone.
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?
Description uses clear verb 'Discover' and lists specific resources (formats, codecs, resolutions, presets, current render choice). Distinguishes from siblings like resolve_configure_render (which configures) and resolve_render_status (which checks status).
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?
Implied usage: use to discover render options. No explicit guidance on when to use vs alternatives (e.g., when to configure vs discover). No when-not or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the nature of checks ('bounded ffprobe checks') and possible SHA-256 computation, which enriches the agent's understanding of the tool's behavior beyond the annotations.
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, concise sentence that immediately conveys the tool's essence. Every word earns its place; there is no unnecessary verbosity.
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 complexity of the tool (many expectations parameters, output schema present), the description is too brief. It doesn't explain what 'bounded ffprobe checks' entail, the return format, or how SHA-256 is computed, leaving significant behavioral gaps for an agent.
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?
With 0% schema description coverage, the description does not explain the 'path' parameter or detail the 'expectations' object. While it mentions 'optional SHA-256,' it fails to add meaning for the required parameter, relying on the schema alone which has many nested properties.
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 explicitly states the tool's purpose: 'Verify an allowlisted media delivery with bounded ffprobe checks and optional SHA-256.' It uses specific verbs ('Verify') and resources ('media delivery', 'ffprobe checks', 'SHA-256'), clearly distinguishing it from siblings like 'resolve_import_media' or 'resolve_execute_destructive_action'.
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 verifying media delivery but does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'resolve_import_media' for ingestion) or when not to use it. It lacks context about prerequisites or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's claim as 'read-only' is consistent and adds value beyond annotations by specifying the scope (timeline, media, settings, render choice, disk capacity). No contradiction.
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 12-word sentence that front-loads the key behavior ('Read-only studio preflight') and lists checked areas efficiently. Every word earns its place, with no redundancy.
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 tool with 9 parameters, the description is brief and does not explain parameter usage or return structure. However, an output schema exists which likely covers return values. The description adequately conveys the tool's purpose but lacks depth for the parameter count.
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%, so the description should compensate. However, it only mentions general categories ('timeline, media, settings, render choice, disk capacity') without detailing any of the 9 parameters. Parameter names like output_dir, timeline_id, and require_audio require explanation that the description fails to provide.
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 it is a 'read-only studio preflight' for the specific areas of timeline, media, settings, render choice, and disk capacity. This distinguishes it from sibling tools like resolve_get_state (state retrieval) or resolve_verify_media (media verification) by emphasizing a comprehensive check before production.
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 implies use for production preflight checks, but does not explicitly state when to use this tool versus alternatives like resolve_get_state or resolve_execute_destructive_action. The context is clear but lacks explicit when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds that listing does not open projects, which is useful but not extensive. With annotations carrying the safety burden, a score of 3 is appropriate.
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, efficient sentence with no wasted words. It is front-loaded and directly conveys the purpose.
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 no parameters and the presence of an output schema, the description is sufficient. It could optionally mention the return format, but the output schema likely covers that. The tool is simple, so completeness is adequate.
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 tool has no parameters, and schema coverage is 100% (empty). The description does not need to add parameter meaning. Baseline score of 4 applies.
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 lists projects in the local Resolve project-library folder without opening them, using a specific verb 'List' and resource. It distinguishes from sibling tool resolve_open_project by explicitly stating 'without opening them'.
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 implies when to use by stating what it does, but lacks explicit guidance on when not to use or alternatives. The phrase 'without opening them' hints at differentiation from resolve_open_project, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds specific behavioral detail (what aspects are checked: connectivity, version, context, transport, policy, capabilities) beyond the annotations. No contradiction.
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 sentence that immediately states the verb and lists the key aspects. It is concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description fully covers the tool's purpose. It is complete for a health-check tool with no required inputs.
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?
With zero parameters, schema coverage is 100% and baseline is 4. The description explains what the tool does (checks various health aspects), adding meaning beyond the empty schema.
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 uses the specific verb 'Check' and clearly identifies the resource 'Resolve', listing multiple specific aspects (connectivity, version, active context, etc.). It distinguishes from all sibling tools, which are about modifying or creating content.
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 as a health check but provides no explicit guidance on when to use vs. alternatives, nor conditions or prerequisites. Since it is the only health-check tool among siblings, context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![codex-davinci-resolve-mcp MCP server](https://glama.ai/mcp/servers/Mandrilsquad1441/codex-davinci-resolve-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Mandrilsquad1441/codex-davinci-resolve-mcp)

Score Badge

Copy to your README.md:

[![codex-davinci-resolve-mcp MCP server](https://glama.ai/mcp/servers/Mandrilsquad1441/codex-davinci-resolve-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Mandrilsquad1441/codex-davinci-resolve-mcp)

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/Mandrilsquad1441/codex-davinci-resolve-mcp'

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