agent-ready-kit

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

Discloses critical behavior: when should_ask_user is true, agent must ask user rather than act on guessed vertical. Annotations already indicate read-only, idempotent, non-destructive; description adds workflow context without contradiction.

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 key information front-loaded. Every sentence adds value: usage context, input description, output list, special flag handling. 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?

Covers all essential aspects: inputs, outputs, special flag, return of site title/meta description for rendering. With output schema present, description is complete for agent invocation.

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 covers all 3 parameters with descriptions. Description adds workflow context (e.g., using user_provided_vertical_id to skip detection) and explains the business_type parameter's resolution against taxonomy. Slight redundancy but valuable extra meaning.

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?

Clearly states the tool detects business vertical from site data and returns specific metrics like AI-search lift % and positioning pitch. References use after scan_site, differentiating it from siblings like scan_site and detect_platform.

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 says 'Use this immediately after scan_site' and provides detailed handling for low-confidence detection (ask user before continuing). Also explains optional parameters to skip auto-detection.

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 annotations, the description discloses detailed side effects: running Coinbase's validator, per-check fixes, firing indexing settlement from its own funded wallet, pointing to self-settle above a threshold, confirming the merchant-feed entry, idempotency, concurrent double-spend protection, and human escalation after 5 failures. This is rich behavioral context that annotations alone do not provide.

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 purposeful; the first sentence establishes the core purpose, and subsequent sentences unpack the pipeline steps, safety guarantees, and escalation behavior. Every sentence adds value, though the single-paragraph format could benefit from bullet points for easier parsing.

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 complex multi-step tool with an output schema, and the description covers the full lifecycle: validation, settlement logic, self-settle fallback, feed confirmation, receipt return, idempotency, and failure escalation. It is sufficiently complete for an agent to invoke it safely and understand expected 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 provides 100% coverage of the single parameter listing_key, including its format and requirement. The description references the key but adds no additional semantic meaning beyond what the schema states, so the 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 identifies the tool as a resumable pipeline driver for a purchased Bazaar Listing Package, stating its role in advancing through validation, settlement, and feed confirmation. It is distinct from sibling tools like create_bazaar_listing and validate_x402_endpoint, which serve different stages.

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 states to use it any time with the listing_key for a purchased package, providing clear context and implying it is the ongoing driver after purchase. It does not explicitly name alternatives or exclusions, but the specific mention of 'purchased package' and 'resumable pipeline driver' differentiates it from creation/validation tools.

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 safe, read-only, idempotent behavior. Description adds important behavioral details: questions are ranked by price_impact, and the agent should present them as user-choices rather than covert data collection. 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?

Three sentences, each serving a distinct purpose: usage, return format, and rendering guidance. No redundancy, well front-loaded. Every sentence 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?

Given the tool's simplicity (2 params, no enums, no nested objects) and existence of an output schema, the description covers purpose, usage guidelines, behavioral transparency, and ethical use. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must add meaning. It implies 'quote_id' via 'existing quote' but does not explicitly describe either parameter. 'max_questions' is not mentioned at all. The schema's limited meaning (quote_id as string) is not enriched.

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?

Clearly states verb 'get' and resource 'questions to tighten an existing quote'. Distinguishes from sibling tools that create proposals or refine quotes. The description is specific about the task and outcome.

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 says when to use ('when you want to know what user-facing questions would most tighten an existing quote') and provides advice on rendering questions as user-choices. It does not explicitly exclude alternative scenarios but gives clear usage 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?

Adds behavioral context beyond annotations: provisions listing, returns listing_key, drives pipeline, notes that optional params are collected by kit tool. 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?

Well-structured and front-loaded with core purpose. Slightly long but each sentence earns its place by providing clear guidance.

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?

Given complexity (6 params, 2 required, output schema exists) and sibling tools, description covers process flow, distinguishes customer types, and references pipeline sequence completely.

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 baseline 3. Description adds meaning: bundle_key is engagement freebie, email binds listing_key, optional params are handled by kit tool. Does not repeat 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 creates a bazaar listing for paid engagement customers with a valid bundle_key. It distinguishes from the standalone purchase path and outlines the pipeline.

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 (paid engagement customer with bundle_key) and when not (buyers without bundle_key use standalone purchase). Provides alternative URL for the standalone path.

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 lack behavioral info (readOnlyHint=false, etc.), but description adds: returns proposal with terms, deliverables, checkout hand-off types, and 403 error for comparison-shopping. Side effects and authorization are not fully disclosed, but it's sufficient.

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 sentences with front-loaded conditions and key output. No wasted words; every sentence 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?

