Server Quality Checklist

Tool Scores

• get_cleared_statusB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for behavioral disclosure. It offers only thin hints: the reference to 'same payload as lookup_merchant' and 'probe=false' imply it executes a check variant, but it never says what the payload contains, whether the operation is read-only, what error/not-found behavior occurs, or how 'cleared status' is represented. An agent cannot infer the return shape without going to look up lookup_merchant.

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

  Conciseness4/5

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

  The description is a single sentence with the core purpose front-loaded before the routing note, so it is efficient and earns its place. The downside is density: the parenthetical '(Check, probe=false)' packs in unexplained jargon that forces the reader to parse technical shorthand, slightly hurting readability despite the brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one documented parameter, no output schema, and no annotations, the description carries the full burden of explaining what the agent should expect, and it falls short. It reveals nothing about the payload contents, the meaning of 'cleared status', or the semantics of 'probe=false'. An agent evaluating whether this tool satisfies its goal is left to investigate lookup_merchant merely to understand the return value.

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

  Parameters3/5

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

  The single parameter 'slug' is fully documented in the schema with an example ('coinbase-identity'), so coverage is 100% and the baseline is 3. The description adds nothing about the parameter beyond the schema — it doesn't clarify accepted formats, normalization, or the relationship between slug and domain. It neither compensates for a gap nor adds value, so it stays at the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description does state a verb and resource ('Cleared status for a slug/domain') and distinguishes itself by name-checking lookup_merchant, which separates it from siblings like cleared_check and get_trust_score. However, the parenthetical '(Check, probe=false)' is cryptic jargon that muddies what the tool actually does, and the claim 'same payload as lookup_merchant' leaves it ambiguous whether this returns the full lookup payload or only a cleared-status field. The core purpose is recoverable but not crisp.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit routing guidance: 'Prefer lookup_merchant in new agent loops.' This clearly tells the agent when NOT to use this tool and names the preferred alternative, which is valuable given the crowded sibling list. The gap is that it never states the conditions under which this tool SHOULD be used (it implies legacy/backward-compat only), and it does not explain WHY lookup_merchant is preferred.

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

• get_trust_scoreA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses that it avoids a full catalog load, which is useful, but the cryptic 'probe=false' is unexplained, and it does not state the return format or whether there are any side effects. It adds some transparency but leaves gaps.

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

  Conciseness4/5

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

  The description is a single sentence that gets to the point quickly. The parenthetical '(probe=false)' is slightly cryptic but not overly verbose. It is well-front-loaded and generally concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter read tool without an output schema, the description gives the essential action and scope. However, it does not describe what the breakdown contains or how to interpret the result, and the 'probe=false' reference is unexplained, leaving some ambiguity for complete usage.

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

  Parameters3/5

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

  The schema coverage is 100% with a clear description for 'slug'. The tool description only rephrases 'slug' as 'origin/slug', adding no new semantic meaning. It meets the baseline but does not compensate further.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Uses a specific verb ('Get') and resource ('detailed trust score breakdown'), and clearly scopes it to an 'origin/slug'. The phrase 'via Cleared Check (probe=false) — no full catalog load' distinguishes it from siblings like list_cleared_services or get_cleared_status, making its purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is a lightweight, targeted lookup ('no full catalog load') for getting a detailed breakdown. While it does not explicitly name alternatives or when-not-to-use, the context is sufficient for an agent to infer when this is the appropriate tool.

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

