Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, non-destructive), and the description adds real value beyond them: no processing, fast/cheap, and critically what is NOT measured (true peak, loudness range) with a pointer to get_job. That negative scoping is genuinely useful behavioral disclosure.

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?

Four tight sentences, front-loaded with the measurement scope followed by cost/workflow and the negative note. Every sentence earns its place; no filler.

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?

An output schema exists, so return values need not be re-explained, and the description covers what is measured, latency/cost, when to invoke, and the true-peak/loudness-range exclusion. Nothing an agent needs to call it correctly is 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?

Only one parameter, and the schema description coverage is 100% with a detailed audio_url description covering formats and share-link resolution. The description adds nothing about the parameter, so the baseline 3 applies — the schema does all the work here.

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 (Measure) and resource (track) and enumerates the exact metrics returned: integrated LUFS, sample peak, duration, sample rate, stereo correlation. The explicit contrast with processing-oriented siblings like master_track ('without processing') lets an agent route correctly without opening schemas.

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 clear workflow context — run this before choosing a preset — plus cost/latency signals ('Free, a couple of seconds'). It also diverts the agent for true peak/loudness range to get_job. It does not explicitly name master_track as the alternative step, keeping it from a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly=false, destructive=false, openWorld=true. The description adds cost modeling (N credits for N tracks, not one, or N free runs), resource caps (10 tracks, 100 MB/file, 300 MB/call) attributed to server memory, runtime expectations ('takes minutes'), return shape (one job id per track), and the dry_run escape hatch. This is rich behavioral context well beyond the annotations.

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?

Front-loaded with purpose, then cost, then the highest-value semantic (album_mode), then limits and workflow. Every sentence carries information, though the batching advice and repeated target_lufs phrasing make it slightly longer than necessary.

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?

An output schema exists and annotations carry the safety profile, yet the description still supplies the polling workflow (get_job per job id), cost, caps, and timing needed to call this batch mutation correctly. Nothing an agent needs is 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 coverage is 88%, so baseline is 3, but the description adds real meaning: album_mode is explained with the relative-leveling behavior ('the loudest hits the target exactly, the others keep their offsets, so a quiet interlude is not inflated'), and credits are tied to audio_urls count. Other params (style, bitrate, out_format) are left entirely to the schema.

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 with scope: 'Master up to 10 tracks in one call with the same settings.' An agent can distinguish it from the sibling master_track (single) purely from the description.

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 clear context for use: batching up to 10 tracks sharing settings, album vs unrelated singles via album_mode, and routes polling to get_job and previewing to dry_run. It never explicitly names master_track as the single-track alternative, so routing between the two is inferred rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/destructive/openWorld, so the safety profile is covered. The description adds real behavioral context beyond them: the response is a point-in-time entitlement snapshot ("right now") and includes a reset schedule, which tells the agent the values are time-boxed and may need re-checking.

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 dense sentence pair: contents first, then the call-to-action ("Call before mastering"). No filler, no restatement of the tool name.

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 zero parameters, an output schema documenting the return shape, and annotations covering the safety profile, the description only needs to convey purpose and timing — which it does. It could note rate-limit or caching behavior for a quota check, but nothing essential is 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The "this caller" phrasing usefully confirms the implicit scoping that no argument is needed.

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 states a specific scope ("what this caller may do right now") and enumerates exactly what is returned: masters left today and reset time, credit balance, upload cap, and advanced-module availability. This cleanly separates it from siblings like get_service_info (service capabilities) and get_job (job status).

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?

"Call before mastering" gives an explicit pre-condition for use, which is genuinely actionable. It stops short of naming when-not to call or pointing at alternatives, but the trigger condition is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description adds genuinely new behavior: the no-credit cost model, the guarantee that loudness/tone are untouched, and the asynchronous job-id/polling contract. It does not discuss failure modes or what sensitivity changes, keeping it short of a 5.

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?

Front-loaded with the core action and no filler sentences; each clause (what is removed, what is preserved, cost, follow-up) carries information. The parenthetical artifact list makes the middle dense, but nothing is wasted.

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 3-param async job tool with annotations and an output schema, the description covers scope, cost, preservation guarantees, ethical caveat and the polling handoff. Remaining gaps are the undocumented out_format/sensitivity parameters, which the output schema cannot cover.

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 67%: audio_url is well documented and enriched with share-link resolution behavior, but out_format (enum) and sensitivity ('0-1, default server-side') are undocumented. The description adds no parameter-level detail to compensate, so it sits at the baseline.

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 ('remove the marks an AI generator leaves in the audio') and enumerates exactly what those marks are (narrow tones above 15 kHz, level jumps at block seams, fixed spectral peaks). An agent can distinguish this from analyze_track or master_track without opening any schema.

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 clear operating context: it preserves loudness and tone, it does not conceal AI provenance, it never spends a credit, and the result must be polled via get_job. It stops short of explicitly naming when to choose this over a sibling like master_track, so it is context-rich but not fully routed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: the download_url is a signed link that works without credentials and expires in about an hour, and the call is free. It does not discuss rate limits or behavior while a job is still running.

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?

Three short sentences, front-loaded with the primary purpose, followed by the preview-specific return shape and the download-link caveat. The trailing 'Free.' is terse but carries real decision-relevant cost information, so no sentence is waste.

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?

