unofficial-davinci-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a specific function (e.g., color matching, beat detection, EDL generation) with minimal overlap. The clear separation between live and interchange tiers further resolves any ambiguity.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., assemble_edit, beat_grid) or a resolve_verb_noun pattern for live operations. The dual pattern is still predictable and readable, with minor inconsistency in prefix usage.
Tool Count4/5
With 23 tools, the server covers a broad range of DaVinci Resolve workflows without being excessive. Each tool has a clear purpose, though some might be combined (e.g., generate_edl and generate_fcpxml).
Completeness3/5
The toolset is comprehensive for the intended interchange/live workflow but lacks basic editing operations like trimming, transitions, or effects, which are notable gaps for a full video editing assistant.
Average 3.9/5 across 23 of 23 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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?
No annotations are present, so the description must carry the burden of behavioral disclosure. It indicates a non-destructive planning phase with a confirm trigger for rendering, but it does not mention whether it modifies project files, requires an open project, or what permissions are needed. The 're-measured' term hints at loudness analysis but is vague.
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, front-loaded sentence that captures the core purpose quickly. It is concise with no wasted words. However, for a tool with 12 parameters, a structured bullet list might improve clarity without adding length.
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 (12 parameters, no output schema, low coverage), the description leaves significant gaps. It does not explain return values, the relationship between confirm and dry_run, or the meaning of ramp parameter. The description is insufficient for an agent to use the tool correctly across all scenarios.
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 only 17% (2 of 12 parameters have descriptions). The description adds some meaning by referencing dialogue normalization, music bed level, and ducking windows, but it does not explain most parameters (e.g., ramp, dry_run, output_path). With low coverage, the description should compensate more thoroughly.
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 it plans a mix involving dialogue, music, and SFX normalization, bed level, and ducking, with a render on confirm. It is specific and uses verbs like 'plan' and 'render'. However, it does not differentiate from sibling tools like 'cut_music' or 'measure_loudness', missing an opportunity to clarify its unique role.
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 lacks any guidance on when to use this tool versus alternatives. It mentions a confirm step but does not explain prerequisites or scenarios where other tools might be preferred. No exclusions or context for usage 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?
With no annotations, the description must disclose behavior fully. It mentions cutting to length, musical boundaries, and sting-out types. However, it does not explain whether the operation is destructive (though 'dry_run' suggests preview mode), what happens to the original audio, or how output is handled. Partial transparency.
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 unnecessary words. It is appropriately concise, though breaking it into structured items could improve readability without adding length.
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 8 parameters, low schema coverage, and no output schema, the description is insufficient for an agent to use the tool correctly. Missing details on essential parameters (e.g., dry_run, confirm) and output behavior limit completeness.
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 only 13% (only bar_hint has a description). The description indirectly explains target_seconds (target length) and sting (sting-out type), but does not cover other parameters like confirm, dry_run, tail_fade, output_path, or bar_hint. This leaves significant gaps in agent understanding.
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 cuts a song to a target length, ending on a musical boundary with a smooth sting-out. It distinguishes from sibling tools like 'tighten_dialogue' or 'beat_grid' by focusing on music and sting effects. However, 'musical boundary' is somewhat vague and could be more precise.
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. Sibling tools cover different editing tasks (e.g., dialogue tightening, assembly), but the description does not provide any 'when-to-use' or 'when-not-to-use' advice, leaving the agent to infer usage.
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 does not disclose any behavioral traits such as whether the tool is read-only, requires specific file formats, or modifies the files. With no annotations present, the description carries full burden but provides minimal insight into side effects or constraints.
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 very short and concise, consisting of a single sentence. However, it is too brief and lacks structure (e.g., no bullet points or separation of concerns), which might leave the agent without enough context.
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 that there is no output schema, no annotations, and only one parameter, the description should provide more context about what is returned or how the measurement is performed. It is incomplete and assumes the agent already knows the details of EBU R128.
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?
The input schema has one parameter 'paths' with 0% description coverage. The description only adds 'per file', which is insufficient to clarify what paths refer to (e.g., audio files, directories) or any constraints like supported formats. The schema provides no additional help.
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 measures EBU R128 integrated LUFS, loudness range, and true peak per file. It uses a specific verb 'measure' and specific resource (audio loudness metrics), and distinguishes itself from sibling tools like mix_plan or probe_media which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, nor are there any prerequisites or exclusions mentioned. The description simply states what it does without indicating appropriate contexts.
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?
No annotations are provided, so the description must disclose behavioral traits. It mentions the output (cut plan, preview) but does not explain key behavioral aspects like the meaning of confirm, dry_run, or other parameters, nor any destructive or non-destructive nature.
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 that front-loads the purpose and outputs. It is appropriately sized but could be more structured with bullet points for parameters or output details.
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 10 parameters, no output schema, and no annotations, the description is incomplete. It does not explain how to use the cut plan, what parameters control tightening behavior, or prerequisites for the input media.
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 only 20%, with only media and noise_db having descriptions. The tool description itself does not add meaning to the other 8 parameters (e.g., head, tail, confirm, dry_run). Since coverage is low, the description should compensate but fails to do so.
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 detects and tightens dead air in talking clips, returning a cut plan and optional preview. This verb+resource is specific and distinguishes it from siblings like cut_music or assemble_edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for talking clips with dead air but does not explicitly state when to use or when not to use this tool over alternatives like cut_music or beat_grid. No when-not or alternative guidance is 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?
No annotations provided, so description carries full burden. It discloses baking of .cube LUTs and preview strips, but lacks details on file overwrite behavior, performance implications, 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 efficiently captures core functionality with no redundancy. Action verb and resources are front-loaded.
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 8 parameters, no output schema, and no annotations, the description omits important parameter behavior and integration context (e.g., DaVinci Resolve). 'output_dir' behavior and 'dry_run' semantics are missing.
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 coverage is low (38%), description adds context for 'method' (Reinhard vs Lab-histogram) and preview, but does not explain 'confirm', 'dry_run', or 'strength' meaning beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'Match' and resource 'target clips/stills to a reference image', distinguishes from siblings like 'resolve_apply_lut' and 'resolve_set_grade' by detailing LUT baking and preview strips.
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 vs alternatives like 'resolve_set_grade'. No prerequisites, exclusions, or method selection criteria provided.
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?
No annotations provided; the description mentions using ffprobe implies read-only operation but lacks details on behavior like speed, file size limits, or error 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?
The description is a single, efficient sentence that lists capabilities without wasted words, well front-loaded.
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?
No output schema; the description lists extracted properties but does not specify return format (e.g., JSON object, array for multiple files), leaving a gap for an agent.
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 100% for the single parameter; the tool description lists metadata returned but does not add meaning to the paths parameter beyond the schema's description.
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 probes media files with ffprobe and lists specific metadata attributes (duration, fps, etc.), distinguishing it from sibling tools like scan_media_folder which likely scans folders.
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 probing individual media files but does not explicitly state when to use vs alternatives, nor provide 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?
No annotations provided, so the description carries the full burden. It discloses validation and optional beat snapping, but does not mention side effects, authentication needs, or error conditions. It provides basic behavioral info but lacks depth for a mutating tool.
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, front-loaded with key actions, and contains no superfluous words. It efficiently conveys the tool's purpose and optional behavior.
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 takes a complex nested object and has no output schema. The description mentions returning a normalized plan but does not describe its structure, error handling, or prerequisites. More context about the expected plan format and return value would improve completeness.
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 says 'Validate an edit plan' without explaining the structure or required fields of the plan object, which is complex and nested. The description adds 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 clearly states the verb 'validate' and resource 'edit plan', and distinguishes this tool from siblings by mentioning normalization and optional beat snapping, which is not present in sibling tools like beat_grid or cut_music.
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 probing media and before interchange/live, but does not explicitly state when to use or when not, nor does it mention alternatives among siblings. The usage context is implied but not detailed.
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?
With no annotations, the description carries full burden. It discloses scanning and probing behavior and stable sorting, but lacks details on error handling, performance impact, or whether the operation is read-only or modifies files. Adequate but not comprehensive.
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?
Extremely concise with two sentences. Front-loaded with the main purpose and a unique behavioral trait. No filler or redundant information.
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?
The tool has 5 parameters and no output schema, yet the description is minimal. It does not explain what the result looks like, how 'probe' affects output, or any behavioral context like performance with large folders. Incomplete for an AI agent.
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?
The input schema has 60% description coverage, and the description adds no new parameter semantics beyond what's in the schema. It does not elaborate on parameters like folder_path or include_extensions. Baseline 3 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?
Clearly states 'Scan a folder for media and probe each file' with a specific verb and resource. Adds unique behavior 'Stable sorted order' that distinguishes it from sibling tools like 'probe_media' which likely operates on single files.
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 guidance on when to use this tool versus alternatives. The mention of 'stable sorted order' implies a specific use case but doesn't provide when-not or alternatives. Usage is implied by the tool name and description.
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?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Check'), but does not disclose any behavioral traits such as what happens if the job_id is invalid or if the tool has any side effects. The description is minimal.
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 includes the purpose and constraint. Every word is necessary, and there is no wasted text.
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 simplicity (1 parameter, no output schema), the description covers the basic purpose. However, it omits information about what the tool returns (e.g., progress info, queue state), which would be helpful for an agent to interpret results.
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?
The input schema has 100% coverage with a clear description for the single parameter 'job_id' ('Render job id from resolve_render'). The tool description adds no additional 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 clearly states the verb 'Check' and the resource 'render progress and the render queue', which is specific and distinguishable from the sibling tool 'resolve_render'. The constraint 'Live tier only' adds clarity.
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 provides a clear usage context ('Live tier only'), which guides when to use the tool. However, it does not explicitly state when not to use it or compare with alternatives like 'resolve_render', but the sibling context makes it obvious.
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?
No annotations are provided, so the description must carry behavioral info. It states 'Live tier only' and outlines the dry_run/confirm flow. But it lacks details on side effects, permissions, or behavior when parameters conflict (e.g., start_render true but confirm false).
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 brief and to the point (2 sentences). It avoids verbosity but could be slightly more structured by separating the workflow from the constraints.
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 9 parameters and no output schema, the description covers the high-level workflow and restriction ('Live tier only'). However, it does not elaborate on key parameters like preset_name or render_settings, leaving gaps for effective use.
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 100%, so the schema already documents parameters. The description adds minimal semantics beyond highlighting dry_run and confirm interaction. Baseline 3 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 configures a render job for the current timeline and optionally starts it. It distinguishes from the sibling tool resolve_render_status by mentioning polling.
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 provides a workflow: use dry_run first, then confirm. It also suggests polling with resolve_render_status. However, it does not explicitly state when not to use this tool or list alternatives.
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?
Covers dry_run and file writing, but lacks details on overwriting, error handling, or permissions, especially since no annotations exist.
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?
Two dense sentences front-load the core purpose and key behavior, with no wasted words.
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?
Explains the output (file for Resolve import) and dry_run behavior, but omits return format details and error scenarios; good for the complexity.
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 coverage is 100%, and the description adds only overall context (FCPXML version, Resolve compatibility) without enhancing parameter meanings.
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 generates an FCPXML 1.9 timeline with clips and markers for DaVinci Resolve, distinguishing it from siblings like generate_edl.
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?
It positions the tool as 'primary way to deliver an edit in interchange (free Resolve) mode' but does not explicitly exclude alternatives or compare with siblings.
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?
No annotations are provided, so the description carries full burden. It discloses that results include 'concrete numbers and mappings to tool parameters', which is helpful. However, it does not explicitly state the tool is read-only or discuss any side effects, rate limits, or data size.
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 two short sentences, front-loaded with the core purpose and including all needed context without extraneous words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter with an enum, no output schema, and no annotations, the description adequately covers what the tool does and what the parameter controls. It could mention that it's a read operation, but the content is complete enough for an AI agent to invoke correctly.
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 coverage is 100%, so baseline is 3. The description adds that omitting topic lists available topics, which partially echoes the schema description. It also adds context about returning numbers and mappings, but does not significantly enhance understanding 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 reads editorial knowledge, explicitly listing the topics (color looks, beat-cutting, etc.) and contrasting it with 'not just operating the app'. This distinguishes it from sibling tools that perform actions like assembling, color matching, or cutting.
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 the tool is for editorial guidance (e.g., 'for editing well') and mentions that omitting topic lists available subjects. It does not explicitly exclude use cases or name alternatives, but the contrast with 'operating the app' hints at when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the algorithm dependency (librosa or fallback) and the outputs, but does not cover security, side effects, or required permissions. This is adequate for a non-destructive estimation tool.
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: two sentences that immediately convey the tool's purpose and key behavior. No filler or redundant information.
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 the low complexity (single parameter, no output schema), the description fully covers what the tool does, its output, and the fallback behavior. It is sufficient for an agent to select and invoke the tool correctly.
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 coverage is 100% with a clear description for the single parameter 'audio'. The description adds no additional meaning beyond the schema, so a baseline score of 3 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 explicitly states the action ('Estimate') and the specific outputs (tempo, beat times, downbeat guess, onset strengths). It clearly distinguishes from sibling tools, none of which perform beat detection.
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 mentions using librosa when available else fallback, but does not explicitly state when to use this tool versus alternatives. The purpose is implied but no direct when/when-not guidance 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?
With no annotations provided, the description bears the full burden of disclosing behavior. It explains dry_run returns the plan vs. writing a file, and notes the output is simpler than FCPXML. It could be improved by mentioning side effects (e.g., file writing) or prerequisites, but is still informative.
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 concise with two sentences, front-loading the purpose and distinguishing information. Every word earns its place, and there is 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?
Given the tool has 6 parameters, 2 required, no output schema, the description covers the main purpose and dry_run behavior. However, it lacks details on the EDL format, ordering of clips, error handling, or what the plan object looks like. More completeness would help, especially since there is no output schema.
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?
The input schema has 100% coverage, so baseline is 3. The description adds value by explaining that dry_run='true returns the plan, dry_run=false writes the file' and that the tool is simpler than FCPXML. However, it does not elaborate beyond the schema for other parameters.
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 generates a CM3600 EDL for video clips in a plan, using specific verbs and resources. It distinguishes itself from the sibling tool generate_fcpxml by noting it is simpler (cuts only, no audio/effects), which helps differentiate.
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 provides clear guidance on when to use this tool ('use for round-tripping a cut list') and compares it to FCPXML. It also explains the dry_run parameter behavior. However, it does not explicitly state when not to use it or list alternative tools.
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?
Adds value beyond annotations (none provided) by stating the import-if-needed behavior and the two-step dry_run/confirm process. Also notes the Live tier restriction. Does not describe error handling or side effects.
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?
Two concise sentences that front-load the purpose and essential workflow instructions. 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?
No output schema, so description should explain what the dry_run plan contains or how to interpret results. It omits return value details, error conditions, and post-confirm behavior. Adequate but with clear gaps.
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 100%, so parameters are already well-documented. The description adds minimal extra meaning (e.g., 'importing them first if needed' context). Baseline is 3.
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 the verb 'append clips' to the specific resource 'active timeline', with additional details on importing and the dry_run/confirm workflow. It distinguishes itself from sibling tools like 'assemble_edit' or 'beat_grid' by focusing on timeline appending.
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?
Provides explicit workflow guidance: 'dry_run first, then confirm' and a constraint 'Live tier only'. However, it does not discuss when to use this tool over alternatives like 'assemble_edit' or 'generate_edl'.
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?
With no annotations, the description discloses the dry-run/confirm pattern (non-destructive by default) and the 'Live tier only' constraint, which are key behavioral traits. It does not cover permissions or reversibility, but the provided info is sufficient for safe invocation.
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?
Two concise sentences: first states purpose, second gives critical usage instructions. No wasted words, front-loaded with essential information.
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 description is short and covers core aspects, but lacks details on return values (e.g., what the dry run plan contains) and assumes knowledge of 'Live tier'. Given 9 parameters and no output schema, more context would improve completeness.
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 coverage is 100% with detailed parameter descriptions. The tool description does not add new parameter details but frames the dry_run and confirm parameters in a workflow context. Baseline of 3 is appropriate as no significant value beyond 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 verb 'Set' and the resource 'ASC CDL slope/offset/power/saturation on timeline clips', distinguishing it from sibling tools like 'color_match' or 'resolve_apply_lut' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'dry_run first, then confirm' and 'Live tier only', providing a clear workflow instruction and constraint. However, it does not mention when to avoid this tool or alternatives for other tiers.
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?
Although no annotations are provided, the description discloses the key behavioral safety pattern (dry_run then confirm) beyond what the schema states, guiding the agent to avoid accidental mutation.
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?
Two concise sentences: first states purpose, second provides workflow and alternative. No filler; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, safety workflow, and sibling distinction. Lacks description of return values (no output schema), but still adequate for a tool with clear input schema and safety pattern.
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 100%, so baseline is 3. The description adds the workflow hint ('dry_run first, then confirm') but does not deepen parameter meaning beyond what the schema provides.
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 ('Add') and resource ('one or more markers to the active timeline'), and distinguishes from sibling tool 'generate_marker_csv' by specifying the tier limitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('Live tier only'), when-not-to-use ('for free Resolve use generate_marker_csv'), and a recommended workflow ('dry_run first, then confirm').
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?
With no annotations provided, the description bears the full burden of behavioral disclosure. It effectively communicates the dry-run/confirm workflow and tier restriction, but could further elaborate on side effects or failure modes.
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 consists of three concise sentences, each adding distinct value: purpose, workflow, and alternative tool. No unnecessary words or 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 tool's complexity (6 parameters, no output schema) and the presence of sibling tools, the description covers the core workflow and constraints adequately. Some parameter behaviors (e.g., clip_indexes, node_index) rely on schema descriptions, which is acceptable.
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 100%, so parameters are already well-documented. The description adds minimal additional meaning beyond the schema, such as the dry_run/confirm pattern, but doesn't significantly enhance parameter understanding.
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 applies a .cube LUT to clips on a timeline video track. It distinguishes from sibling tool color_match by specifying that color_match produces the LUT file, whereas this tool applies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to dry_run first then confirm, which is a clear workflow directive. It also restricts usage to Live tier and directs users to color_match for LUT production, providing explicit 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It accurately describes the two-phase commit pattern (dry_run then confirm) and explains the confirm parameter's role. It doesn't cover potential failure modes or whether imports are additive, but the core behavior is well described.
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: three sentences, no filler. The purpose is stated first, followed by workflow and usage context. Every sentence serves a clear purpose and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 4 parameters, no output schema, and no annotations, the description provides essential context: the two-phase workflow, usage timing relative to siblings, and tier restriction. It could be improved by describing what the dry_run plan looks like or error handling, but it is largely complete for typical usage.
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?
Schema coverage is 100%, so each parameter is already documented. The description adds value by explaining the workflow context (dry_run first, then confirm) which complements the schema. It does not repeat parameter details but provides high-level guidance on how to use them together.
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 ('Import media into the project media pool') and the resource. It distinguishes from siblings by specifying to run before resolve_create_timeline / resolve_append_to_timeline and only when media is not already in the pool. The verb+resource is 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow ('dry_run first, then confirm') and states when to use the tool ('when the media is not already in the pool'). It also mentions 'Live tier only' and suggests ordering relative to sibling tools. However, it does not explicitly state when not to use the tool 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?
No annotations provided, so description carries full burden. Discloses read-only nature ('Read') and operational constraint ('Live tier only'). Adequate behavioral context for a simple read tool.
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?
Two sentences, front-loaded with key purpose and output, no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description lists all returned information. Missing error conditions or behavior with no open project, but adequate for a simple orientation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, but description adds meaning by explaining what the tool returns (project name, timelines, active timeline details). Baseline 4 for zero-parameter tools 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?
Clearly states the verb 'Read' and the specific resources: project name, timelines, active timeline's frame rate and marker count. Distinct from sibling tools which are more focused on editing, creation, or rendering tasks.
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?
Explicitly says 'Use to orient before editing' and 'Live tier only', providing clear context for when to use and a constraint. Lacks explicit exclusion of alternatives but sufficient for orientation.
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?
In the absence of annotations, the description explains that dry_run returns a plan and dry_run=false writes the file. It mentions the output is a deterministic CSV. However, it does not specify what happens if output_path is omitted, nor does it describe potential side effects like overwriting existing files.
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?
Two sentences cover purpose and usage. No filler or redundant information. Very efficient and front-loaded.
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?
The tool is simple and well-documented. The description explains output columns and dry_run mode. However, it doesn't clarify default behavior for output_path when dry_run=false, and 'interchange mode' might be unclear without domain knowledge. Still, it is nearly complete.
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?
Schema coverage is 100% so baseline is 3. The description adds value by explaining the purpose of dry_run (plan vs write) and detailing the CSV columns, which maps to the markers array items. This goes beyond the schema descriptions.
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 writes a deterministic marker manifest CSV with specified columns (frame, timecode, seconds, name, color, note, duration). It distinguishes from sibling tools like resolve_add_markers by indicating it is for interchange mode when live insertion is unavailable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use in interchange mode where live marker insertion is unavailable' and explains the dry_run parameter behavior (returns plan vs writes file). This gives clear guidance on when and how to use the tool.
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 discloses what the tool reports (tier, version, ffmpeg, dependencies) and implies read-only behavior. However, it does not explicitly state non-destructive or idempotent nature, though 'reports' suggests it. With no annotations, the description carries full burden and is mostly transparent.
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?
Two sentences effectively convey purpose and usage guidelines. The first sentence lists items; the second provides cross-tool guidance. No unnecessary words. Could be slightly more structured, but efficient and front-loaded.
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 no output schema, the description fully covers what the tool does and provides important context about tier behavior and dry_run defaults. It is complete for the tool's simplicity and the agent's decision-making needs.
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 zero parameters and the input schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline score of 4 is appropriate as the description does not need to add 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 clearly states the tool reports the active tier (live vs interchange), DaVinci Resolve version, ffmpeg availability, and dependency status. This specific verb+resource combination distinguishes it from sibling tools which perform specific actions like editing, rendering, or analyzing media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Call FIRST', providing strong priority guidance. It also explains when to use the tool based on tier (live vs interchange) and describes the dry_run behavior for mutating tools, which helps the agent decide when to invoke this tool before others.
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?
No annotations are provided, so the description carries the full burden. It explains the dry_run/confirm pattern, indicating that dry_run returns a plan without changes and confirm must be true to apply. This is transparent about the tool's safety mechanism, though it could mention potential overwrite behavior or idempotency.
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 two sentences, with the first covering purpose and options, and the second providing usage constraints and alternatives. No redundant information; every clause serves a 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?
For a tool that creates a timeline with no output schema, the description covers creation options, the critical dry_run/confirm safety pattern, and tier limitations. It could mention the return value format for dry_run, but the existing 'return the plan' sufficently implies a plan object.
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?
All 7 parameters have schema descriptions (100% coverage). The description adds context by grouping clips as 'edit decision list', music_paths as 'optional audio', and explaining dry_run/confirm interplay. This adds meaning beyond the raw 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 it creates a timeline with optional seeding from clips, music, and markers. It distinguishes itself from generate_fcpxml, which is for free Resolve, making the tool's purpose specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to dry_run first then confirm, and notes that this is for Live tier only, with an alternative (generate_fcpxml) for free Resolve. This provides clear when-to-use and 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.

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:

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

Score Badge

Copy to your README.md:

[![unofficial-davinci-mcp MCP server](https://glama.ai/mcp/servers/wassermanproductions/unofficial-davinci-mcp/badges/score.svg)](https://glama.ai/mcp/servers/wassermanproductions/unofficial-davinci-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/wassermanproductions/unofficial-davinci-mcp'

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