• report_deliveryA
  3.8/5.0
  Behavior3/5

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

  The description indicates a write operation (POST) but does not disclose potential side effects, idempotency, or whether the action is reversible. It also does not mention any dependencies (e.g., must have a prior payment). Since no annotations are provided, the description carries the full burden, but it lacks these behavioral details.

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

  Conciseness5/5

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

  The description is concise and to the point, with no redundant wording. It packs the essential information (action, endpoint, outcome values, and usage context) into a single sentence, making it easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides sufficient context for when and why to use the tool ('after pay' and 'learn route quality'). It does not mention the response format or error handling, but since no output schema is defined, this is not strictly required. The description is adequate for an agent to decide when to invoke it.

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

  Parameters3/5

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

  The schema provides descriptions for all four parameters (origin, source, outcome, requestId), covering their meaning and defaults. The tool description does not add any additional semantic value beyond what is already in the schema, so the baseline score of 3 applies given high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Report Gateway route delivery outcome') and specifies the HTTP method and endpoint ('POST gateway/track'). It also provides the outcome values ('delivered|not_delivered') and the contextual reason ('Call after pay so Cleared can learn route quality'). While it could be more explicit about the exact resource being updated, the verb and resource are clear enough to distinguish it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a specific condition for use ('Call after pay') and explains the purpose ('so Cleared can learn route quality'). It implies this is a post-action reporting step. However, it does not explicitly state when not to use the tool or mention alternatives, leaving some ambiguity about edge cases.

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

• check_domain_statusA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden, and it does add some value by noting this uses 'Check (probe=false)' and that it is an alias of get_cleared_status. This implies a non-mutating verification action, but it does not explicitly state read-only behavior, auth requirements, or what the response contains. It is adequate but not deeply transparent.

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

  Conciseness4/5

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

  The description is one tight sentence with the main action front-loaded and routing context appended. The phrase 'sandwich step 1' is cryptic, but overall there is no fluff and every clause contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has only one parameter, no annotations, and no output schema, the description covers the essential coordination pointers: alias identity and an explicit alternative for a specific use case. It leaves 'sandwich step 1' undefined and does not describe the return value, but for a simple check tool this is largely acceptable.

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

  Parameters3/5

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

  The schema already provides 100% coverage for the single slug parameter with an example. The description adds no additional parameter detail beyond calling it a 'domain/service', which roughly matches the schema's description. This is a baseline 3 case where the schema handles the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Check if a domain/service is verified on ClearedIndex') and the resource, and it differentiates from siblings by explicitly naming this tool as an alias of get_cleared_status and calling out lookup_merchant as the preferred alternative for a specific workflow. The purpose is unambiguous even though 'sandwich step 1' is jargon.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit routing guidance: it notes this tool is an alias of get_cleared_status and that lookup_merchant should be preferred for 'sandwich step 1'. However, the condition 'sandwich step 1' is not explained, and it doesn't enumerate when to choose this tool over get_cleared_status, so the guidance is present but slightly under-specified.

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

• submit_for_reviewA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full behavioral burden. It does add useful behavioral context by saying this is a submission action and returns a listing URL plus initial checks, implying a verification workflow. However, it does not disclose potential side effects such as duplicate submissions, resubmission rules, or whether the listing is immediately visible.

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

  Conciseness5/5

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

  Two concise sentences: the first states the action and target, the second states the result. There is no redundant language or repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives the essential return information and the schema covers the eight required parameters. Still, the description does not explain the verification stage after submission, what the 'initial checks' include, or any prerequisites for the endpoint schema being submitted.

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

  Parameters3/5

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

  Schema description coverage is high (88%), so the input schema already documents most parameter meanings. The description adds the x402 endpoint context but does not explain any schema fields beyond what is already present. A baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses the specific verb 'Submit' with a clear resource ('new x402 endpoint/service to ClearedIndex for trust verification') and states the return value ('listing URL and initial checks'). It is immediately distinguishable from the surrounding read/check/status sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Phrases like 'Submit a new' and 'for trust verification' clearly signal when this tool should be used. It does not explicitly name read-only alternatives or exclusions, but the submission intent is clear enough that an agent can select it without confusion.

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

• get_badgeA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It implies a read-only operation returning a URL, but does not mention side effects, permissions, error handling, or what happens if the slug is invalid or the service is not verified. Gives a basic idea but lacks explicit behavioral details.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the primary action and followed by a practical use case. No unnecessary words or repetition, achieving high efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description covers the main purpose and a common use case. It does not elaborate on authentication, URL format, or conditions for verification, but these are not critical for basic usage. Overall, sufficiently complete given the simplicity.

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

  Parameters3/5

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

  Schema description fully covers the slug parameter (100% coverage), so baseline is 3. The tool description adds no additional detail about the parameter itself, though 'for a verified service' hints at a constraint. No significant enrichment beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: obtaining the ClearedIndex trust badge URL for a verified service. It uses a specific verb ('Get') and resource (trust badge URL), and mentions a use case (embedding verification status), making it distinct from sibling tools like get_trust_score or get_cleared_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a use case ('useful for embedding verification status') but does not explicitly contrast it with sibling tools or specify when not to use it. Lacks explicit when/when-not guidance, but the purpose is clear enough to guide selection.

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

