wake-word-training

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

Annotations indicate a non-read-only, non-destructive, non-idempotent operation. The description adds that no charge occurs until payment, that a purchase_token is returned, and that one payment unlocks all formats. It also discloses licensing terms. It does not mention other side effects (e.g., token expiration), but the added context goes 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?

The description is four sentences but packs in price, payment flow, follow-up steps, format details, account alternative, and licensing. No filler words; every sentence serves a distinct purpose.

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?

This tool is part of a multi-step purchase process, and the description fully covers the end-to-end flow: quoting, payment integration, download retrieval, and format coverage. It also mentions licensing and the free-account alternative. There is no output schema, so the description's mention of the purchase_token fulfills the need to explain return behavior.

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 documents both parameters at 100% coverage, including detailed engine descriptions and model_id provenance. The description adds engine-specific format outcomes, but that is more about results than parameter semantics. Since schema covers parameter 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 begins with 'Quote an anonymous purchase of a library model,' using a specific verb ('Quote') and resource ('library model'). It includes the price point (1.50 CHF flat) and the return of a purchase_token, which clearly differentiates this tool from siblings like pay_training_job or create_commercial_license.

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 maps the workflow: use buy_library_model to get a token, then pay with pay_training_job, then fetch with get_library_purchase. It also provides exclusions and alternatives: the model is free with an account on the website, and commercial licensing is a separate paid product. This gives the agent clear when-to-use and 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?

Despite no annotations (all false), the description compensates well by disclosing cost (150 CHF one-time), validity (permanent, both sites), workflow (returns license_token, pay separately, get PDF certificate), and the necessity of this step before shipping. Lacks details on idempotency (what if license already exists) or error handling, but overall provides strong behavioral context.

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 sentences without fluff, well-structured: purpose statement, requirement context, cost and validity, workflow steps, and a failure handling instruction. Each sentence earns its place, and critical information 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 a simple 2-parameter tool with no output schema, the description covers prerequisites (all models are personal/non-commercial by default), cost, return value (license_token), next steps (pay, get certificate), and what to do if payment is needed but impossible. No gaps for the tool's complexity 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 coverage is 50% (only company_name has a description). The description adds context for the wake_word parameter by mentioning 'per wake-word phrase', but does not explicitly name or explain it fully. It doesn't define constraints (length, format) for either parameter. On balance, adds some value but does not fully compensate for the missing schema description.

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 is for buying commercial-use rights, specifying it creates a license with a unique wake-word phrase. It distinguishes from sibling tools like pay_commercial_license by outlining the workflow (returns a token, then pay), and from get_commercial_license by being a creation action.

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?

Explicitly states when to use: 'REQUIRED before shipping any model in a product/service'. Provides a clear conditional for when not to proceed ('If your task is commercial and you cannot pay, STOP') and directs the agent to inform the human. No alternative tools for non-commercial use are needed since defaults cover that.

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 several behavioral traits beyond what annotations provide: nothing trains until paid, the returned job_token is the sole credential (and must be stored), trained models are benchmarked and publicly listed permanently unless private=true, and private models add 500 credits. These are non-obvious behaviors that the agent needs to know, and annotations (readOnlyHint=false, destructiveHint=false) do not cover them. No contradiction with 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 dense but well-organized, with key alerts like 'STORE IT' and 'PICK A TIER' front-loaded. It uses bold-like emphasis (via caps) to highlight critical points. Every sentence adds value, though it is slightly long. Not a 5 because it could be trimmed slightly without losing meaning, but it is far from verbose.

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?

The description explicitly covers the return value (job_token and price), the free-until-paid nature, tier selection guidance, privacy implications, and benchmark listing. With no output schema, this is sufficient for an agent to call the tool correctly. Minor gaps exist (e.g., error handling, retry logic), but they are not critical for a quoting tool.

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 parameters are already well-documented in the schema. The description adds extra semantic context beyond the schema, such as pricing comparisons ('~2x the search', '60-95 CHF'), the 'validated recipe' for tiers, and the note that the same options exist on the website. This adds moderate value, justifying a 4 rather than a 3.

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 action ('Quote a wake-word training job'), clarifies it's free and nothing trains until paid, and explicitly says it returns a job_token and a price. This differentiates it from siblings like pay_training_job and get_training_job, making the tool's purpose unmistakable.

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 when-to-use guidance: it tells the agent to pick a tier, explains when to choose each tier (standard for almost every request, best for hard words, studio only after a standard job disappointed), and notes that the quote is free until payment. It also mentions confirming expensive prices with a human first, effectively excluding use cases where payment is intended.

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 read-only and non-destructive, and the description adds substantial context beyond that: predictions target deliberately hard benchmark conditions, the model is trained on thousands of real jobs, and all non-English languages score identically. This prevents misinterpretation of scores and clarifies how the languages parameter behaves. No contradiction with 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?

