Retrieve a transcription by ID or request ID to get full text and extracted comments once complete, or check processing status and errors.
Get a transcription by its ID or requestId. Returns the full transcription text and any extracted comments when completed, or status/error info if still processing or failed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Transcription ID | |
| requestId | No | Transcription job request ID |
Changes observed during successful MCP inspections.
v2.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds genuinely non-redundant behavioral detail: the response shape varies by state (full text plus extracted comments when completed, status/error otherwise), which is important for an agent deciding whether to retry or poll. It does not note whether a lookup by a nonexistent ID errors or returns null.
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, no filler. The retrieval contract is front-loaded and the state-dependent return behavior follows immediately; 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?
With no output schema, the description correctly carries the burden of explaining return values across states, and annotations cover the safety profile. The one real gap is that both parameters are optional (required: 0) yet the description never says what happens if neither is provided, nor whether it polls or fails while processing.
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 both parameters are already documented as 'Transcription ID' and 'Transcription job request ID'. The description only restates that lookup is possible by either key, adding no syntax or precedence detail (e.g., which wins if both are supplied). Baseline 3 applies when the schema does the heavy lifting.
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 states a specific verb and resource (retrieve a transcription) and specifies the two lookup keys, which cleanly separates it from list_transcriptions and search_transcriptions. It stops short of naming a sibling explicitly or describing the broader transcribe workflow, so it earns a solid 4 rather than a 5.
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: call this after a transcription exists, using either the transcription ID or the job request ID. There is no explicit when-to-use/when-not guidance, no mention of alternatives such as list_transcriptions for discovering IDs, and no guidance on polling when the job is still processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.