• lookup_merchantA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that this is a 'probe=false' operation (likely a read-only check) and indicates it returns security-relevant fields (pass, score, payToMismatch, tier), which suggests it may affect payment routing. However, it doesn't state whether it makes any external calls, has side effects, or requires authentication. For a tool that gates payments, this is a notable gap, but it does provide some behavioral hints beyond the minimal.

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

  Conciseness5/5

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

  The description is two sentences long, front-loads the critical 'DEFAULT before pay' warning, and includes a clear instruction. Every sentence contributes: the first defines the action and output, the second specifies when to use. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter lookup tool with a well-documented schema, the description is nearly complete. It explains the purpose, key return fields, and when to call it. It doesn't explain error handling or the meaning of 'profile URL', but given it's a verification check before payment, an agent likely needs this. An explicit note about what 'pass' means would be helpful but is a minor gap.

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

  Parameters3/5

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

  The schema description for the only parameter (origin) is already detailed, covering URL, domain, or slug with examples. The description adds context by saying it's for 'merchant origin/slug' but doesn't add meaningful new semantics beyond what the schema covers. Given 100% schema coverage, the baseline of 3 is appropriate; the tool adds minimal extra value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'look up a merchant origin/slug on Cleared Index via Check'. It specifies the resource (Cleared Index) and the method (Check), and lists key return fields (pass, score, payToMismatch, tier, profile URL). This is distinct from siblings like 'cleared_check' and 'list_cleared_services', as it focuses on merchant lookup before payment.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states 'Call this before any x402 payment to an unknown merchant', which gives strong usage context. However, it doesn't explicitly mention alternatives or when not to use this tool. The context is clear enough for an agent to know when to use it, but it lacks exclusions (e.g., 'use cleared_check for ...') to fully distinguish from similar siblings.

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

• cleared_checkA
  4.2/5.0
  Behavior4/5

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

  Annotations are absent, so the description carries the burden. It discloses the probe=false default (fast, catalog-safe) and implies non-destructive verification. It doesn't state side effects or required auth, but for a read-like check, the description gives useful behavioral context. Minor gap: no mention of rate limits or termination behavior.

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

  Conciseness5/5

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

  Two sentences, no filler, and front-loaded with the primary purpose. Return fields are listed concisely, and the probe note is placed at the end. Very efficient and structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 2 parameters and no output schema, the description covers purpose, key defaults, and return values. It lacks explicit edge cases or usage examples, but given the simplicity, it's almost complete. A 4 is appropriate.

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

  Parameters3/5

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

  Schema coverage is 100%, so both parameters are documented. The description adds meaning by explaining probe=false is 'fast, catalog-safe' and default, which enriches the parameter semantics. However, it doesn't explain the impact of probe=true beyond live-probing. Baseline 3 is justified because schema covers the basics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('verify') and resource ('an origin before pay'), and enumerates the return fields (pass, score, payToMismatch, tier, card URL, provenance). It differentiates from siblings like get_trust_score or check_domain_status by focusing on 'before pay' verification. The title 'Cleared Check' adds clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: verify an origin before payment, which is clear context. It does not explicitly exclude alternatives or state when not to use it, but it hints at the probe setting for agent farms. Lacks explicit 'when to use' vs 'when not to use' guidance, so a 4 is appropriate.

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