An output schema exists, so return values need not be re-explained, yet the description still flags the two things an agent would otherwise mis-handle: per-style preview results with listen links, and the signed, credential-free, time-limited download_url. With a fully documented single parameter and annotations covering safety, nothing material is 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 100% and the single job_id parameter already documents its format, pattern and provenance (master_track, clean_ai_trace, preview_styles, batch_master job_ids). The description adds nothing about the parameter, so the baseline 3 applies.

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+resource (get job status/progress/result metrics) and enumerates the exact metrics returned (after_lufs, true_peak_db, lra, platform_ready). It also scopes which job types it applies to (mastering, cleanup, preview), which cleanly separates it from siblings like check_limits or get_service_info.

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?

Usage is only implied: the agent must infer that this is the polling tool to call after master_track, clean_ai_trace or preview_styles. There is no explicit when-to-use, when-not-to-use, or statement of how long to wait between polls, though the sibling set makes the routing reasonably obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it should be called once per session, implying the result is stable and repeated calls are wasteful. Return format is left to the output schema, which exists.

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 short sentences, no filler. The content scope comes first and the call cadence second, which is the right front-loading for an agent deciding whether to invoke.

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?

An output schema exists, so return-value details need not be restated. The description covers what the tool provides, when to call it, and its read-only nature via annotations — nothing an agent needs to call this correctly is 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly does not invent parameter guidance.

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 enumerates exactly what the tool returns — service overview, free tier, credit economics, and where the rules live — which is specific enough that an agent can distinguish it from every sibling (all of which are audio-processing tools). It stops short of a clean verb+resource phrasing, but the content list 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?

"Call once at the start of a session" gives explicit timing and frequency guidance, which is exactly the when-to-use information an agent needs for an orientation tool. No alternatives are named, but none are needed since no sibling overlaps with this function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: it discloses that the tool is free and that its output is the authoritative source of preset keys. It stops short of anything else notable for a zero-side-effect list tool, which is acceptable here.

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?

Front-loaded with the resource and payload, then routing guidance, then a one-word cost note. Every clause carries selection-relevant information; nothing is redundant.

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 zero-parameter read-only list tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what it returns, why to call it instead of neighbours, and when the alternatives are better.

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?

The schema has zero parameters, so per the baseline a 4 is appropriate. There is no parameter detail the description could add; the fields it mentions (preset keys, LUFS) describe output, which the output schema already covers.

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 ('List all mastering presets') plus the payload detail ('target loudness in LUFS'). It explicitly distinguishes itself from preview_styles and get_service_info, so an agent can identify it without opening the schema.

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 when-to-use rule ('Call this to get the exact preset keys that master_track and batch_master accept') and names both alternatives with the precise condition that selects each (preview_styles for hearing 2-6 on the track, get_service_info for the wider manifest).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well past the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by disclosing the credit cost model, the free-quota fallback (1 free master/day without advanced modules), the 100 MB server-side fetch ceiling, and the asynchronous nature (job id returned, 20-60 s typical, up to 10 min with restoration). These are exactly the behavioral facts an agent needs before spending money.

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?

Five sentences with no filler, front-loaded on purpose and then cost, then the async/polling contract, then the size limit, then the dry_run recommendation. Every sentence carries information; the ordering is logical and easy to scan.

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 12-parameter, paid, asynchronous tool with an output schema, the description covers the essentials an agent needs: billing behavior, quota fallback, source fetching and size cap, and the polling/return contract. The output schema carries the return shape, so nothing critical is 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 92%, so the schema already documents nearly every parameter, including dry_run, intensity clamping, bitrate sets, and audio_url resolution. The description restates dry_run's no-charge behavior and adds the 100 MB ceiling, but contributes little parameter meaning the schema does not already carry. Baseline 3 applies when the schema does the heavy lifting.

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+resource ('Master one track') and immediately scopes it to a single track, which cleanly separates it from the batch_master sibling. The first sentence is enough for an agent to identify the operation without opening the schema.

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 clear workflow guidance: pass dry_run=true first to preview cost and settings, poll get_job after submitting, or supply webhook_url instead. It names the get_job sibling explicitly. It stops short of saying when to prefer batch_master or preview_styles over this tool, so it is clear context rather than a full alternative matrix.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the description carries real added weight: it discloses cost (FREE), a rate limit (6 per day), and what the preview actually renders (middle 24 s across 2-6 presets). It does not explain whether the call is synchronous or returns a job to poll, which is a gap given the presence of a get_job sibling.

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 short sentences, front-loaded with the action and scope, with the cost/quota parenthetical and the anti-pattern guidance packed in without waste.

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?

An output schema exists so return values need no explanation, and the description covers cost, quota, scope and selection guidance. The only notable omission is the async/job semantics of the call, which matters for a tool family that includes get_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 both parameters are already documented in the schema, including the preset default and the accepted URL forms. The description's '2-6 presets' merely restates the minItems/maxItems bounds, so baseline 3 is appropriate.

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 (master), a precisely scoped resource (the middle 24 s of the track), a count range (2-6 presets at once), and the outputs (per-preset loudness plus a listen link). An agent can immediately tell this apart from a full-length mastering sibling because the preview window and multi-preset compare are explicit.

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 a clear when-to-use rule: 'Use this instead of guessing a preset, and instead of spending a credit to try one,' which implicitly positions it against the paid mastering tools. It stops short of naming master_track/batch_master directly as the alternative, so the routing is clear but slightly inferential.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.