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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces the 'without processing' behavior. It also adds valuable context: the tool is free, takes only a couple of seconds, and does not measure true peak and loudness range. While annotations cover safety, the description adds nuance about scope and latency, though it doesn't detail output format beyond the output schema.

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 sentences with zero wasted words. The tool's purpose and key behavioral scoping are front-loaded, and the caveat about true peak/loudness range is efficiently placed at the end.

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 simple, read-only, single-parameter tool with an output schema, the description covers purpose, usage timing, scoping limits, and cost/speed. The note about get_job also routes the agent to the correct sibling for missing measurements. 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?

Schema coverage is 100% and the single parameter is fully documented in the schema ('Public https URL of the audio file (wav/mp3/flac/m4a)'). The description doesn't add parameter-level details beyond what the schema provides, 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?

The description states a specific verb+resource combination: 'Measure integrated LUFS, sample peak, duration, sample rate and stereo correlation without processing.' It clearly distinguishes analyze_track from master_track by explicitly noting it does not process the audio.

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?

The description explicitly instructs when to use this tool ('Run this before choosing a preset') and provides an exclusion by noting what is NOT measured in this fast pass and that those metrics come from get_job. This gives clear context for selecting analyze_track versus alternatives.

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?

The description substantially exceeds the sparse annotations by explaining costing per track, memory-based upload limits, relative-leveling behavior, processing time, per-track job IDs, and exact dry_run semantics before anything is spent. This is exactly the kind of behavioral context an agent needs beyond readOnly/destructive hints.

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?

Every sentence in the description earns its place: purpose, pricing, behavior, limits, latency guidance, return format, and dry-run safety. It is dense but not bloated, and the critical operational constraints appear early.

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 tool with 8 parameters and an output schema, the description covers all consequential aspects: cost model, constraints, album-mode behavior, timing, polling workflow, and a safe preview path. An agent can correctly select and invoke this tool with confidence.

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 already high at 88%, so the baseline is met. The description adds meaningful semantics beyond the schema: album_mode means the loudest track hits the target while others keep offsets, N tracks cost N tokens/runs, and there are per-file/per-call size caps not encoded in the schema. This elevates the value beyond the field descriptions alone.

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 opens with a specific verb and resource: 'Master up to 10 tracks in one call with the same settings.' This clearly distinguishes the tool from the sibling master_track as a batch operation while stating its scope precisely.

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?

It gives clear operational guidance: token/free-run costs per track, server caps, album-mode semantics, timing expectations, dry_run usage, and a recommendation to send fewer, longer tracks per call. It does not explicitly name master_track as the alternative for single-track jobs, but the batch context and sibling list make the usage clear.

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 and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating what the check returns, but does not disclose any additional behavioral nuances such as whether the call itself consumes quota or whether results are cached.

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?

The description is a single, front-loaded sentence that states the tool's purpose and the recommended call time without any filler. Every phrase adds useful information.

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 tool with an output schema present, the description covers what the tool reports and when to call it. Nothing critical is missing for an agent to select and invoke it correctly.

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 the baseline is 4. The description compensates by explaining what information will be reported, which is sufficient given the empty input 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?

The description clearly states the tool reports the account's current operational limits: token balance, free quota and reset time, upload cap, and PRO module availability. It is distinguishable from sibling info tools like get_pricing and get_service_info because it focuses on account limits rather than service or pricing details.

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?

The instruction 'Call before mastering' gives explicit timing for when to invoke this tool. It does not mention alternatives or exclusions, but the context is clear enough that an agent would know to call this before performing mastering operations.

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?

The description adds valuable behavioral context beyond the annotations: it is asynchronous ('Returns a job id — poll get_job'), free, and non-destructive to loudness/tone. Annotations only provide readOnly=false, openWorld=true, destructive=false, so the description meaningfully supplements them.

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 deliver the core behavior, constraints, cost, and result-handling instruction with zero filler. Every sentence earns its place and the most important distinction ('without mastering') is front-loaded.

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 an async job-submission tool, the description covers the action, scope, side effects, cost, and how to obtain the result. An output schema exists, so return-value details are not the description's job, and the schema covers parameter constraints. Nothing essential for correct invocation 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 input schema already describes audio_url and sensitivity with 67% coverage, so the baseline is 3. The description does not add detail about out_format or how sensitivity behaves, but the schema's enum and range descriptions largely carry the parameter semantics.

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 uses a specific verb ('Strip') and resource ('AI generator fingerprint'), and clearly differentiates the tool from mastering by stating 'without mastering; loudness and tone stay as they are.' This makes it distinct from sibling master_track without needing to inspect 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?

