Query source-backed semantic spans locally to retrieve accurate video moments and avoid fabricated descriptions.
Query source-backed semantic spans locally without inventing descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| 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.4Input schema / properties / overwriteAdded value: +{
+ "default": false,
+ "description": "Explicitly allow replacing existing media. Existing non-media files are protected.",
+ "title": "Overwrite",
+ "type": "boolean"
+}v1.16.0Input schema / additionalPropertiesAdded value: +falsev1.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that the query is local and source-backed and avoids inventing descriptions, which is useful, but it says nothing about permissions, side effects, rate limits, or the meaning of the overwrite capability—a notable gap for a tool with an overwrite parameter.
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?
The description is a single front-loaded sentence with no wasted text, which is good. But it is under-specified rather than appropriately concise, leaving key usage and parameter context absent.
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?
Although an output schema exists and need not be described, the input schema is vague and the tool has no annotations. The description does not explain the nested request payload, the overwrite behavior, or how this tool relates to the many sibling analysis/timeline tools, leaving it incomplete for correct invocation.
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?
Schema description coverage is only 50%. The nested 'request' object has no description or defined shape, and the description does not explain what belongs in it. Only the 'overwrite' parameter is documented in the schema, and the description adds no parameter meaning beyond that.
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?
The description gives a specific verb ('Query') and a resource ('semantic spans'), and adds constraints like 'source-backed' and 'locally.' However, 'semantic spans' is jargon without clarification, and there is no differentiation from closely related siblings such as video_semantic_timeline or video_inspect_temporal.
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?
It implies the tool is for local, source-backed semantic queries, but gives no explicit guidance on when to choose it over alternatives like video_semantic_timeline or video_analyze. There are no exclusions, prerequisites, or workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.