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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine beyond-schema context: 'The text is only processed for this response' (statelessness/privacy) and that the corrected SRT is optional and what it fixes (encoding, overlaps trimmed, long lines split, short subtitles extended). It omits the 200k character input ceiling, which is a real practical constraint.

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 the verb and outcome, with the check list consolidated into one dense enumeration rather than scattered. The long middle sentence is list-heavy but every item is a distinct check the agent may need to interpret results against.

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?

There is no output schema, so the description must convey the return shape, and it does at a high level ('lists problems per subtitle', plus an optional corrected SRT). An agent knows what comes back and why, though the exact issue-object structure (field names, per-line references) is left unstated.

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 baseline is 3; the description earns an extra point by tying checks to parameters — 'gaps shorter than the minimum frame gap', 'reading speed (characters per second)', 'line length, line count' — and by explaining what include_fixed_srt actually returns. It does not mention fps or the preset rule sets, but the schema documents those thoroughly.

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 (checks/validates) and resource (pasted SRT or WebVTT subtitle text) and enumerates exactly what classes of problems it reports: timing overlaps, gaps, CPS, line length/count, duration, and encoding mojibake. The purpose is unmistakable and clearly distinct from the sibling tools (bitrate, safe zone, text position).

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 implies usage ('pasted SRT or WebVTT subtitle text') and notes the optional corrected-SRT output, so an agent can infer this is the validation entry point. But it never states when to prefer it over an alternative, nor any exclusion such as file-path input vs pasted text, or when to enable the preset/fps tuning.

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