High-level return behavior is described, but parameter details are sparse. Output schema likely covers return structure, yet the lack of parameter explanations leaves gaps for a tool with 4 params and 0% schema coverage.

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 0%, and description only partially explains 'user_consent_scope' via conditions. Other parameters ('quote_id', 'selected_tier', 'checkout_protocol') have no explanation, forcing reliance on names 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 title 'Create a binding-style proposal' and description clearly state the tool creates a proposal. It distinguishes from sibling tools like 'refine_quote' and 'request_quote' by specifying conditions and output. Verb+resource is precise.

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?

Explicit conditions for use are given: medium/high quote confidence and appropriate consent scope. It warns against comparison-shopping callers. However, no alternative tool is named for when conditions aren't met, leaving some ambiguity.

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 read-only, idempotent, safe. Description adds that it returns platform slug, confidence, and matched signals for reasoning, which is extra behavioral context. No contradictions.

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 concise sentences front-loaded with usage guidance. Every sentence adds value: usage context, platform examples, return value details. No 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?

Covers purpose, usage, return structure. Does not mention error handling or invalid URLs, but output schema exists and annotations cover safety. Mostly complete for a simple 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?

Only one parameter (url) with 0% schema description coverage. Description implies the URL is the site to detect, but does not add explicit format or constraints. Adequate given single param and clear context.

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?

Description clearly states the tool identifies hosting/CMS for deploy instructions. Distinct from sibling tools like scan_site or verify_deployment by focusing on platform detection.

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: 'pick the right deploy instructions for a site'. Provides examples (cPanel vs Vercel). Missing explicit when-not-to-use but context is 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 only indicate non-readOnly and non-destructive. The description adds crucial behavioral details: free tier returns metadata+download_url (no file bodies), paid tier returns inline file objects chunked above 8KB. Also instructs how to render download_url. No contradictions 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 well-structured with clear free/paid tier sections. It is slightly verbose with explicit instructions like 'DO NOT paste raw file contents' and markdown formatting advice, but these are helpful for correct agent behavior. Front-loaded with usage case.

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?

Covers two main use cases, behavior per tier, and links to sibling for pricing. With 8 parameters, missing details on error handling or invalid bundle_key. Output schema exists but is not shown; description focuses on return categories (metadata, files) adequately. Slight gaps prevent a 5.

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 38% (low). Description adds significant meaning for 'bundle_key' (free vs paid distinction) and 'domain' (domain-only). However, it does not explain 'phone', 'category', 'primaryToolName', 'primaryToolDescription', or 'siteName' beyond what schema provides. Baseline 3 due to low coverage, with partial compensation.

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?

Description clearly states the tool delivers files to paid customers (with bundle_key) or free starter files to downstream agents. It distinguishes two tiers and uses specific verbs ('deliver', 'returns'). Siblings like 'get_customer_files' or 'get_bazaar_listing_kit' handle different resources, so this tool's purpose is unique.

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?

Description explicitly specifies when to use ('when delivering files to a paid customer' OR 'when a downstream agent wants free starter files') and what to avoid ('DO NOT paste raw file contents into chat'). It also directs to call sibling 'get_pricing_tiers' for pricing evaluation, providing clear 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?

