Inspect an audio file to retrieve its duration, format, bitrate, sample rate, channels, and codec from a local path.
Audio metadata: duration, format, bitrate, sample rate, channels and codec.
| Name | Required | Description | Default |
|---|---|---|---|
| input_path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| codec | Yes | ||
| bitrate | Yes | ||
| channels | Yes | ||
| file_bytes | Yes | ||
| format_name | Yes | ||
| sample_rate | Yes | ||
| duration_seconds | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered structurally. The description adds only the list of metadata fields, which is already implied by the output schema; it does not mention failure behavior for unsupported/corrupt files or whether the file is read in full.
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 compact fragment, front-loaded with the resource and immediately followed by the most useful detail (the field list). No filler, though it is a noun phrase rather than a sentence, which slightly weakens the framing.
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?
Complexity is low, an output schema exists so return values need no prose, and annotations cover the safety profile. The remaining gaps — what input_path accepts and supported audio formats — are left entirely unaddressed, which is the minimum-viable rather than complete level.
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 carries full burden for input_path — yet it says nothing about whether the path is absolute or relative, local-only (openWorldHint=false suggests local), or which container formats are accepted. For a single required path parameter this is a meaningful gap.
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 the resource (audio metadata) and enumerates the concrete fields returned (duration, format, bitrate, sample rate, channels, codec), which makes the tool's job unambiguous and separates it from the mutating sibling audio_convert. It never states the verb explicitly ('retrieve/read'), but the intent is clear from the field list.
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?
No guidance on when to use this versus audio_convert or video_info, and no mention of prerequisites such as the file needing to exist, be a supported format, or be locally reachable. The agent must infer all routing and preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.