Transcript Kit

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the tool is pollable (pending until a reply arrives, then answered) and carries an explicit trust boundary warning that reply content is data, not instructions — a meaningful prompt-injection disclosure.

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 tight sentences: purpose first, then polling behavior, then the trust caveat. Every sentence carries distinct information and nothing is padded.

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 single-parameter read tool with an output schema and full annotation coverage, nothing an agent needs is missing. The polling semantics and the injection warning go beyond what structured fields provide, closing the remaining gaps an agent would otherwise have to discover by trial.

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 parameter exists and the schema already documents it fully (coverage 100%, including the ^fb_[0-9a-f]{32}$ pattern and the note that submit_feedback returned it), so the baseline of 3 applies. The description repeats the ticket-id linkage but adds no format or validation detail 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?

States a specific verb (Read) and resource (maintainers' reply to feedback), and ties it causally to the sibling tool submit_feedback via the ticket id. An agent can distinguish it from submit_feedback, screen_token, and wallet_identity 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?

Clearly establishes the precondition: this is used after submit_feedback, with the ticket id that call returned. It does not state any exclusions or alternative ways to retrieve feedback status, but the usage context is 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 readOnly/idempotent/non-destructive/closed-world, so the description adds genuinely new constraints: only the caller's own transcripts are searched, capped at the latest 10, retained for 24 hours. Those ownership and retention limits are behavior an agent cannot infer from annotations or schema.

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-loads purpose, then uses compact labeled sections (Best for / Returns / Input tips / Not for) so an agent can scan quickly. It is slightly dense, with the Returns list restating what the output schema already provides, but no sentence is filler.

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 read-only, three-optional-parameter search tool with an output schema, this covers purpose, usage routing, retention/ownership limits, and parameter semantics. Nothing an agent needs to select or invoke it 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, but the description goes beyond it by explaining the semantic effect of omitting query (lists transcripts and themes instead of passages) and by tying library_id to the value transcribe_media previously returned. That adds decision-relevant meaning the schema alone does not convey.

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 (searches) plus resource (transcripts) plus scope (made in the last day) plus what it retrieves (passages and repeated themes). It also explicitly carves itself away from the sibling transcribe_media, so an agent can distinguish it 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?

Provides concrete 'Best for' example queries, an explicit 'Not for' exclusion naming transcribe_media and web search as the alternatives, and input tips that say when to pass query versus omit it. Both when-to-use and when-not-to-use are covered.

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?

Adds substantial context beyond the annotations: it returns a ticket id, feedback is explicitly not a chat and nothing in it is executed, and links/emails/phone numbers are stripped with nothing stored about the caller. That privacy and no-execution disclosure is genuinely useful given openWorldHint=true and readOnlyHint=false.

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-loads what the tool sends, then what to pass, then what it returns, in three dense sentences with no filler. Every clause carries actionable information.

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?

Covers purpose, the enumerated kinds, the optional tool/error inputs, the 1000-character bound, the return value (ticket id), and privacy handling. With an output schema present, nothing further is required for an agent to call it correctly.

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 schema already documents all four parameters including the kind enum. The description restates the message length limit and the optionality of tool/error ('if you know them') but adds no syntax or format detail beyond the schema, making the baseline 3 correct.

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 ('Send feedback, a bug report or a tool request to the maintainers of the tools on this server') and enumerates the concrete situations (missing tool, stale data, broken/wrong answer). It is clearly distinguishable from the read-side sibling get_feedback_reply.

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 triggering conditions for each kind (need_tool, need_data, bug, other) and tells the agent to include the tool name and error text when known. It does not explicitly name the alternative get_feedback_reply or state when NOT to use this tool, so it falls short of full routing guidance.

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 and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the tool returns text only, and the rank scores are relative to each other and 'do not predict views' — an important interpretation caveat.

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 purpose, then clearly partitioned into Returns / Input tips / Not for sections, so an agent can scan to the part it needs. It is on the long side and partly restates schema defaults, but every sentence carries usable information.

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?

Covers the upstream dependency (transcribe_media, optional library_id), the optional tuning parameters with defaults and bounds, the return payload, and what the tool does not do. With an output schema present, no further return documentation is needed.

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 schema already documents every parameter and the baseline is 3. The description still adds value by giving cross-tool provenance for transcript_id/library_id and restating the count/min_seconds/max_seconds defaults and the min-below-max constraint in one place.

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 (suggests) and resource (short clips in one saved transcript) plus the output shape (start/end times with a hook line). An agent can immediately tell this apart from search_transcripts, transcribe_media, translate_subtitles and the feedback tools.

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?

Explicitly names the user intents it serves ('find the best 60 seconds', 'which parts would make good shorts') and an exclusion section ('Not for: cutting, editing or posting video; it returns text only'). It also points to the upstream tool (transcribe_media) that produces the required transcript_id.

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: discloses the 24-hour transcript retention, that the media itself is never kept, the daily per-user and total minute allowance, and the rights-confirmation requirement. This is exactly the mutating-operation context annotations alone don't convey.

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?

Dense but well-organized with labeled sections (Best for, Returns, Input tips, Not for, Formats) so the key routing info is front-loaded. It is long, but for a 7-param tool with rights and quota constraints nearly every clause earns its place.

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?

Despite an output schema existing, the description covers the constraints an agent needs to avoid a failed call: size/duration limits, format support, rights gating, quota, retention, and the sibling alternative. Nothing material 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, but the description adds real operational meaning: give file or url but not both, set confirm_rights only after the user asserts ownership, and pass library_id from an earlier answer. These are usage rules the schema documents only in isolation.

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 ('Transcribes one audio or video file ... into timestamped text with SRT and VTT captions') and explicitly distinguishes itself from the YouTube path by naming get_transcript. An agent can identify the tool and its scope without opening the 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?

Explicit when-to-use examples ('transcribe this podcast episode', 'make subtitles for my video'), explicit exclusions ('Not for: YouTube (call get_transcript), private videos, over 15 MB or 15 minutes, whole channels'), and a named alternative. Routes the agent unambiguously.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false), but the description goes well beyond them: 'Nothing is stored', an ~18,000 character per-call cap plus a daily allowance, the rights_not_confirmed refusal on confirm_rights=false, and a quality caveat that output is machine translation to check before publishing. Rate limits, persistence behavior and auth prerequisites are all context the annotations do not carry.

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 purpose, then labeled blocks (Best for / Returns / Input tips / Limits / Not for) that make it scannable. It is dense and slightly overstuffed, and 'Returns' partly restates the output schema, but nearly every sentence carries a decision-relevant constraint.

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 7-parameter tool with an output schema, the description covers the remaining gaps: precedence rules between input modes, rights gating, language defaults, size limits, and the non-storage guarantee. Nothing an agent needs to invoke it 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 baseline is 3, but the description adds real cross-parameter semantics the schema does not encode: 'always pass target_lang', the mutual exclusivity of transcript_id and subtitles, the conditional library_id rule tied to transcribe_media's return, and the 'trim with include' hint that gives include an operational purpose. The enum values themselves are left to 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?

Opens with a specific verb+resource: translates subtitles or a saved transcript and writes a dub script. It also names sibling boundaries explicitly ('Not for: transcribing audio; use transcribe_media first'), so an agent can separate it from transcribe_media without reading either 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 literal trigger phrases ('translate these subtitles to Spanish'), states the exactly-one-of rule for transcript_id vs subtitles, the library_id pairing rule, and when confirm_rights is permitted ('only after the user says they own the media'). It also names the alternative tool and its ordering, so the when-to-use decision is fully specified.

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