Annotations already provide idempotentHint=true, and the description reinforces this by stating 'the kit is regenerated on every call (idempotent)'. It adds details about file return behavior (inline, chunked above 8KB) and that missing parameters are filled from the purchase. No contradictions 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 a single dense paragraph with four sentences, each conveying critical information: prerequisite, kit contents, parameter behavior, and fallback guidance. While concise, a more structured format (e.g., bullet points) could improve readability, but as a paragraph it efficiently uses space.

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 7 parameters, an output schema, and annotations, the description sufficiently covers the kit's contents, regeneration property, file handling, and precondition. The output schema likely details return values, so the description need not repeat that. The only minor gap is not explaining the DEPLOY-CHECKLIST order, but overall it's comprehensive.

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 86%, so the schema already documents most parameters. The description adds value by explaining that resource_url, pay_to, price_usd, and stack can be passed to fill missing purchase data, and that listing_key is required. This clarifies the optional parameters' role beyond mere definitions.

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: generating a deploy-ready x402 v2 kit after purchasing the Bazaar Listing Package. It distinguishes itself from sibling tools like create_bazaar_listing by focusing on post-purchase kit generation and specifies the kit's components (handler code, trigger script, cron, etc.).

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 'Use this after buying the Bazaar Listing Package' and requires the listing_key. It also provides an alternative when no listing_key exists (directing to purchase via URL). However, it does not mention specific sibling tools as alternatives, which would strengthen 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 adds significant behavioral context beyond the annotations. It explains the paywall behavior: without a valid bundle_key, a teaser is returned; with it, the full report is provided. This goes beyond the readOnly and idempotent hints, offering transparency about data access and limitations. No contradictions 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 highly concise: three sentences that are front-loaded with usage guidance, followed by details on the paywall behavior. Every sentence provides critical information without redundancy or filler. This is an optimal length for the tool's complexity.

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?

Given the tool has an output schema (as indicated by context signals), the description does not need to detail return values. It covers the two operational modes (with/without bundle_key) and mentions key data points returned (citation rates, position, etc.). This is complete for an agent to understand the tool's behavior and output.

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 provides high-quality descriptions for both parameters (bundle_key and brand_domain), covering 100% of the parameters. The description does not add new semantic information about the parameters; it only references the bundle_key in the behavioral note. Therefore, baseline score of 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 clearly that the tool retrieves citation data from AI search platforms. It starts with 'Use this when a customer wants to see how AI search platforms cite them,' which directly defines the purpose. However, it does not explicitly distinguish this tool from sibling tools, so it meets the standard for a clear purpose but falls short of the highest tier.

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 on when to use the tool ('when a customer wants to see how AI search platforms cite them') and warns against misuse ('Citation data is paid intelligence, not a free reconnaissance tool'). It does not explicitly mention when not to use it or alternatives, but the guidance is sufficient for most scenarios.

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, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond this: the paywall logic (free vs. full files based on bundle_key) and the base64 encoding of the ZIP, which is crucial for the agent to decode and present to the user.

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, each providing critical information: use case, paywall behavior, and encoding. There is no redundancy or wasted words. It is front-loaded with the primary use case, making it 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?

The output schema exists, so return values are documented elsewhere. The description covers the core purpose, the paywall distinction, and the encoding requirement. It does not explain the optional parameters' effects, but given the output schema and the simplicity of the core behavior, the description is sufficiently complete for the 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?

Schema coverage is only 33% (domain, delivery, bundle_key have descriptions). The description only elaborates on bundle_key (explaining the paywall effect) but leaves the six undocumented parameters (phone, category, siteName, description, primaryToolName, primaryToolDescription) unexplained. With low schema coverage, the description should compensate, but it does not.

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: 'Use this when an agent needs to hand a downloadable ZIP to its end user.' It specifies the resource (customer files) and output format (ZIP, base64), and distinguishes itself from siblings by emphasizing the PAYWALL and bundle_key mechanism, which is unique to this tool.

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 provides a when-to-use scenario ('when an agent needs to hand a downloadable ZIP to its end user') and clarifies the impact of having or lacking a bundle_key. It does not explicitly name alternative tools or exclusions, but the context is clear enough for an agent to decide.

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 annotations (readOnly, idempotent, non-destructive), the description discloses significant behavioral context: it returns specific pricing tiers, includes optional add-ons, and notes that 'The package closes autonomously' via request_invoice/start_checkout, including payment details and cap handling. This is highly transparent about the tool's behavior and side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and rambling, mixing pricing structure, add-ons, and autonomous closing behavior into a single paragraph. It is front-loaded with the usage trigger, but the lack of structure (e.g., bullet points) makes it harder to parse. It could be more concise without losing essential 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?