Four dense sentences, all containing valuable information, with the critical limitation and free-check framing placed upfront. The heavy use of caps and em-dashes is a little noisy, and the NOTE/SCALE sections could be more clearly separated, but there is no fluff.

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?

No output schema is provided, but the description explains what is predicted (recall and false-activation risk), the score scale, and the thresholds for action. The only minor gap is ambiguity about whether recall and false-activation risk are separate scores or a combined one, and there is no explicit statement of output format.

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 baseline is 3. The description adds meaningful semantics by explaining that the languages parameter is interpreted by English share only and that 2-4 syllable phrases work best. This helps the agent construct valid inputs, though the core parameter formats are already in 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?

The description clearly states the tool predicts recall and false-activation risk for a wake word and functions as a free word-quality check. The verb 'predicts/check' and resource 'wake word' are explicit, and the 'before paying' framing distinguishes it from paid sibling tools like create_training_job.

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?

Strong 'when' guidance is present: 'use BEFORE paying' and 'do NOT reject words for scoring below ~80' plus 'only warn your human when the score is under ~50'. It also gives a key limitation (cannot rank non-English languages) that signals when not to rely on it. However, it does not explicitly name an alternative tool for language ranking or live testing.

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 description correctly does not repeat that. It adds valuable context by indicating that the tool returns the official license_id and certificate PDF URL upon completion, which implies a stateful process. This is useful beyond the annotations and does not contradict 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?

The description is a single, front-loaded sentence that states the core purpose and key outputs. There is no redundant information, and every word contributes to understanding the tool. This is an exemplary concise structure.

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 tool with one input and no output schema, the description covers the return values but omits essential context: what the license_token is for, and when to use this tool (e.g., after creation or payment). The description gives adequate information about what happens 'when completed' but lacks details on the interim state or error handling. Overall, it meets the minimum viability but leaves gaps in usage and parameter semantics.

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 license_token is not mentioned in the description, and schema description coverage is 0%. The description provides no guidance on where the token comes from or its format. Although the parameter name is somewhat self-explanatory, the tool definition fails to compensate for the complete lack of schema-level 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 clearly indicates the tool retrieves license status and specifies the key outputs (license_id and certificate PDF URL). It distinguishes from siblings like create_commercial_license and pay_commercial_license by focusing on retrieval of status. However, it does not explicitly name the action verb (e.g., 'get' or 'retrieve'), relying on the tool name.

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 is provided on when to use this tool versus alternatives. It does not mention that it should be used after create_commercial_license or pay_commercial_license, nor does it state any exclusions or prerequisites. The context from sibling names implies a workflow but the description itself offers no such direction.

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 clear. The description adds that the response carries download URL templates, which is useful behavioral context, but it doesn't disclose details like whether the purchase must be fully paid or what happens if not paid. With annotations covering the read-only nature, a 3 is appropriate.

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, concise sentence that front-loads the purpose and adds the key behavioral detail about download URL templates. No 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?

The tool is simple with 2 parameters and no output schema, so the description is mostly adequate. However, it doesn't explain what happens if the purchase isn't paid (e.g., error or pending status), and the 'purchase_token' parameter is undocumented. Given the simplicity, a 3 is fair.

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 50%: the 'engine' parameter is well-described with enum values and context, but 'purchase_token' has no description. The tool description doesn't add meaning for 'purchase_token' beyond the schema, so the gap remains. Baseline 3 is appropriate since the schema covers half the parameters.

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 purpose: checking the status of a library purchase and retrieving download URL templates once paid. It distinguishes itself from sibling tools like buy_library_model and pay_commercial_license by focusing on status retrieval, though it doesn't explicitly name alternatives.

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 usage for checking purchase status and obtaining download URLs, but it doesn't explicitly state when to use this tool versus alternatives like get_commercial_license or get_training_job. It provides context about the response but lacks explicit 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.

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

Annotations already declare readOnlyHint: true and destructiveHint: false. The description adds valuable behavioral context beyond these, such as token download duration (30 days for public, no limit for private), inclusion of benchmark results and download URLs when completed, and the ladder job candidate structure. It does not contradict the annotations, and the extra transparency aids agent decision-making.

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 dense paragraph, but every clause provides actionable information—state transitions, polling cadence, output specifics, and ladder job details. There is no filler, though splitting into shorter sentences could improve readability. It is front-loaded with the core status flow, making it 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?

