Measures a master or track and proposes a mastering chain without making perceptual claims.
Measure master or track, propose mastering chain, no perceptual claims
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| target | No | ||
| seconds | No |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds no behavioral detail beyond a disclaimer. It never says whether 'propose' writes state, what the measurement covers (LUFS, peak?), how long it takes, or what a proposal contains — and 'measure' superficially suggests a read-only operation while the annotation says otherwise, leaving the agent unsure of side effects.
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?
Very short and front-loaded, so nothing is wasted, but the brevity comes at the cost of clarity: three dangling clauses separated by commas read as notes rather than a self-contained instruction.
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, zero parameter documentation, and thin annotations, the description needed to explain what is measured, what the proposal looks like, and what if anything changes. None of that is present, so an agent could not reliably invoke this tool without experimentation.
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 the full load for source, target, and seconds — yet it only obliquely implies 'master or track' via the resource nouns, with no mention of accepted formats for the oneOf source, what target means, or the 1–30 second analysis window.
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 fragment 'Measure master or track' names a verb and two resources, and 'propose mastering chain' hints at a second output, but the phrasing is telegraphic — it's unclear whether this analyzes audio, writes anything, or returns a chain proposal. It does not distinguish itself from close siblings master_check, master_targets, and master_build_chain.
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 when-to-use context is given, and no alternative is named even though master_check, master_targets, and master_build_chain occupy adjacent territory. 'No perceptual claims' is a caveat, not guidance about when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.