The description covers the complete pricing landscape: the flat $450 package, free tier, optional custom tools at $150 each, separate add-ons ($99, $19/mo, $199/mo), autonomous closing behavior, and consultation requirements. With an output schema present, return values are already documented, so this description is fully sufficient for an agent to handle pricing inquiries.

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 the schema covers everything (100% coverage). The description adds no parameter details, but none are needed. According to the rubric, 0 params yields a baseline of 4, and the description does not need to compensate 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 title 'Get Pricing Tiers' and the opening line 'Use this when an end user (or upstream agent) asks about pricing' clearly state the tool's purpose. It explicitly describes what it returns ('Free tier (two free downloads) + the $450 package') and distinguishes itself from siblings by emphasizing a flat fee with no tiers or per-business quote.

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 an explicit 'when to use' condition: 'Use this when an end user (or upstream agent) asks about pricing.' It also adds that 'requires_consult is false' and a specialist track is optional, preventing unnecessary escalation. However, it does not explicitly name alternative tools or provide 'when-not-to-use' guidance, so it falls short of a 5.

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 the tool as read-only, idempotent, and non-destructive. The description adds behavioral context: the tool derives recommendations from site content and detected vertical, follows a naming convention, and returns ranked results. This goes beyond what annotations provide.

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 sentences, no fluff. The first sentence states the purpose and usage context, the second explains the output and naming convention. Every word is 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?

Given the tool's simplicity and the existence of an output schema, the description provides sufficient information: usage context, input parameters, output content, and naming convention. No gaps identified.

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%, but the description adds meaning by explaining that 'url' is used for scraping and vertical detection, 'vertical_id' is optional to skip auto-detect, and 'business_type' is resolved against a taxonomy. This enriches the schema information.

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 'Use this when planning what agent capabilities a customer should expose' and specifies that it returns up to 5 ranked snake_case MCP tool names with descriptions and rationale. This is a specific verb-resource pair and stands out among siblings.

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 provides a usage context ('when planning what agent capabilities a customer should expose'), which is clear and direct. It lacks explicit exclusion criteria or reference to alternative tools, but the context is sufficiently narrow.

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 mentions 'tightens the quote band' and 're-runs the engine', indicating a modification action. Annotations show non-read-only and non-destructive, which aligns. However, it does not describe whether the original quote is updated or a new one is created, or if there are any side effects (e.g., idempotency).

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 (2 sentences) and front-loaded with the usage trigger. However, it could be more structured by briefly listing key parameters. Still, it is efficient and avoids verbosity.

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?

Given the tool has 4 parameters including nested objects and a output schema, the description is insufficient. It omits explanations for the additional context and constraints parameters, which are crucial for correct invocation. The agent would need more detail to use the tool effectively.

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?

With schema description coverage at only 25%, the description should compensate but does not. Only quote_id is mentioned; the additional_context and additional_constraints parameters, which have complex nested structures, are not explained. The description adds little meaning beyond 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 it is for refining an existing quote after receiving additional context, with a specific verb ('refine') and resource ('quote'). It distinguishes from the sibling tool 'request_quote' by specifying it is for an existing quote with merged context.

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 specifies when to use the tool: 'when the user has shared additional context... after an initial request_quote'. It also provides guidance on passing the quote_id, ensuring proper invocation. However, it does not explicitly state when not to use it or mention 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?

Discloses critical behaviors beyond annotations: one-time billing with no recurring, ~$999,999 maximum with alternate_rail fallback, no wallet needed, immediate payment and automatic delivery via bundle_key, and optional human call. Annotations are mostly false but the description adds rich context without contradiction.

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?

Although long, every sentence earns its place. The description is front-loaded with the primary purpose, uses bold for key terms, and organizes complex details (pricing, limits, alternatives, optional fields) into a coherent flow. It is appropriately sized for the tool's complexity.

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?

Covers pricing tiers, add-ons, payment limits, alternate rails, requirements, delivery, and exclusions. With a rich schema and output schema present, the description provides the full picture an agent needs for correct invocation and navigation of edge cases.

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 covers 100% of parameters, but the description adds essential usage semantics: amount_usd is only for custom-tool add-ons or buyer-agreed totals, only email (and domain) are required, contact fields are optional-but-welcome, and quote_id is preferred. This transforms raw parameter descriptions into actionable decision rules.

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+resource+scope: 'Use this to autonomously close a deal: issue a ONE-TIME Stripe Invoice for the flat $450 package price.' It clearly distinguishes from siblings like start_checkout and request_quote by emphasizing the autonomous, one-and-done nature.

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 ('Use this to autonomously close a deal'), when not to use (wallet-holding agents can skip via x402 endpoint), and what's excluded ('Monthly ongoing support is NOT part of this'). Also provides alternative rail options for large amounts, giving clear decision 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 show non-readOnly, non-destructive, open-world. Description adds: quote validity (7 days), currency localization, consent scope effects, and budget signal handling. No contradictions.

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, uses bold for key behavior, but slightly verbose. Each sentence adds value, could be slightly tightened without loss.

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?

