Retrieve the progress, failure details, output files, and insertion receipt of a drum transcription job. Use it to verify completion before manually inserting results into REAPER.
Read a drum transcription job's progress, failure, output files and insertion receipt. A completed analysis has not inserted anything into REAPER.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Changes observed during successful MCP inspections.
v3.21.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already marks this as read-only; the description adds concrete context by enumerating what is read (progress, failure, output files, insertion receipt) and explicitly states the tool does not insert into REAPER. This goes beyond the annotation without contradicting it.
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 short sentences that front-load the read action and then clarify a key side-effect fact. No filler or repetition of schema 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?
For a one-parameter read-only tool, the description covers what the tool reports and its non-mutating behavior. It could add a hint that job_id comes from transcribe_drums, but the core calling context is otherwise complete.
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?
With schema coverage at 0%, the description must carry parameter meaning. It only refers to 'a drum transcription job' without explaining job_id's format, source, or relationship to transcribe_drums, so the agent is left to infer the obvious identifier role.
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 ('a drum transcription job's progress, failure, output files and insertion receipt'). The second sentence explicitly distinguishes it from insertion tools by noting no REAPER insertion occurs, so an agent can separate this from transcribe_drums/insert_drum_transcription.
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 makes the use case clear: retrieve status, errors, outputs, and receipt for a transcription job. It does not explicitly name alternatives or when-not-to-use, though the 'has not inserted anything into REAPER' clause implies it is a read-side check before any insertion step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.