Execute a published flow template with supplied inputs to generate media through ElevenLabs, requiring paid-operation approval because cost may be unknown.
Run a published template. Because its internal steps can generate media, cost is treated as unknown and both paid-operation gates are required.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | ||
| allow_paid | No | ||
| version_id | No | ||
| template_id | Yes | ||
| allow_unknown_cost | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load: it usefully discloses that cost is treated as unknown because steps can generate media, and that two gates must be set. It stops short of stating side effects, whether the run is asynchronous, what is returned, or whether prior runs are affected.
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 tight sentences with the core action front-loaded and the cost caveat immediately after. No filler or repetition.
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?
A mutation tool with no annotations, no output schema, five parameters, a nested free-form object, and 0% schema description coverage needs far more: the required input contract, what a run produces, and how failures or unknown-cost rejection surface are all missing.
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% across five parameters, including a free-form nested 'inputs' object, so the description must compensate and largely does not. It references 'both paid-operation gates' without naming allow_paid and allow_unknown_cost, and says nothing about template_id, version_id, or the shape of inputs.
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 and resource ('Run a published template'), which separates it from siblings like list_flow_templates and get_flow_template. It does not explicitly name those siblings or clarify the difference from get_flow_run, but the action itself is unambiguous.
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?
Implies the template must already be published and that cost considerations apply, and the note that 'both paid-operation gates are required' tells the agent a precondition exists. However, it never says when to prefer this over direct generation tools, nor what happens if the gates are omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.