Given 7 params, nested objects, and output schema, description covers usage, parameter roles, and edge cases. Output format is mentioned (quote band), and output schema exists, so completeness is adequate.

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?

Low schema coverage (43%). Description compensates by explaining business_type taxonomy resolution, buyer_context.budget_signal usage, calling_agent.consent_scope impact, and accept_language defaulting.

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?

Title and description clearly state the tool is for requesting pricing/scoping for agent-ready engagements. It distinguishes itself from siblings like refine_quote by specifying initial scoping behavior and return of a quote band.

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 ('user wants pricing or scoping'), explains context-dependent output (wide vs. tight band), and gives clear guidance on capturing budget signals for re-engagement.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: lists the 22 checks across three categories, explains free vs. paid behavior (partial vs. full report), and notes fetch-based behavior for SPAs. 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 a single dense paragraph that efficiently covers usage, checks, tiers, and technical note. While it packs a lot of information, every sentence serves a purpose and is front-loaded with the key usage distinction.

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?

Given the tool's complexity (22 checks across three categories, free vs. paid tiers, output schema exists), the description is complete. It covers behavior, parameter roles, and return expectations without needing to re-explain the 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?

Schema coverage is 100% and the description adds significant meaning: explains that url is required, bundle_key unlocks full findings, describes free tier limitations, and provides a purchase URL for per-call access. This goes far beyond the schema docstrings.

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 audits site quality (SEO, accessibility, security headers) and explicitly distinguishes it from the sibling tool 'scan_site' which measures agent-readiness. It lists specific checks, providing a precise verb+resource definition.

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 (when user wants quality audit) and contrasts with scan_site. It also explains the free vs. paid tier behavior, offering clear guidance on tool selection and prerequisites.

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 readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral details: runs 19 live HTTP checks, returns level 0-5, per-check pass/fail with evidence and remediation, and takes 3-5 seconds. 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?

Single sentence for usage, followed by a concise list of checks, output summary, and timing. No unnecessary words, every sentence 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 complex tool with 19 checks and an output schema, the description fully explains the output structure (level, per-check results, evidence, remediation) and runtime. No missing essential information.

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 'url' with 0% schema coverage. The description does not add explicit details about url format or constraints, relying on the tool name and context. Given the schema coverage, the description should compensate more, but the parameter is simple. 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?

Clearly states it assesses 'how AI-callable a site is' with a specific verb and resource. Distinguishes from siblings by listing its 19 unique checks, differentiating it from related tools like run_site_audit.

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?

Opens with 'Use this when you need to assess how AI-callable a site is,' providing explicit context. While it doesn't explicitly state when not to use, the detailed check list leaves no ambiguity.

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, idempotentHint, openWorldHint, and destructiveHint. The description adds valuable behavioral context: it returns a sequence of next-action MCP calls, which goes beyond what annotations provide.

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?

Single concise paragraph with no filler. Every sentence provides essential information: trigger, flow, return value, and downstream usage.

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?

