Checks readiness for the next video job and returns a read-only JSON verdict; optionally allows overwriting existing media while protecting non-media files.
Return a read-only JSON readiness verdict for the next video job.
| Name | Required | Description | Default |
|---|---|---|---|
| overwrite | No | Explicitly allow replacing existing media. Existing non-media files are protected. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.16.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does say the call is read-only and returns JSON, but it never says what the verdict consists of, whether it blocks or just reports, or — critically — why a supposedly read-only check exposes an 'overwrite' option that allows replacing existing media. That internal tension is left unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. Nothing is padded or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers the return shape, so the description needn't detail the verdict fields. However, for a doctor/preflight tool with no annotations, it should say what is being checked and clarify the read-only claim against the destructive-sounding overwrite parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one optional parameter and schema description coverage is 100%, so the schema already explains 'overwrite' in detail. Baseline 3 applies; the description adds nothing about the parameter and does not resolve why a read-only verdict takes an overwrite flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource: return a readiness verdict (preflight check) for the next video job. That distinguishes it from siblings like video_trim or video_convert, though it does not explicitly contrast with the nearest peers (video_quality_check, hyperframes_doctor, video_rescue_inspect).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Readiness verdict for the next video job' implies a preflight/doctor step, but there is no statement of when to call this versus video_quality_check, hyperframes_doctor, or video_rescue_inspect, and no prerequisites or 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.