Generate an AI podcast episode from a topic or full script. Returns a job ticket to poll for completion.
AI podcast episode from a topic or a full script ($0.50 USDC/call). ASYNC — returns a job ticket; poll with x402_poll_job (job_type 'media').
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Episode topic (or provide script) | |
| script | No | Full script (or provide topic) |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the async job-ticket return, the required polling destination and job type, and the USDC cost per call. It does not cover failure modes or permission requirements, but it communicates the core behavioral traits needed to invoke and track the job.
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 with no filler. It front-loads the purpose and cost, then immediately gives the async polling behavior and the exact job_type to use.
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 simple two-parameter async tool with no output schema, the description supplies the essential workflow: input, cost, job ticket, and polling instructions. It could add authentication or failure details, but the referenced poll tool and schema cover most of what an agent needs to call and track the job.
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 100%, and the schema already documents topic and script as alternatives. The description restates the 'topic or full script' relationship but adds no parameter-level detail such as length limits, mutual-exclusion enforcement, or format requirements.
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 identifies the tool's function as producing an AI podcast episode from either a topic or a full script. It names the resource and input mode, and the async mention helps distinguish it from related media tools like x402_video or x402_tts, though it does not explicitly contrast them.
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?
It gives clear usage context: call this to create a podcast from a topic or script, then poll with x402_poll_job using job_type 'media'. It does not state when not to use it or name alternatives, but among siblings there is no direct podcast equivalent, and the async workflow is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.