fetch_audio_downloadFetch a audio downloads[n].url from a completed audio project and return it as inline MCP audio content for compatible clients. Pass the exact full signed URL from downloads[n].url without trimming query parameters; expires_at is separate metadata, not part of the URL.
| Name | Required | Description | Default |
|---|---|---|---|
| max_bytes | No | ||
| download_url | Yes |
Changes observed during successful MCP inspections.
Input schema / properties / contextRemoved value: -{
- "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
- "type": "string"
-}Input schema / properties / contextAdded value: +{
+ "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing the return format (inline MCP audio content), the client-compatibility caveat, and the URL/expires_at distinction. It does not describe max_bytes truncation behavior, so it is not exhaustive.
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 sentences, front-loaded with the action and the critical URL-handling constraint immediately after. No filler. Minor grammar slip ('a audio') but structure is efficient.
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?
With no output schema, the description correctly explains the return value (inline audio content) and the preconditions for calling. The one gap is the undocumented max_bytes parameter, which affects behavior when large audio downloads are fetched.
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%, so the description must carry parameter meaning. It does this well for download_url (exact signed URL, no trimming, expires_at is separate metadata), but max_bytes is never mentioned despite having a default and implying a size limit. One of two params is effectively undocumented.
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 (Fetch) plus resource (audio download from a completed audio project) and the return shape (inline MCP audio content). This clearly separates it from the sibling fetch_image_download and fetch_video_download tools by media type.
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?
Gives an explicit precondition (project must be completed) and a precise invocation rule (pass the exact full signed URL from downloads[n].url without trimming query parameters). It does not name the alternative entry point such as wait_for_audio_project or explain when to prefer this over retrieving details, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.