get_transcript

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

Annotations carry readOnlyHint=true, which the description does not contradict — retrieving a transcript is consistent with a read operation. The description adds genuine behavioral value beyond the annotation: it discloses that long texts are paginated and that the next chunk is fetched via offset=next_offset, and it reveals the output contains timestamps and a WAV path. This is meaningful context the annotation does not provide.

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 sentences with the core purpose front-loaded and the pagination detail placed second. No wasted words; the timestamps format and pagination behavior each earn their place. Only a small efficiency gain would be possible by trimming redundancy.

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 retrieval tool with readOnlyHint annotation and no output schema, the description covers the return content (transcript, timestamps, WAV path) and the pagination mechanism. It is incomplete on what 'id' should be and on prerequisites (e.g., requiring a prior transcribe_recording). The return format is described but the parameter contract is not fully specified.

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 0%, so the description carries the full burden of explaining the two parameters. It partially compensates by explaining offset's role in pagination (next_offset), but it never defines what 'id' refers to (meeting ID? transcript ID?) or its required format. With no schema help, leaving a required parameter undocumented is a notable gap.

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 clearly states the resource (transcript of a meeting) and the content delivered (timestamps in HH:MM:SS format and WAV path). The verb is implied rather than explicit ('Расшифровка' = transcript), but the intent to retrieve is unambiguous. It partially distinguishes from the sibling transcribe_recording, which is about creating a transcript, while this one retrieves it.

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?

There is no explicit guidance on when to use this tool versus its siblings. The natural counterpart transcribe_recording (creation vs. retrieval) is never named, nor is any precondition stated (e.g., that a transcript must already exist). The only usage hint is implicit in the pagination note about offset, which is behavioral rather than selection guidance.

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