The phrase 'without mastering' gives clear contextual guidance that this tool is for fingerprint removal while preserving loudness and tone, which implies when to choose it over a mastering alternative. It does not explicitly name alternatives or exclusions, but the context is strong enough for appropriate selection.

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?

The description goes beyond annotations by disclosing the human-in-the-loop payment requirement and the follow-up polling step. It clarifies that the agent cannot finish payment, which is critical behavioral context. No contradiction with readOnlyHint is present because preparing a link does not necessarily mutate state.

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?

The description is two sentences with no fluff. It front-loads the core action, then states the key limitation and the next step. Every word adds value.

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 single-parameter tool with a documented output schema, this description is fully sufficient. It explains what the tool does, what the agent must do next, and the human dependency, leaving no important gap for an agent to call and use it correctly.

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 100%, so the single parameter pack_id is already self-documenting. The description does not add extra semantic detail beyond the schema, but it also does not need to because the schema provides adequate meaning. 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?

The description clearly states the tool's function: preparing a token purchase for a human principal and returning a checkout link. It also explicitly distinguishes this from completing payment, which is not possible for the agent. This makes the purpose unambiguous and distinct from sibling tools like check_limits.

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?

The description provides explicit usage guidance: use this to prepare a purchase, hand the checkout link to the human, then poll check_limits. It clearly states what the agent cannot do (complete payment) and names the follow-up tool. This is strong contextual routing.

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 mark the tool as read-only and non-destructive. The description adds valuable context beyond that: previews return per-style loudness and listen links, completed masters return a download_url, the signed link expires after about an hour, no credentials are needed to fetch it, and the operation is free. This strongly supports correct agent behavior.

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?

The description is compact and front-loaded, starting with the core purpose before adding conditional details. Every sentence earns its place: general metrics, preview-specific behavior, and master download/auth behavior.

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 one-parameter read-only tool with an output schema, the description covers the essential agent-facing context: what metrics are returned, how previews differ, when a download URL appears, its validity window, authentication requirements, and pricing. 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?

The single parameter job_id has no schema description, and the description does not explain where the job_id comes from or how to format it. It is only implicitly tied to 'a mastering, cleanup or preview job,' so the description does not compensate for the 0% schema coverage.

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 clearly identifies the tool's purpose: retrieving status, progress, and result metrics for mastering, cleanup, or preview jobs. It lists specific metrics and distinguishes behavior by job type, making its scope unambiguous even among siblings like master_track or preview_styles.

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?

The description implies this is the follow-up tool to check a job's outcome, and it gives conditional context for previews and finished masters. However, it never explicitly states when to use this tool versus alternatives, nor does it mention what it is not for.

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 and destructiveHint=false, so the safety profile is covered. The description adds 'live' and 'Free' as useful context but does not disclose return shape or any operational caveats; this is acceptable given the output schema and simple read-only nature.

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 fragments with no filler: resource, usage directive, and cost note. The key guidance 'Never quote prices from memory' is prominent, and the whole description can be absorbed at a glance.

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 parameterless, read-only tool that has an output schema, the description is nearly complete: it states the domain and the essential usage directive. A minor gap is that it does not explicitly name related tools or exclusions, but the low complexity does not require more.

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 accepts zero parameters, so there are no parameter semantics to document; per the rubric this receives the baseline 4.

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 explicitly identifies the resource as 'token packs and payment methods' and marks it as live, and the title supplies the query verb ('Get live pricing'). It is clearly a pricing lookup and distinct in purpose from the service/job/track siblings, though it does not name an alternative pricing-related sibling.

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?

'Never quote prices from memory' is an explicit directive to call this tool for current prices rather than relying on recalled information. It gives clear context for use, though it does not enumerate alternatives or state when not to use the tool beyond avoiding memory.

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 and destructiveHint=false, so the safety profile is covered. The description adds useful content expectations (free vs token costs, rules location) but does not reveal deeper behavioral traits such as response format or whether information may be cached.

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?

