Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral details beyond annotations: it lists what is reported (paths, versions, actionable hints) and documents environment-variable overrides for tool locations.

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 front-loaded and appropriately short for a zero-parameter diagnostic tool. The phrase 'Read-only: modifies nothing' largely repeats the readOnlyHint annotation, which is minor redundancy but not disruptive.

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?

Given the tool's low complexity, zero parameters, and an existing output schema, the description is complete enough. It identifies the dependencies checked, what information is returned, and the environment-variable overrides, while the output schema can handle the return structure.

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?

The tool has zero parameters, so the baseline is 4. The description adds useful configuration semantics by documenting the KDENLIVE_MCP_KDENLIVE, KDENLIVE_MCP_MELT, KDENLIVE_MCP_FFPROBE, and KDENLIVE_MCP_FFMPEG environment variables that can override tool locations.

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 uses a specific verb, 'Report,' and names the exact dependencies checked: Kdenlive, MLT (melt), ffprobe, and ffmpeg. It clearly distinguishes this environment-diagnostic tool from sibling tools such as inspect_project, probe_media, and render_project.

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?

The description makes the diagnostic context clear by stating that it reports whether dependencies are installed and usable, with actionable hints. It does not explicitly say when to prefer this over sibling tools or mention troubleshooting workflows such as before rendering, but the usage context is still clear from the purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the description correctly spends its budget elsewhere: frame-rate integer positions, half-open range semantics for timeline ranges versus inclusive source in/out, and the fact that large timelines get truncated to max_clips. The one gap is that it never says how an agent detects truncation occurred or where to look for the full data.

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?

Three compact sentences, front-loaded with what is returned and immediately followed by the units and range conventions that most often cause misinterpretation. No filler or restatement of the title.

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?

With a full input schema, complete annotations, and an output schema, the description only needs to supply the interpretation rules that structured data cannot — frame units, range boundary conventions, and the truncation cap, including a pointer to the output's 'conventions' field. Nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3. The description adds little parameter-level meaning beyond the schema — it restates the max_clips truncation consequence and implies the sequence default, but adds no format hints for 'path' or 'sequence' beyond what is already documented.

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?

States a specific verb ('Return') plus an enumerated resource set (tracks, clips, mixes, compositions, guides) scoped to exactly one sequence of a Kdenlive project. The word 'read-only' and the sequence scoping distinguish it from siblings like inspect_project and list_project_media without the agent opening any schema.

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?

Usage is implied rather than stated: an agent infers this is the tool for reading timeline structure once it has a project path. There is no explicit 'use this instead of inspect_project when...' routing, and no preconditions (e.g., whether the project must be closed or readable) are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description adds value beyond them: the sha256 is included specifically to let later calls detect file changes, and the disk-only read semantics are spelled out. It does not say what happens on a missing, malformed, or non-Kdenlive file, which is the main remaining behavioral gap.

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?

Three sentences, zero filler, and the core action plus the read-only constraint are front-loaded. The stale-read caveat is placed last where it reads naturally as a caveat rather than burying the purpose.

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?

An output schema exists and annotations cover the safety profile, so the description is not obliged to explain return values. It nonetheless covers the salient result fields and the on-disk freshness caveat, leaving only failure behavior (invalid path, corrupt project) unaddressed for a low-complexity single-parameter tool.

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 coverage is 100% and the single path parameter is already documented as an absolute .kdenlive path, so the schema carries the burden. The description only implies what the path points at ("a Kdenlive project file") without adding validation rules or edge-case guidance beyond the schema.

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?

"Summarize a Kdenlive project file" gives a specific verb and resource, then enumerates the exact contents (versions, profile, frame rate, bin clip count, per-sequence duration and track counts). An agent can distinguish this overview/summary tool from the narrower siblings get_timeline and list_project_media without opening any schema.

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?

States the operating mode clearly ("without modifying it", "Reads the file on disk only") and gives a concrete exclusion: unsaved changes in a running Kdenlive are not visible, which tells the agent when this tool will produce stale results. It does not explicitly name sibling alternatives such as get_timeline or list_project_media, so routing to a narrower tool remains an inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, it discloses that references are resolved the same way Kdenlive resolves them (project root, moved projects, proxies) and that URLs are reported but never fetched — a real network-safety guarantee the annotations don't express. It also states a concrete cap ('up to 50 available files') for probing, giving the agent a limit it could not otherwise know.

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?

Three dense sentences, front-loaded with the core purpose before the diagnostic and probing details. Every clause carries information — resolution rules, no-fetch guarantee, probe cap — with no filler or restatement of the name.

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?

