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

With zero annotations provided, the description carries the entire burden of behavioral disclosure — and it delivers. It discloses the return shape (outputs array with either inline content or a 1-hour time-limited download_url), the sizing rule for inline versus URL delivery, the derivative-job state machine (processing vs. terminal source_expired), and the recovery behavior (retrieving fresh challenges when state was lost). Nothing about the tool's behavior is left to inference.

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, opening with purpose and output structure before moving to polling cadence. It runs long (roughly 250 words), but most sentences earn their place given the tool's complexity. The derivative-job and state-recovery sections could be tightened or split with headers for readability, which keeps this at a 4 rather than a 5.

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 a tool with no output schema, no annotations, and substantial behavioral complexity (derivative jobs, state recovery, multiple formats), the description is remarkably complete. It covers the return format fully, polling timing, size-based delivery rules, derivative-job exceptions, and recovery usage. An agent has everything it needs to call this correctly across all scenarios.

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 schema already documents both parameters, giving a baseline of 3. The description nonetheless adds genuine meaning: it explains that txt/vtt are derived from the stored SRT, that json is v1 (segments only) while words is v2 (segments + per-word timestamps), and how format interacts with the inline-vs-URL delivery decision. The one gap is that it does not directly restate the job_id requirement, though that is already well covered by 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?

The description opens with a specific verb+resource: 'Check the status of a transcribe or summarize job.' It goes well beyond a one-line purpose, detailing exactly what the tool returns (current state, outputs array) and which outputs come inline versus via download URL. Against its siblings (transcribe, summarize, complete_upload, extract_clip), its role as the status-poller is unambiguous.

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 gives explicit invocation guidance: 'Poll this periodically after calling complete_upload — wait at least 60 seconds between checks,' with concrete timing expectations for short versus long files. It explicitly carves out when the tool behaves differently (derivative jobs like extract_clip, publish_youtube have no upload step and no awaiting_upload states) and even instructs how to use it for state recovery. This is proactive, actionable usage guidance with clear conditions.

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