The server defines 15 tools with complete input schemas and basic descriptions. However, definition quality is held back by several critical gaps: (1) Most tool descriptions are terse (10-30 chars) and fail to explain WHEN to use them or their consequences; (2) No output schemas are documented, forcing LLMs to guess result structures; (3) Critical tools lack parameter descriptions (e.g., trim_clip_by_frames and export_project have no descriptions for trackType, include_audio); (4) No error handling guidance, tools do not explain recovery steps; (5) Tool names are reasonable (verb-driven) but descriptions do not disambiguate overlapping tools (e.g., get_sequence_details vs list_all_sequences); (6) No indication of tool side effects (WRITE vs READ_ONLY), limiting agent planning. The codebase shows proper schema registration in ListToolsRequestSchema but does not implement recovery guidance, input validation feedback, or structured output documentation.
Tool descriptions are under 20 characters for 12/15 tools, providing insufficient context for LLM tool selection. E.g., 'Get basic information about the current Premiere Pro project' (57 chars) is borderline; 'Get the track structure of the active sequence' (46 chars) is too generic. Descriptions should answer WHAT, WHEN to use it, and any prerequisites.
Add output schemas to every tool definition. Document the structure of returned data: 'Returns: {project_name: string, frame_rate: number, resolution: {width: number, height: number}, duration_frames: number}'. This enables LLMs to plan downstream calls and extract the right fields.
Expand tool descriptions to 50-150 characters. For each tool, answer: (1) What does it do? (2) When should you use it instead of similar tools? (3) What does it return? Example: 'Get metadata for all sequences in the project. Call this first if you need to find a specific sequence by name; for the currently active sequence, use get_active_sequence_info. Returns: [{ name, duration_frames, width, height, frame_rate }]'.
Add descriptions to ALL parameters, especially optional ones. For trim_clip_by_frames, document: 'trackType (string, required, enum [video|audio]): Which type of track to trim, audio edits affect only audio clips, video edits affect video clips.' For export_project's include_audio: 'include_audio (boolean, default true): Whether to include audio in the export. Set to false to export video-only.'
Implement structured error responses with recovery guidance. When a tool fails, return JSON like: {'status': 'error', 'error_code': 'sequence_not_found', 'message': 'Sequence "project-xyz" not found. Available sequences: seq1, seq2, seq3. Try calling list_all_sequences() first to see all options.'}. This tells the LLM what went wrong and how to fix it.
Add input validation and return actionable error messages. When LLMs pass invalid enums (e.g., direction='middle' instead of 'in'|'out'), return: 'Invalid direction: got "middle", must be one of: in, out'. This enables self-correction in one retry.
Score history
Overall score trend
↑ 33 points across a rubric change (v1 → v2)
50/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
50
2026-07-28+
v2
2026-03-09
F
17
-
v1
read only
source verified
63/100
Get all media items in the project browser with file information
get_render_queueread onlysource verified63/100
Get current render queue status and items
get_selection_inforead onlysource verified65/100
Get information about currently selected clips or time range
Parameter descriptions are missing or incomplete. trim_clip_by_frames parameters trackType, direction, and framesDelta lack descriptions in the source code. export_project's include_audio lacks a description. LLMs cannot infer whether these are required, optional, or what format/values are valid.
No error handling guidance. Tools do not indicate how LLMs should respond to failures, is an error retryable? Should the agent ask the user? Are some errors fatal? The CallToolRequestSchema handler catches exceptions but returns no structured error classification or recovery hints.
No input validation or actionable error messages. If an LLM passes invalid sequence_name to get_sequence_details or an out-of-range page_size, there is no mechanism to return 'Invalid sequence_name: got "project-xyz", available sequences: seq1, seq2' that would let the LLM self-correct.
No tool annotations for idempotence or destructiveness. The code marks trim_clip_by_frames, create_sequence, and export_project as WRITE tools in the metadata, but the tool definitions themselves lack readOnlyHint/destructiveHint/idempotentHint annotations that would guide agent planning and help determine retry safety.
Overlapping tool purposes create ambiguity. get_sequence_details, list_all_sequences, and get_active_sequence_info all retrieve sequence data but do not clarify when to use each. Descriptions should state: 'Use this when you need metadata for ALL sequences; call get_active_sequence_info for the currently open sequence; call get_sequence_details for one sequence with full track/effect/marker detail.'
No pagination support documented. Tools like get_project_media, get_timeline_clips, and get_render_queue likely return large result sets but lack limit/offset/page_size parameters. Without pagination, large results blow context windows and LLM reasoning degrades.
No chain-enabling references. Tools like create_sequence and export_project do not document what fields they return (e.g., sequence_id, export_path), making it impossible for LLMs to pass results to downstream tools without extra lookup calls.
create_sequenceexport_project
Add tool annotations to the tool definitions. Include readOnlyHint: true for all get_* tools, and destructiveHint: true for create_sequence and export_project. For idempotent tools (if any are replayable without side effects), add idempotentHint: true. This guides agent planning and retry logic.
Clarify tool overlap with WHEN-to-use guidance in descriptions. For get_sequence_details vs list_all_sequences: 'Use get_sequence_details when you have a sequence name and need full details (tracks, effects, markers); use list_all_sequences to discover all sequences in the project and get summary info (name, duration).'
Add pagination support to discovery tools. Add parameters: limit (default 20, max 100), offset (default 0). Document: 'Returns up to 20 items per call; use offset to fetch additional pages. Include total_count in response so agents know when to stop.'
Document chaining references in output schemas. For create_sequence, document: 'Returns: {sequence_id: number, name: string, ...}. Use sequence_id in trim_clip_by_frames and export_project.' For export_project: 'Returns: {export_path: string, status: string, duration_seconds: number}'.
Add a confirmation pattern for irreversible operations. Before executing create_sequence or export_project, return a dry-run result with a confirm_create_sequence or confirm_export_project tool, or add a 'confirm: true' parameter. This prevents accidental data loss from agent mistakes.