Search podcast transcripts for a query and play the matching audio segment to hear where a topic is discussed.
Search transcript for query and play that span (NL: play where they talk about X).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| dry_run | No | ||
| rerender | No | ||
| processed | No | ||
| match_index | No | ||
| padding_sec | No | ||
| project_path | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.1Input schema / properties / project_path / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / project_path / defaultAdded value: +nullInput schema / properties / project_path / typeRemoved value: -"string"Input schema / requiredPrevious value: -[
- "project_path",
- "query"
-]New value: +[
+ "query"
+]v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden, and it declares only that audio is played. It says nothing about the side effects of playback on session state, what dry_run/rerender/processed toggle, or whether the play action interrupts ongoing playback — significant gaps for a 7-parameter tool with a playback side effect.
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?
A single tight sentence with the core action front-loaded and a parenthetical NL example, with no filler. It is efficient, though the extreme compression is part of why so much stays unexplained.
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?
An output schema exists so return shapes need not be documented, but for a tool with seven parameters at 0% schema coverage, no annotations, and a playback side effect, the description leaves the agent without enough to invoke it correctly beyond the required query.
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% and the description explains only 'query'. The six remaining parameters (dry_run, rerender, processed, match_index, padding_sec, project_path) are bare titles in the schema and are not clarified, so an agent cannot tell how to pick a match or control the padding/rendering behavior from the text.
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 names a specific compound action (search transcript, then play the matching span) and the resource (transcript span). The mention of playback loosely differentiates it from search_transcript_tool, but it never names the sibling explicitly, so an agent must infer the split from the verb alone.
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 natural-language gloss 'play where they talk about X' implies the intended use case, but there is no statement of when to choose this over search_transcript_tool (search only) or play_audio_tool (playback only), and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.