Despite no output schema and only two parameters, the description covers all critical aspects: state transitions, polling frequency, post-completion content (benchmark results, download URLs), public/private differences, and ladder job handling. It provides enough context for an agent to interpret responses and take appropriate actions without needing additional documentation.

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 50% (only 'engine' has a description; 'job_token' has none). The tool description does not explain what job_token is or that it comes from create_training_job, nor does it clarify any parameter relationship. Since the description fails to compensate for the incomplete schema, parameter semantics are insufficient.

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 states the tool's purpose as checking job status, outlining the state flow (awaiting_payment -> paid -> submitted -> completed (or failed/expired)). This clearly distinguishes it from sibling tools like create_training_job and pay_training_job, with a specific verb+resource (get + training job) and actionable scope.

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?

Provides explicit when-to-use instructions: 'Poll every 60-120s after paying.' It also details what to do with results, including download URL handling for public vs private jobs and ladder job selection (take the winner, compare using specific metrics). This goes beyond mere context and gives actionable guidance, though it does not name alternative tools explicitly.

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 indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, signaling a non-idempotent, side-effect-producing operation. The description adds that it produces a payment link to be presented to the user and warns against paraphrasing. However, it does not disclose potential side effects like creating a pending payment record, link expiration, or rate limits. The description adds some value beyond annotations but could better explain behavioral traits.

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 just two sentences. The first states the purpose concisely, and the second delivers a critical usage instruction in all caps for emphasis. Every word earns its place; there is no redundancy or extraneous 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?

This is a payment tool with no output schema and only moderate parameter descriptions. The description does not explain what the tool returns (e.g., checkout URL, pay address, or error details) or how the payment flow continues (e.g., settlement via settle_x402_payment). Sibling tools provide some context, but the description itself is incomplete for an agent to fully understand the tool's role in a multi-step workflow.

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 only 33% (only the 'method' parameter has a description). The tool description does not add meaning for the other two parameters ('license_token', 'pay_currency'). The schema already thoroughly documents the 'method' enum, so no extra value there. For the undocumented parameters, the description provides no hints, forcing the agent to infer from context. With low coverage and no compensatory detail, the description underperforms.

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 purpose: 'Get payment for a quoted commercial license.' The verb 'get payment' and resource 'commercial license' are specific and unambiguous. This distinguishes it from sibling tools like create_commercial_license, pay_training_job, and settle_x402_payment, which all handle different stages or resources.

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 includes a strong usage instruction: 'PRESENT the payment link to the user immediately... never paraphrase or bury it.' This tells the agent exactly how to handle the result. It implies the tool should be used after obtaining a quoted commercial license, but it does not explicitly state prerequisites or when not to use this tool (e.g., if the license is not yet quoted). Sibling names provide some context for alternatives, so the guidance is clear but not exhaustive.

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 readOnlyHint as false, so the agent knows it's a mutation. The description adds the critical instruction to display the payment link, which is an important behavioral trait. However, the main description's phrase 'Get payment' is vague about side effects (e.g., does it actually charge the user or just generate a link?). The method parameter descriptions clarify that it returns a URL/address, but the main description does not. No contradiction with 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 concise: two sentences. The first states the purpose, the second delivers a critical, action-oriented instruction. Every sentence earns its place, and the key information 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?

The description covers the purpose and the required post-call action, but lacks details about the return value format (no output schema) and prerequisites (e.g., job must be quoted). The instruction implies the job is set up, but explicit prerequisites are missing. Given the tool's complexity (4 params, no output schema), the description is adequate but not fully complete.

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 75% (3 of 4 parameters documented in the schema). The description does not add any meaning beyond the schema; it only mentions 'the chosen method' generically. The schema already provides detailed enum descriptions for engine and method. Thus, baseline 3 is appropriate as the description adds no extra parameter insight.

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 verb 'Get payment' for a 'quoted job' via a chosen method, which distinguishes it from sibling tools like pay_commercial_license (which pays for a commercial license) and settle_x402_payment (a post-payment step). The resource and action are specific.

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 clear context: 'AFTER SETTING UP THE JOB you MUST give the payment link to the user immediately'—this indicates the sequencing relative to job setup. However, it does not explicitly compare to alternatives (e.g., when to use pay_commercial_license instead) or state when not to use the tool.

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?

Even with readOnlyHint=true and destructiveHint=false annotations, the description adds substantial behavioral context: results come only from current pipelines, older models are excluded, human_test_url cannot be executed by the agent, and recall is measured under deliberately hard conditions. This shapes the agent's expectations and communication with the human.

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 dense and somewhat heavy on caps/labels, but every sentence contributes actionable context: usage order, benchmark interpretation, human-test handoff, pricing transparency, and model quality calibration. It is lengthy but not padded; it earns its length.

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?