An output schema exists, so return values need no explanation; the description covers the remaining risk areas: path resolution semantics, missing/unreadable file diagnosis, network behavior, and probe limits. Nothing an agent needs in order to call this correctly is missing.

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 coverage is 100%, so the baseline is 3; the description earns an extra point by explaining what probe=true actually yields (streams, codecs, sizes, frame rates, rotation) and the 50-file ceiling, which is not encoded in the schema. max_items is left to the schema, which documents it adequately.

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 opens with a specific verb and resource ('List the media referenced by a Kdenlive project's bin') and extends it to effect/transition assets such as LUTs and luma wipes, so the scope is unambiguous. It implicitly separates itself from get_timeline (bin vs. timeline) and probe_media (optional inline probing), but never names those siblings to make the boundary explicit.

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?

Usage is only implied: the agent can infer this is the tool for auditing bin assets and finding missing files, and that probe=true adds metadata. There is no explicit 'use this instead of probe_media / inspect_project when…' guidance, and the overlap with the sibling probe_media tool is left for the agent to resolve.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds real context beyond that: the data source is the installed Kdenlive and it merges system plus user custom presets. It does not say what happens if Kdenlive is not installed, which is the only notable gap.

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?

Two short sentences, zero waste, with the resource and scope front-loaded and the downstream routing hint placed after. Every clause carries information an agent can act on.

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?

With an output schema present, return values need no explanation, and the description still previews the key fields. For a no-parameter read tool this is essentially complete, though it could note the failure mode when Kdenlive is absent or point to diagnose_environment.

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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it does not waste space inventing parameter guidance.

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 ('List the render presets') and scopes it precisely to the installed Kdenlive, distinguishing system presets from user custom presets. It also states the returned fields (group and file extension), so an agent knows exactly what it gets without opening the output schema.

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?

The second sentence, 'Use a returned name with render_project,' explicitly routes the agent to the downstream sibling and the condition that selects it. There is no explicit when-not guidance, but for a zero-parameter discovery tool the usage context is effectively unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, closed-world behavior, so the description is not required to prove safety. It adds real behavioral value beyond that: URL inputs are refused, and crucially 'probing reads headers and does not prove that every frame decodes,' which warns the agent against over-trusting a successful probe.

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?

Three sentences, front-loaded with purpose, then constraints, then the important caveat. Every clause carries information an agent needs; nothing is padding.

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?

For a one-parameter read tool with an output schema, this covers what matters: inputs, scope limits, and the interpretation caveat. It does not say what happens on a missing/unreadable file (error shape) or whether the probe is expensive for large files, both minor gaps here.

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?

There is a single parameter with 100% schema description coverage, and the schema already states 'Absolute path of a local media file.' The description's '(absolute path)' restates rather than extends that, so this is the baseline case where the schema does the work.

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?

States a specific verb+resource ('Check one local media file') and enumerates exactly what comes back: duration, streams, codecs, dimensions, rational frame rate, sample rate, channels, rotation. That output list distinguishes it from siblings like list_project_media or get_timeline, which operate on collections rather than a single file.

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?

Usage conditions are clear and concrete: one file only, absolute path required, local files only, URLs refused. It does not explicitly route the agent to a sibling (e.g., 'use list_project_media to discover paths first'), so the alternative-selection guidance is implicit rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses blocking behavior, the timeout escape hatch, ffprobe validation of the output, refusal conditions (existing output, unknown presets, missing media), and the important safety detail that the old file is replaced only after a successful validated render. This explains why destructiveHint=true despite 'Never modifies the project or its media' — the destruction is limited to the output path.

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?

Front-loaded with the core action and mechanism, then proceeds to guarantees and refusal conditions in a logical order. Four dense sentences with little waste, though the refusal enumeration is slightly packed and could be split for faster scanning.

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?

For a long-running, potentially destructive render tool, the description covers blocking semantics, timeout, validation, refusal/overwrite safety, and the unsaved-changes caveat. With an output schema present, no return-value explanation is needed, so nothing an agent needs to invoke this correctly is missing.

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 coverage is 100%, so the baseline would be 3, but the description adds real semantics: timeout_seconds truncates the blocking render, overwrite=true is required for an existing output and replacement is deferred until validation succeeds, and unknown presets are refused. These constraints are not inferable from the schema alone.

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?

States a specific verb and resource ('Render a Kdenlive project to a new local file') plus the mechanism (kdenlive --render) and post-step (ffprobe validation). An agent can distinguish it from siblings like inspect_project, list_render_presets or probe_media without opening any schema.

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?

Gives clear usage context: it blocks until completion or timeout, and it explicitly covers the edge case that it renders the on-disk file rather than unsaved changes in a running Kdenlive. It does not explicitly name an alternative sibling to call first (e.g., list_render_presets for preset discovery, which only appears in the schema), so the when-to-use-vs-alternative guidance is clear but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.