Given the full parameter schema, output schema presence, and rich annotations, the description is sufficiently complete. It covers purpose, trigger, orchestration sequence, and result format without unnecessary detail.

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 parameters are well-documented in the schema. The description does not add additional parameter details beyond the schema, which is acceptable.

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 trigger phrase that should invoke this tool and summarizes the orchestrated workflow, distinguishing it from sibling tools that handle individual steps.

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 specifies when to use this tool based on user request. While it doesn't list when not to use, the trigger is unambiguous and the description implies this is the primary orchestrator, not for individual sub-tasks.

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 the critical real-world side effect: it issues an actual payable invoice, delivery is automatic, and the bundle_key activates upon payment. It also clarifies that consult_url is optional. This goes well beyond the annotations (which only indicate it's not read-only) and provides essential 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?

The description is appropriately sized for the tool's complexity. Each sentence serves a distinct purpose: usage trigger, core behavior, alternative, clarification, and free-tier fallback. No fluff or redundancy; it is well-structured and 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?

Given the tool's financial impact and delivery mechanism, the description provides comprehensive context: when to use, alternatives, payment flow, delivery timing, and optional extras. The output schema presumably documents return values, so the description is complete for agent decision-making.

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 value by stating the flat $450 price and the optional nature of consult_url (though not in the schema, it's useful context). It doesn't fully clarify whether consult_url is an input or output, but it does add meaning beyond 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's purpose with a specific verb and resource ('buy the package now') and explicitly distinguishes it from sibling tools like request_invoice and generate_files. It is immediately obvious what this tool does and how it differs.

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?

Explicit when-to-use guidance is given ('Use this when an end user wants to buy the package now'), with clear exclusions and alternatives: custom tools via request_invoice, Free tier via generate_files. This fully covers usage context and differentiation.

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 provides rich behavioral context beyond annotations: 'Capture is non-binding', explains phone-first follow-up conversion rates, and details budget signal usage. No contradiction with annotations (destructiveHint false, etc.) as the tool is non-destructive.

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 well-structured with bold headings, fallback, and bullet-like emphasis. However, it is somewhat verbose; could be slightly more concise while retaining all valuable details.

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?

Given 14 parameters, 93% schema coverage, and an output schema (implied), the description covers all important aspects: required fields, fallback, budget signals, close/handoff instructions, and tool specs. It is complete for complexity.

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 93%, but the description adds substantial meaning: explains required contact fields, why phone is prioritized, how to capture budget_signal, and the source enum values. This goes well beyond the schema's property descriptions.

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 'Use this when the user has indicated interest in being followed up with — even before formal checkout.' It specifies the verb (submit lead) and resource (lead capture) and distinguishes from sibling tools like start_checkout by mentioning pre-checkout usage.

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 states when to use the tool ('user has indicated interest...') and provides detailed fallback instructions ('if the user explicitly refuses to share a phone, accept email-only'). It also implicitly contrasts with formal checkout tools.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description goes beyond by detailing the output structure (structured fields + markdown blob + caller_reasoning block) and the cooperative sampling mechanism. It explains that the caller_reasoning block contains a prompt that the agent can execute to personalize the recommendation, and that if unable, rendering markdown as-is works. No contradictions 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 detailed but well-structured, with the key usage statement front-loaded. Each part provides necessary guidance: usage, output format, cooperative sampling, and fallback behavior. While lengthy, every sentence adds value, and it avoids redundancy with the schema. Minor reduction could improve conciseness, but it remains effective.

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?

Given the presence of an output schema, the description adequately covers all necessary context: when to use, what the tool returns (structured + markdown, caller_reasoning), how to interpret cooperative sampling, and fallback instructions. No gaps are apparent for an agent selecting this tool. The combination of description and schema provides full context.

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%: both 'url' and 'include_vertical' have descriptions. The description adds minimal extra meaning ('we'll scan + detect vertical' for url and 'Include vertical context block (default true)' for include_vertical), which is already in the schema. Baseline is 3, and the description does not significantly enhance 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 clearly states the specific purpose: 'Use this when displaying scan output to a human via chat'. It identifies the verb (summarize/render), the resource (scan output), and the audience (humans). It differentiates from sibling tools like run_site_audit and scan_site by focusing on human-readable formatting rather than raw data.

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 states the usage context ('when displaying scan output to a human via chat') and provides guidance for handling the output (render markdown or execute the prompt from caller_reasoning). It also mentions that chat clients that can't render React get the same story, implying when this tool is appropriate. However, it doesn't explicitly list alternative tools for non-chat scenarios.

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 safe, idempotent, read-only behavior. Description adds valuable context that user choice is the qualifying signal and no buyer_context needed, surpassing annotation coverage.

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, front-loaded with usage guidance, no redundancy. Every sentence 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?

Given existence of output schema, the description sufficiently covers purpose, usage, and behavioral context for a simple selection 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 coverage is 0% and description does not explain the 'service_request' parameter or its nested 'natural_language_description' field. The description focuses on output and usage, not input 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?

Clearly states the tool returns 2-4 tier options for self-selection. Misses explicit differentiation from sibling 'get_pricing_tiers', but the context of avoiding detail sharing is distinctive.

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 specifies when to use (comparison_shopping mode, wants to pick a tier without details) and states no buyer_context required, guiding away from 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, but the description adds valuable context: 'no payment is made, nothing is indexed', 'Probes the URL live via CDP's read-only validator', and explains that the crawler probes WITHOUT query params. This goes beyond annotations and reveals important behavioral nuances.

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 front-loaded with the core purpose, but then becomes overly verbose with promotional content: pricing ($99), Stripe links, purchase instructions, and mentions of being 'included FREE'. These sentences do not earn their place in a tool definition and distract from the actual functionality.

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 thoroughly explains return values (per-check preflight results, simulated verdict, index status) and common failure modes (v1 rejection, 400 vs 402). It is complete for understanding the tool's behavior, though the extra marketing content slightly muddles focus. The presence of an output schema reduces the need to describe structured returns further.

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% with both url and method described. The description adds meaningful nuance to the url parameter ('probed exactly as given — try the bare URL your discovery doc advertises') and explains why the bare URL matters due to crawler behavior. This slightly exceeds the schema's 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?

The description clearly states a specific verb and resource: 'check whether an x402-payable HTTPS endpoint is configured to be indexed by the Coinbase x402 Bazaar'. It distinguishes from sibling tools like check_bazaar_listing by focusing on preflight endpoint validation rather than listing 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?

The description explicitly says 'Use this FREE utility' and explains when it applies. It provides clear alternatives: if the endpoint is rejected, use the Bazaar Listing Package via create_bazaar_listing or request_quote for exotic stacks. However, it lacks a direct 'when not to use' statement, and the broad 'any agent or seller' is slightly unspecific.

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, idempotentHint=true, destructiveHint=false. The description adds context about trust-progressive disclosure and return of URL/summary, reinforcing safe behavior without contradiction.

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 sentences, front-loaded with directive usage guidance followed by contextual framing. No wasted words; every sentence 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 simple read-only tool with good annotations and output schema, the description covers the high-level purpose and usage context well. However, the complete lack of parameter explanation leaves a notable gap.

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 only parameter compliance_filter has 0% schema description coverage, and the description provides no explanation of its purpose, format, or expected values. This is a significant omission.

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 verifying certifications, compliance posture, or operational record, and specifies it returns a URL and summary. It distinguishes from siblings by mentioning trust-progressive disclosure and buyer_context, which aligns with no other sibling tool.

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 says when to use: 'before sharing buyer_context' and as part of 'trust-progressive disclosure'. Provides clear context, though does not explicitly mention when not to use or list 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds behavioral context by revealing the scan reports current level, passing checks, and failing checks with fix strings, and notes it is a re-scan of the live site. This goes beyond annotations by specifying output content and the post-deploy framing, though it doesn't mention rate limits or edge cases.

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, each earning its place: first gives the usage trigger, second describes the action and outputs, third distinguishes from scan_site. The description is front-loaded with 'Use this after...' and contains no redundant or filler 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?

With a simple 2-parameter schema and an output schema present, the description covers the core usage context, behavioral output, and sibling relationship. It doesn't explain how expectedLevel is used if omitted or behavior on invalid URLs, but the output schema and annotations cover enough for a well-scoped verification 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 0%, so the description must compensate. It partially defines expectedLevel ('expected level') and url ('the live site') through context, but does not explicitly describe parameter formats, types beyond the schema, or examples. It adds some meaning but leaves room for ambiguity, especially for expectedLevel's optional nature.

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: 'confirm the live site reaches the expected level' and 'Re-scans the site, reports current level, which checks pass, and which still fail with their fix string.' It explicitly differentiates from sibling scan_site by framing as post-deploy verification rather than initial assessment, providing a specific verb+resource with clear 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?

Explicit when-to-use guidance is provided: 'Use this after a customer has deployed the agent-ready files...' It also names an alternative tool (scan_site) and explains the distinction: 'Same scanner as scan_site, but framed as post-deploy verification rather than initial assessment.' This clearly orients the agent to choose this tool over siblings.

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