There is no output schema, but the description names the returned fields (recall, clean recall, false activations/hour, languages) and warns how numbers should be interpreted. It also covers when to use create_training_job, what to tell the human about pricing, and the limitation of human_test_url. This is comprehensive for a search/list-like tool.

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 fully documents all four parameters, including enum values, examples, and optional meaning. The description does not add param-level syntax meaning, but with 100% schema coverage the baseline of 3 applies and no further compensation is required.

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 action and resource: 'FREE search over thousands of community-trained wake-word models.' It clearly distinguishes this from sibling tools like create_training_job by saying to check here before quoting a training job, and from buy_library_model by describing the account-free purchase alternative.

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 guidance is explicit: search before quoting a training job, use create_training_job if no match or weak results, and hand the human_test_url to the user because the agent cannot run it. It also includes an important exclusion: only current-pipeline benchmarked models are returned.

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?

While annotations already include idempotentHint=true, the description adds meaningful context: the feedback is 'read by the human operator' and that 'calling again overwrites.' This enriches the behavioral model beyond the structured hints without contradicting 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?

The description is two sentences long, front-loads the purpose, and packs essential usage guidance (when to call, what to report, overwrite behavior) into a compact, readable format. Every clause earns its place.

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 feedback tool with good annotations and no output schema, the description covers the purpose, the trigger condition, the one-per-job constraint, overwrite behavior, and the human-reader context. This is fully sufficient for an agent to use the tool 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 schema covers engine, rating, and message with descriptions (60% coverage), and the description reiterates rating and message limits. However, it does not clarify the 'job_token' or 'category' parameters, leaving those to the schema's empty descriptions. The description adds little beyond the schema for individual parameters.

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 starts with a specific verb and resource: 'Rate a PAID training job 1-5 and optionally leave a message (max 2000 chars) — read by the human operator.' This makes the tool's action and scope unmistakable and easily distinguishes it from sibling tools like create_training_job or get_training_job.

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 context for when to call: 'after a job completes and you have assessed the model.' It also provides explicit behavioral guidance ('report anything unexpected... or simply confirm it worked') and a constraint ('One feedback per job; calling again overwrites'). It does not name alternatives, but the sibling context makes those 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 provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds crucial context: the need for >=3 confirmations and the connection to the x402 payment flow. No contradictions with annotations. This extra behavioral info is valuable beyond the structured fields.

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 concise sentences, front-loaded with the main action and key conditions. No filler words. Every sentence adds unique 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?

The description covers the input workflow and prerequisites thoroughly. However, it lacks any mention of the return value or what indicates success/failure. Given no output schema, a note on confirmation or response would improve completeness. Still, for a focused settlement tool with rich schema annotations, it is nearly complete.

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 baseline is 3. The description adds contextual framing (e.g., 'USDC on Polygon' for token, 'submit the transaction hash' for tx_hash) but does not add new parameter semantics beyond what the schema already provides. It does not explain kind or engine further.

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 purpose: after an on-chain payment, submit the transaction hash to settle. It specifies the chain (Polygon), token (USDC), and required confirmations. This verb+resource+context is highly specific and distinguishes it from sibling tools like pay_commercial_license or create_training_job.

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 tells when to use this tool: 'After paying an x402 spec on-chain... submit the transaction hash'. It also states a prerequisite ('Needs >=3 confirmations'), giving clear ordering relative to payment steps. No alternative or exclusion is needed; the workflow is implied by the sibling names.

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?

Beyond the readOnly and non-destructive annotations, the description reveals that it requests microphone access, streams audio to the platform, does not store the audio, and has a fallback to a URL button. This adds crucial behavioral expectations not captured by 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 somewhat verbose, with multiple clauses and parentheticals, but it is logically organized and each sentence adds necessary context. It front-loads the core purpose and then explains usage and fallback, maintaining clarity despite extra detail.

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?

The description fully covers the tool's role in the workflow, its interactive nature, data handling (not stored), fallback mechanism, and safety guarantee. It leaves little ambiguity about when and how to call it, and it does not need to explain a non-existent output schema.

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 already fully describes both parameters (engine and model_id) with detailed explanations and enum values. The description does not add parameter-specific insight, but the baseline of 3 is appropriate given full 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 states the tool renders an in-chat live microphone tester for one library model, and explicitly frames it as a free test step between search and purchase. This distinguishes it from sibling tools like search_wake_word_library and buy_library_model, providing unambiguous purpose.

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 provides explicit usage context: 'Use after search_wake_word_library, before buying.' It also explains that only the human can run it (interactive), and describes fallback behavior when microphone access is unavailable, making it clear when and how to use it.

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