• list_cleared_servicesA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It conveys a read-only catalog load and distinguishes itself from single-origin checks, but it does not disclose pagination, result shape, or any notable constraints, which matters for a tool with no output schema.

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

  Conciseness5/5

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

  Two sentences, with the core purpose first and the sibling guidance second. Every phrase earns its place; there is no padding or schema duplication.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-parameter, optional-parameter list tool, the description plus schema provides enough to invoke it: what it lists, the available filters, and when to use it versus alternatives. Missing pagination/output details keep it from a 5, but nothing essential blocks a correct call.

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

  Parameters3/5

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

  The schema already documents both optional parameters with descriptive text and allowed values, so schema coverage is 100%. The description only restates the category filter and adds no new meaning beyond the schema's parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description leads with a specific verb ('List') and resource ('verified services on ClearedIndex'), and explicitly marks category filtering as optional. It also contrasts itself with cleared_check/lookup_merchant, so the agent can tell catalog listing apart from single-origin lookups.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives an explicit routing rule: prefer cleared_check or lookup_merchant for single-origin sandwich steps, and use this tool to 'load the catalog.' That is a clear when-not-to-use instruction plus alternative selection, leaving little ambiguity.

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

• route_gatewayA
  4.2/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden. It discloses a rate limit ('100 free routes/month'), a non-requirement ('no API key'), and the nature of the response (payTo URL + totalCost), implying a read-only lookup. It does not explicitly state side effects (e.g., mutating state), but the context of routing suggests no permanent changes. It provides meaningful behavioral context beyond the schema, though it could be more explicit about idempotency or external calls.

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

  Conciseness5/5

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

  The description is compact and front-loaded. The first sentence establishes the tool's unique value ('one call, best verified x402 endpoint'), followed by what it routes, its output, its usage context, and then a key constraint. Every sentence earns its place with no fluff, making it efficient and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has six parameters (all schema-described) and no output schema, the description covers the essential execution details: how to use it, what to expect in return, and usage limits. It does not elaborate on routing strategy nuances or error cases, but the schema fills those gaps. For a routing tool, the description is sufficiently complete for an agent to invoke it correctly without additional investigation.

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

  Parameters3/5

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

  The schema has 100% coverage, so all six parameters are documented with descriptions. The tool description adds only a high-level hint that routing considers 'trust score, price, latency, and canary,' but this does not substantially supersede the schema's per-parameter details (e.g., defaults, enums). Given the baseline of 3 for full schema coverage, the description does not add enough extra semantic value to raise the score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Routes by trust score, price, latency, and canary') and the resource ('Cleared Gateway') and specifies the output ('Returns payTo URL + totalCost'). It distinguishes the tool from siblings by positioning it as the routing step after lookup_merchant, making its role unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage context: 'Use after lookup_merchant when you need category routing.' This tells the agent when to invoke it relative to a sibling. However, it does not explicitly state when NOT to use it or mention alternatives (e.g., list_cleared_services) for filtering or discovery, so it lacks exclusions. 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.

• agent_readA
  4.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavioral traits. While it implies a read-only operation (providing intelligence), it does not explicitly state that it has no side effects, nor does it mention any security, rate limiting, or data handling characteristics. The description is informative but lacks explicit behavioral guarantees.

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

  Conciseness5/5

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

  The description is concise, using only a few sentences. It front-loads the core function, then lists the outputs, and ends with usage context. No redundancy or filler, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description provides essential context: it fits into a broader workflow (after lookup_merchant, before payment) and lists what the tool returns. While it does not describe an output schema (none exists), it covers the primary aspects an agent needs to decide when to call and what to expect. Minor gap: it doesn't mention error cases or fallback behavior, but that is not critical for typical usage.

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

  Parameters4/5

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

  The schema has one parameter, 'slug', with a description: 'Cleared listing slug or origin (e.g. taylor-good-agents)'. The description further clarifies that it accepts a slug or origin, matching the schema. The example provides concrete guidance, though it does not specify the exact format or constraints beyond that.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: providing routing intelligence for a listing, including verdict, when-to-call, settle posture, endpoint hints, and payToMismatch. It distinguishes itself from sibling tools by its focused role in the merchant lookup and payment flow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  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: 'Call after lookup_merchant before paying an unknown merchant.' It also clarifies the accepted input (slug or origin), giving the agent a clear trigger and context.

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