Search, draft and manage your podcast workspace from your agent.
Scored across 3 tools
The three tools occupy distinct roles: search discovers capabilities/schemas, execute runs exactly one capability, and ask_podmule provides read-only advisory answers. The main fuzziness is between ask_podmule and execute for ambiguous action requests, but the descriptions explicitly cross-reference each other to route correctly.
All names are lowercase snake_case, but the pattern is mixed: 'ask_podmule' uses a verb+domain form while 'execute' and 'search' are bare verbs with no object. Readable and predictable enough, but not a consistent verb_noun convention.
Three tools is a deliberate gateway/facade design, and each earns its place (discover, act, advise). It sits at the thin end of the range, but the surface is coherent for a server that proxies a larger capability catalog rather than exposing it directly.
Discovery, execution, and advisory paths are all covered, with search filling the schema/enumeration gap and execute handling reads plus an allowlisted write pilot. The read-only-by-default policy blocks most writes and dangerous operations, which is a stated design constraint rather than a missing capability, though it caps writers' coverage.
Ask PodMule for a concise read-only domain answer or an advisory route plan. Use this for quick questions, summaries, diagnostics, drafting, "what should I do?" prompts, and ambiguous action requests. This tool never performs writes. For exact capability contracts use search; for one selected action (read or write) use execute.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| request | Yes | ||
| response_format | No |
| Name | Required | Description |
|---|---|---|
| error | No | |
| links | No | |
| route | No | |
| answer | No | |
| status | Yes | |
| citations | No | |
| suggested_actions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'This tool never performs writes,' which is consistent with the annotations readOnlyHint=true and destructiveHint=false. It goes beyond the annotations by characterizing the nature of responses (concise, advisory) and noting it covers 'ambiguous action requests,' which implies it may return a route plan rather than executing actions. This adds value beyond the structured data 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?
The description is two sentences, tightly packed with useful information. It front-loads the core purpose and immediately follows with use cases and sibling differentiations. No filler or redundant phrasing; every sentence 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?
Given the tool's advisory nature, the description is sufficient: it clarifies read-only behavior, specifies use cases, and points to siblings. The presence of an output schema reduces the need to describe return values. However, it could briefly mention that the 'request' parameter should be a natural-language prompt or a specific format expectation, but the 'advisory' framing implies this. For a simple tool with clear annotations and output schema, this is nearly 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 description coverage at 0%, the description must compensate for parameter meaning. While it doesn't detail each parameter, it conveys the overall intent: 'request' is the main prompt, 'response_format' determines output type (answer, route_plan, json), and 'context' provides optional scoping. The description's use of 'advisory route plan' implies that response_format='route_plan' is for guidance. However, it could be more explicit about how 'context' parameters are used, but the high-level purpose is clear.
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 tool's purpose: to 'Ask PodMule for a concise read-only domain answer or an advisory route plan.' It lists specific use cases (quick questions, summaries, diagnostics, drafting, advisory prompts) and distinguishes itself from siblings by noting it does not perform writes, unlike execute. This is a specific verb+resource with clear differentiation.
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?
Explicit guidance is provided: 'Use this for quick questions, summaries, diagnostics, drafting, "what should I do?" prompts, and ambiguous action requests.' It also gives exclusions: 'For exact capability contracts use search; for one selected action (read or write) use execute.' This clearly states when to use this tool versus alternatives and includes what not to use it for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one OAuth-visible PodMule capability. Reads run directly. Modern MCP 2026 clients with MRTR support may preview and affirm the allowlisted update_episode pilot; legacy clients and every other MCP write remain read-only. Dangerous writes are always blocked — do those in the PodMule app. Use ask_podmule for ambiguous requests and search for exact schemas.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| input | No |
| Name | Required | Description |
|---|---|---|
| error | No | |
| links | No | |
| result | No | |
| status | Yes | |
| invocation_id | No | |
| writes_enabled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give readOnlyHint=false, destructiveHint=false, openWorldHint=false, but the description discloses a nuanced write policy: read passthrough, a specific allowlisted write pilot gated on client capability, a legacy-client read-only fallback, and hard blocking of dangerous writes. This goes well beyond the annotations and is consistent with them, so there is no contradiction.
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?
Four tightly packed sentences, front-loaded with the core action before the write-policy caveats and routing. Dense with domain jargon (MRTR) but no filler, and each sentence carries distinct 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?
An output schema exists, so return values need not be described. For a generic dispatcher with 0% schema coverage, the description compensates reasonably by explaining the write/read policy and explicitly pointing to search for exact schemas, leaving only the parameter-level detail thin.
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 two parameters (name, input) are bare strings/objects, so the description carries the full explanatory burden. It only implies that name identifies a capability and defers real parameter semantics to the sibling search tool, adding little beyond the schema itself.
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 clear verb and resource: 'Execute one OAuth-visible PodMule capability.' The resource is abstract (a named capability) since this is a generic dispatcher, but the description distinguishes itself from the ask_podmule and search siblings by routing ambiguous and schema-lookup needs away. No sibling-confusion remains, though the tool's exact remit is inherently broad.
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?
Explicit when/when-not behavior and alternatives: reads run directly, writes are limited to the allowlisted update_episode pilot on modern MRTR-capable clients, dangerous writes must be done in the PodMule app, ambiguous requests go to ask_podmule, and exact schemas come from search. The routing conditions are spelled out rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search available PodMule capabilities for this OAuth token. Use this when you need the exact capability name or schema before calling execute. For ambiguous domain requests, call ask_podmule first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| detail | No |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| matches | Yes | |
| writes_enabled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds that the search is scoped to capabilities for the current OAuth token, which is useful context. However, it doesn't describe pagination behavior for results, whether the search is full-text or exact match, or how detail='schema' affects the output structure. With the annotations covering the safety profile, a 3 is appropriate.
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?
The description is two sentences: first states purpose, second gives usage guidelines. Every sentence earns its place with no redundancy. It could be improved by front-loading the most critical info (perhaps moving the sibling tool reference earlier), but it's efficient and clear.
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?
Given the tool has an output schema and annotations providing safety profile, the description adequately covers purpose and usage guidance. The 3 parameters have inline constraints in the schema, and the description hints at their purpose (query for capability names, detail for schema retrieval). The mention of 'ask_podmule' as a fallback compensates for potential ambiguity. A slight gap is that it doesn't clarify if 'search' is prefix-based, fuzzy, or exact, but this is acceptable given the clear usage guidance.
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 0%, so the description must compensate for parameter meaning. The description itself only indirectly references parameters (the need for a 'capability name' implies 'query'), but the context signals note 0% coverage. However, the output schema exists (not shown here) which may clarify parameter effects, and the description's brief guidance helps the agent understand the tool's core parameter (query for capability names). The schema's parameters (limit, query, detail) have inline constraints (max/min, enum) but no textual descriptions, so the description's lack of explicit param talk is a gap, but acceptable given the concise format.
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 uses a specific verb 'search' and resource 'available PodMule capabilities for this OAuth token', clearly stating what the tool does. It acknowledges the sibling tool 'execute' by mentioning it needs the exact capability name, which helps distinguish its purpose.
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 explicitly states when to use this tool ('when you need the exact capability name or schema before calling execute') and provides guidance for ambiguous domains ('call ask_podmule first'). It clearly distinguishes between its two sibling tools and gives conditional usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ask_podmuleexecutesearchPodcast intelligence for agents: transcripts, clips, speaker diarization, mention tracking.
Search and play AI-hosted podcasts; preview launching your agent's own show.
Podcast booking-intelligence MCP server: search shows, match profiles, draft pitches, read replies.
Prepare podcast rundowns and private drafts; review saved transcripts in your linked Studio.
Add one secure layer between your agents and this server.
