Skip to main content
Glama

Repurpose a transcript

repurpose_transcript
DestructiveIdempotent

Starts one billable, idempotent content transformation for a completed transcript.

Input Schema

NameRequiredDescriptionDefault
modeYes
idempotencyKeyYes
transcriptionIdYes

Output Schema

NameRequiredDescriptionDefault
statusYes
operationIdYes
submittedAtYes
retryAfterSecondsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior4/5

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

Adds real value beyond annotations: 'billable' discloses a cost consequence that no annotation encodes, and 'starts' signals asynchronous kickoff (implying polling via get_job_status). 'Idempotent' merely restates idempotentHint, and the description never explains what makes the call destructive (destructiveHint: true) or what the openWorld access entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tightly-packed sentence with no filler; cost and idempotency are front-loaded as qualifiers on the verb.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be explained, and the async+billable framing is present. But for a destructive, open-world mutation with zero parameter documentation, the description should say what mode options produce and what happens on idempotencyKey reuse — that gap is material.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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 for all three required parameters and discharges none of it: no explanation of the idempotencyKey reuse/conflict contract, no description of the mode enum values or their outputs, and no note on the transcriptionId format beyond the regex.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Starts') and resource ('content transformation for a completed transcript'), plus the prerequisite that the transcript must be completed. However, 'content transformation' is vague about what is actually produced — the mode enum (show-notes, thread, blog, quotes) is nowhere reflected in the description — and it does not differentiate itself from nearby siblings like summarize_transcript or export_transcript.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance and no named alternative. The only implicit routing cue is 'completed transcript', which implies an eligibility precondition, but an agent choosing among summarize_transcript, export_transcript, translate_transcript and this tool gets no help.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.