Loading ToolBench
Model Context Protocol server for DaVinci Resolve integration
This server has significant definition quality issues. While it provides 6 tools with basic type information, most lack comprehensive descriptions, parameter documentation is sparse, output schemas are not documented, and error handling guidance is minimal. Tool names follow verb_noun convention (positive), but the implementation fails to meet production standards for LLM-friendly tool definitions. Most parameters lack descriptions, several descriptions are under the 50-character minimum for LLM clarity, and no output schemas are documented. The server would require substantial rework to be production-ready.
Activate a domain to register its tools
Deactivate a domain to unregister its tools
Get the current page in DaVinci Resolve
Get the version of DaVinci Resolve
List all available domains with their status and tool count
Switch to a different page in DaVinci Resolve
Output schemas completely undocumented. No tool returns a documented schema, LLMs cannot predict output structure or plan follow-up tool calls. Violation of pattern:tool requirement that 100% of A+ tools document return types.
Parameter descriptions missing or insufficient. The 'domain' parameter in activate_domain and deactivate_domain has only 'Name of the domain to activate/deactivate', no guidance on what domains are available, valid format, or how to discover them. The 'page' parameter in switch_page lacks description entirely. Violates pattern:tool-description requirement that every parameter must have a non-empty description (10 - 1024 chars).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
Tool descriptions too sparse to guide LLM selection. 'Get the version of DaVinci Resolve' (27 chars), 'Get the current page in DaVinci Resolve' (37 chars), and 'Activate a domain to register its tools' (38 chars) fall below the 50-character baseline for LLM-friendly descriptions. They lack WHAT, WHEN, and any prerequisite/dependency hints. Baseline from 549 production tools: 194 chars average (p10=34, p90=392). These are at the very bottom of the distribution.
No error recovery guidance. The tool call handler catches DaVinciResolveError and generic Exception but returns only 'DaVinci Resolve error: {e}' or 'Unexpected error: {e}'. This violates pattern:recovery-guide, errors must tell the LLM what to do next. Example: 'Page not found. Available pages: edit, cut, fusion, color, fairlight. Did you mean one of these?'
No input validation or actionable error messages. If an LLM passes an invalid domain name or page name, the error is 'DaVinci Resolve error: <exception>', no hint of what went wrong, what values are valid, or how to recover. Violates review:actionable-errors: 'Invalid status: got "pending", must be one of: open, in_progress, resolved' guides the LLM; 'Invalid input' does not.
Parameter enum constraints missing. 'page' in switch_page should declare the valid page set (e.g. edit, cut, fusion, color, fairlight, inspector) as an enum in the schema. Free-form strings invite hallucinated values. A well-formed enum is self-documenting and prevents invalid LLM calls.
Tool composition broken. activate_domain and deactivate_domain manage domain state, but their outputs are not documented. list_domains supposedly returns domain status and tool count, but the response schema is not visible in the code. Without knowing what list_domains returns, an LLM cannot effectively chain domain activation → domain tool discovery → tool invocation. Violates pattern:tool-chain.