The description is extremely concise, with two short sentences that each earn their place. It front-loads the content and gives a direct call-time instruction without wasted words.

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 informational tool with an output schema and safety annotations, the description is complete. It tells the agent what the tool returns conceptually and when to call it, and the output schema covers concrete return values.

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 has zero parameters, so parameter documentation is not needed. The baseline of 4 applies because there is no parameter ambiguity to resolve.

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 that the tool explains what Magic Master does, what is free versus token-costed, and where rules live, so the general purpose is clear. However, it does not explicitly differentiate itself from sibling tools like get_pricing or check_limits, which may overlap in content.

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?

It gives explicit timing guidance: 'Call once at the start of a session.' It does not explicitly mention when not to use it or point to an alternative, but for a session-intro tool this is clear enough context.

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 and destructiveHint=false, covering the safety profile. The description adds useful context about the output content—target loudness in LUFS—and clearly signals a non-destructive listing operation.

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?

The description is extremely concise, with two short sentences that each carry meaningful information: the resource scope and the cost implication. No filler or redundant content is present.

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 listing tool with an output schema and safety annotations, the description is sufficiently complete. It states what is listed and what field is included; missing sibling differentiation is a minor gap given the tool's simplicity.

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 has zero parameters, so there is nothing to document semantically. The schema is trivially complete, and the description does not need to add parameter details.

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 clearly states that the tool returns all mastering presets with their target loudness in LUFS, which matches the title and identifies the resource. It does not explicitly use the verb 'list', but the meaning is unambiguous and distinct enough from the sibling tools.

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?

The description provides no guidance about when to use this tool versus alternatives such as preview_styles or get_service_info. The phrase 'Free' hints at a cost-related benefit, but there is no explicit when-to-use or when-not-to-use guidance.

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?

The description discloses substantial behavior beyond annotations: token cost with quota fallback ("COSTS 1 TOKEN when the account has a balance; otherwise it runs on the free quota without PRO modules"), async job semantics with timing ("typical 20-60 s, up to 10 min with restoration"), and a 100 MB server-side file ceiling. This is exactly the kind of context annotations (readOnlyHint=false, openWorldHint=true) cannot express.

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 dense sentences, front-loaded with the core purpose, then cost, then async workflow, then limits, then the recommendation. Every sentence carries distinct information — cost, timing, file ceiling, dry-run advice — with zero filler or repetition of schema content.

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, the description covers the critical operational facts an agent needs: pricing model, quota behavior, async return pattern, expected latency, size limits, and a safe-first workflow. An output schema exists, so return values need no description, and the dry_run advice addresses the main risk of accidental spend.

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 92%, so the schema does most of the work. The description adds genuine meaning beyond it: the dry_run recommendation explains its purpose (price + effective settings before anything is spent) and the 100 MB ceiling adds a real constraint on audio_url that the schema omits. These are modest but concrete additions.

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?

"Master one track" names a specific verb and resource, and the explicit singular phrasing differentiates it from the sibling batch_master without needing to open either schema. The opening sentence is unambiguous about what this tool does.

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?

The description gives clear operational guidance: run dry_run=true first for a price/settings preview, and expect to poll get_job afterward with concrete timing bounds. It does not explicitly state when to prefer siblings like batch_master or clean_ai_trace, though the "one track" phrasing implies the contrast.

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 mark the tool as non-destructive, but the description adds useful behavioral context: it previews only the middle 24 seconds, returns loudness and a listen link per preset, is free, and has a 6-per-day cap. It does not mention link expiration or persistence, but there is no contradiction with 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?

The description is short and front-loaded with the core action and outcome. The FREE/limit note and usage guidance are useful. The verb 'Master' is slightly ambiguous compared to the title's 'Compare,' but there is no wasted text.

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 two-parameter preview tool with an output schema and non-destructive annotations, the description is practically complete. It covers the action, scope, quota, output highlights, and usage rationale. It could mention style key sourcing more explicitly, but the schema already points to list_presets.

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%, so the schema already documents audio_url and styles. The description reinforces that styles should be 2-6 presets and that each produces loudness and a link, but it does not add new parameter-level details beyond what the schema already provides.

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 precise action and resource: 'Master the middle 24 s of the track in 2-6 presets at once and get each one's loudness plus a listen link.' This clearly identifies a preview/compare workflow and distinguishes it from siblings like master_track or list_presets.

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?

The description explicitly says to use this tool 'instead of guessing a preset' and 'instead of burning a token to try one,' which gives clear selection context. It does not explicitly name sibling tools or cover when another tool like batch_master would be better, but the intended usage is clear enough.

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