Server Quality Checklist

Tool Scores

• x402_ecosystem_statsA
  3.9/5.0
  Behavior2/5

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

  No annotations are provided. The description fails to disclose data freshness (e.g., how often the snapshot updates), rate limits, or whether the output is static or dynamic. For a tool with zero annotations, the description carries the full burden and doesn't address these behavioral traits.

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

  Conciseness5/5

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

  Two sentences: first enumerates data points, second gives usage guidance. No redundant words. Every sentence earns its place.

  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 zero-parameter, no-output-schema tool, the description is adequate but lacks details on output format, update frequency, or size limits. It covers the 'what' well but misses the 'how' and 'limitations,' leaving some gaps for an agent to navigate.

  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 input schema has zero parameters, so schema description coverage is 100%. The description adds value by explaining the content of the snapshot, though this is more about output. Baseline for no params is 4, and the description does not detract.

  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 uses specific verbs like 'aggregate snapshot' and lists exact metrics (endpoints, settlement volume, etc.). It clearly distinguishes from sibling tools like x402_endpoint_history or x402_trust_score by focusing on ecosystem-wide stats.

  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 'Use this to gauge market health before transacting,' providing a concrete when-to-use scenario. It could be improved by explicitly naming when not to use (e.g., for individual endpoint details), but the context allows inferring differentiation from siblings.

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

• x402_watch_renewA
  3.9/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses that secret stays same and payment model, but omits behavior on invalid watch_id or expired watch, and does not mention idempotency or 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.

  Conciseness5/5

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

  Two sentences with no superfluous words. Information is front-loaded and efficiently conveys core functionality, payment, and secret persistence.

  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?

  No output schema, so description should explain return format. It vaguely mentions 'returns the price quote,' but does not specify structure or cover error cases like missing watch or expired watch. Lacks completeness for a mutation tool.

  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% and parameter description in schema is adequate ('Watch id returned by x402_watch_create'). The tool description adds no extra meaning about the parameter itself, only behavioral context.

  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?

  Clearly states the tool extends an active watch by 30 days, distinguishing it from sibling tools like x402_watch_create (creates) and x402_watch_events (lists events).

  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?

  Specifies timing ('before it expires') and payment behavior (auto-pay or price quote). However, it does not explicitly state when not to use it (e.g., if watch expired) or mention alternatives like creating a new watch.

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

• x402_endpoint_historyA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden. It discloses pay-per-call behavior, auto-pay logic, and measurement specifics (single EU vantage point, includes network distance). This adds valuable 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.

  Conciseness5/5

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

  Two sentences, no wasted words. The first sentence packs all essential details, the second adds pricing and measurement context. Highly efficient.

  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 no output schema, the description sufficiently describes the return (time-series of events and probe results). It covers input, output, pricing, and measurement caveats. It is complete for a history tool, though pagination or format details are omitted.

  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?

  Schema coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema by explaining the types of events in the time-series (listing, delisting, price changes, probe results) and measurement details, enriching the understanding of the parameters.

  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 provides 'Raw observation time-series for a SPECIFIC x402 endpoint' and lists the events included. It distinguishes from sibling tools that focus on ecosystem stats or trust scores.

  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 implicitly tells when to use: when you need historical data for a specific endpoint. It does not explicitly mention when not to use or alternatives, but the context of sibling tools makes the use case clear.

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

• x402_trust_leaderboardA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses that it's free, top-25, deterministic trust score with components, and that latency is measured from a single EU point and lightly weighted. Addresses limitations honestly.

  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?

  Three concise sentences, each serving a purpose: main output and ranking criteria, latency measurement detail, and use case recommendation. 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?

  Without an output schema, the description explains the output content (top-25 endpoints, trust score factors) and pricing (free). Sufficient for a simple list tool with no parameters.

  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?

  Tool has zero parameters and schema coverage is 100%, so per guidelines baseline is 4. Description adds no parameter info but none is needed.

  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?

  Clearly states it lists the top-25 most trustworthy x402 endpoints based on a deterministic trust score. Distinguishes from siblings by specifying 'free' and 'top-25', differentiating it from other trust tools like x402_trust_score or x402_trust_bulk.

  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?

  Explicitly says 'Use this to discover reliable paid endpoints,' providing clear context for when to use. Does not mention when not to use or directly compare with alternatives, but the use case is well-defined.

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

• x402_watch_editA
  4.4/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses key behaviors: bearer authentication, connection testing for new URLs, atomicity (unchanged config on failure), full-replace semantics, and return of updated watch view. Missing some edge-case error behavior, but adequate.

  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 three sentences, front-loaded with the main action, and every sentence adds essential information without redundancy.

  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 no output schema, the description mentions returns the updated watch view, which is sufficient. It covers the main functional aspects, though error handling details are omitted. Overall, complete for a mutation tool.

  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?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining connection testing and full-replace behavior, which goes 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 clearly states the tool's purpose: 'Edit an active watch: change webhook/Slack URLs, liveness sensitivity, or subscribed events.' It uses specific verbs and resources, and distinguishes itself from sibling tools like create, cancel, and renew.

  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: requires a secret from x402_watch_create, and explains the full-replace behavior per channel. However, it does not explicitly exclude cases where this tool should not be used (e.g., for creating a new watch).

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

• x402_find_alternativesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description fully discloses behavioral traits: pay-per-call cost (~$0.005), auto-pay behavior, similarity independence from latency/geography, and the fields returned. It does not mention error handling or auth details beyond wallet configuration, but covers major behavioral aspects.

  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 a single, well-structured paragraph with no redundancy. It front-loads the core purpose and progressively adds details (use case, output fields, exclusions, pricing). Every sentence earns its place without verbosity.

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

  Completeness5/5

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

  Given no output schema, the description fully explains the return object (fields like score, grade, similarity, price, endpointPage URL). It covers purpose, parameters, usage, behavioral notes, and edge cases (empty array). An agent has sufficient information to invoke correctly.

  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?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining how parameters are used (e.g., 'before paying' for resource, default limit, minScoreDelta threshold), and provides an example URL. This goes beyond the schema alone.

  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 verb 'find' and resource 'better-scored alternatives to an x402 endpoint'. It specifies the action: given an endpoint URL, return semantically similar endpoints with higher trust scores. This distinguishes it from siblings like x402_trust_score (single score) and x402_trust_leaderboard (ranking), making the 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?

  Explicit usage guidance is provided: 'Use this to route away from a mediocre/dead/expensive endpoint... before paying, check if a higher-graded equivalent exists.' It also explains valid empty response and exclusions (same-host siblings, 'avoid'-flagged). Lacks direct comparison to sibling tools but the niche is clear.

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

• x402_semantic_searchA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly: deterministic ranking with exact tie-break order, the 0.5 similarity floor, the effect of missing descriptions, null score/grade behavior, payment/auth behavior, and the exact returned fields are all disclosed. There is no contradiction with any annotation because none exist.

  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 well structured and front-loaded: purpose first, then ranking behavior, then edge cases, then output fields, then cost. It is verbose, especially in the missing-description paragraph, but nearly every sentence earns its place given the absence of annotations and output schema.

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

  Completeness5/5

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

  Despite having no output schema and no annotations, the description is self-contained: it enumerates all returned fields, the null behavior for unscored endpoints, pricing, payment fallback, and the deterministic ranking semantics. An agent has everything needed to invoke the tool and interpret its result correctly.

  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 input schema already documents both parameters fully at 100% coverage, so the description does not need to add much. It reinforces the semantic-matching nature of 'query' and the 'up to 25' limit, but it does not materially add new parameter-level constraints or syntax 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 opening sentence states a specific verb ('SEMANTIC SEARCH'), a specific resource ('the entire monitored x402 endpoint catalog'), and a clear output ('up to 25 endpoints whose advertised purpose is semantically closest'). This makes the tool's role as a discovery/search tool obvious and distinguishes it from the trust-score, leaderboard, and watch siblings.

  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 says 'Use this for DISCOVERY: find candidate endpoints for a capability before checking any of them in depth.' It also explicitly excludes verdicts, recommendations, and flag details, and directs the agent to x402_trust_score for those, which is clear when-to-use and alternative guidance.

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

• x402_watch_cancelA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: soft-cancel (not delete), no new events, events readable until original expiry, probing cadence drops, auth requirement, free, idempotent. Comprehensive.

  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?

  Three sentences, front-loaded with key information, 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.

  Completeness4/5

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

  Covers what the tool does and its effects. No output schema but idempotency implies minimal response. Minor gap on exact return value, but overall complete for a cancellation tool.

  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?

  Schema coverage is 100%, and description adds value by explaining the secret is from x402_watch_create and watch_id is from create. Provides provenance 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?

  Clearly states the tool performs a soft-cancel on a watch, distinguishing it from a delete. The verb 'cancel' and resource 'watch' are specific, and the description adds nuance about event log readability.

  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?

  Provides context on when to use (immediate soft-cancel), contrasts with delete, and mentions idempotency. Could be more explicit about alternatives among siblings, but the sibling list makes it clear this is the cancel tool.

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

• x402_watch_eventsA
  4.6/5.0
  Behavior5/5

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

  No annotations provided, so description carries full burden. It reveals that nothing is lost between polls, cursors are global sequences, and cancelled watches stay readable. This provides comprehensive behavioral context beyond a simple read operation.

  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 paragraph of about 10 sentences, packing substantial information without excessive verbosity. Could benefit from light structuring (e.g., separating streams), but remains clear and focused.

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

  Completeness5/5

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

  No output schema, but description covers both event streams, cursor usage, reliability guarantees, lifecycle behavior, and push reconciliation. This provides all necessary context for correct usage without needing to infer.

  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?

  Schema coverage is 100%, and the description adds valuable context: since and watch_since are cursors from previous polls, and secret/watch_id come from creation. It explains cursor advancement and global sequence nature, exceeding schema 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 clearly states the tool reads an append-only event log for an x402 watch, returning two streams. It distinguishes from sibling tools (create, cancel, edit, renew) by focusing on polling and event retrieval.

  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 explains when to poll, how to use cursors, and that cancelled watches remain readable. It mentions push delivery reconciliation, but does not explicitly list scenarios where alternative tools should be used instead.

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

• x402_watch_createA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and does so thoroughly. It discloses critical behaviors: payTo changes on templated endpoints are severity 'warn' not 'critical', liveness_flapping coalesces alerts, all URLs are connection-tested before payment with no charge for unreachable ones, webhook signature details (HMAC-SHA256 keyed by hex of sha256 secret, not raw secret), and pay-per-call cost. This is exemplary transparency beyond the 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?

  The description is long due to the tool's complexity, but every sentence adds value: purpose, event semantics, flapping behavior, return URLs, alternatives, URL configuration, signature format, and cost. It is front-loaded with the primary purpose and flows logically. No tautology or filler.

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

  Completeness5/5

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

  Given the tool's complexity, no annotations, and no output schema, the description is remarkably complete. It explains return artifacts (bearer secret, poll/renew/edit/cancel URLs, next_steps), payment flow, webhook signature construction, event types, and delivery testing. The only minor omission is a detailed list of event types (left to schema), but the description mentions them by name and provides enough for an agent to invoke correctly.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds extra semantics: webhook_url/slack_url accept a single string or an array (max 5), all URLs are connection-tested before payment, and delivery is reported in 'delivery.connection_test'. These details go beyond the schema's property descriptions, enhancing understanding of parameter behavior.

  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 opens with a specific verb+resource: 'Start monitoring ONE x402 endpoint for 30 days.' It clearly differentiates from siblings by naming x402_watch_events for polling and mentioning renew/edit/cancel URLs returned on success. The scope (one endpoint, 30 days) and delivered event types are explicit.

  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 on when to use this tool (start a new monitor) and explicitly names an alternative for consuming events: 'Use x402_watch_events to poll the append-only log.' It also describes payment behavior and that URLs are connection-tested before payment, but does not give explicit 'when not to use' exclusions beyond implying this is for creation. This is clear context without a full when-not matrix.

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

• x402_trust_scoreA
  4.8/5.0
  Behavior5/5

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

  No annotations are provided, so the description fully carries the transparency burden. It discloses live-probing for uncataloged endpoints, the low-confidence first-contact flag, the latency measurement from a single EU vantage point, the meaning of 'unverified' (unknown, not bad), and the expectation that payTo/price may vary for templated endpoints. It also warns that provider-advertised claims are unverified.

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

  Conciseness3/5

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

  The description is a single dense paragraph with no visual structure, making it harder to scan. Every sentence does convey distinct information, but the lack of bullets, sections, or numbering hurts readability. It is comprehensive but not concise; the sheer length may overload an agent trying to quickly extract key usage rules. It earns a 3 as a minimum viable score for structure.

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

  Completeness5/5

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

  With no output schema, the description must explain return values, and it does so thoroughly: it lists the score, grade, verdict, price, scoreRange, flagsDetailed, component breakdown, provider claims, and 30-day stats. It covers edge cases (parameterize, unverified, not-payable) and caveats (latency, payTo variation), making the tool's behavior and outputs fully understandable for an agent.

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

  Parameters5/5

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

  Although the schema already describes `resource` as a full x402 resource URL, the description adds substantial nuance: it gives an example, explains how uncataloged endpoints are probed, and details how template placeholders like {slug} or :slug are treated with a 'parameterize' verdict. This goes well beyond the schema's simple description and helps the agent understand both the format and behavioral expectations for the input.

  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 it computes a trust score for a SPECIFIC x402 endpoint, with a verdict, price, and structured flags. It explicitly contrasts with broader tools by emphasizing specificity ('SPECIFIC x402 endpoint') and saying 'One call answers WHETHER and at WHAT PRICE to use an endpoint', which differentiates it from siblings like x402_ecosystem_stats or x402_trust_bulk.

  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 explicit when-to-use guidance: 'Call this BEFORE paying an unknown x402 endpoint to avoid dead, fraudulent, or recently-hijacked services.' It also provides decision rules for each verdict (parameterize, unverified, not-payable), telling the agent what actions to take or not take for each case, and notes when auto-pay occurs vs. returning a quote.

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

• x402_trust_bulkA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden. It thoroughly discloses paid nature, cache staleness (~15 min), recompute limits, response flags (recompute_limit_hit), automatic tier selection, pricing, and found:false behavior. This is comprehensive behavioral transparency.

  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?

  Although longer than typical, every sentence adds essential operational detail (purpose, outputs, caching, limits, pricing, alternatives). The structure front-loads the primary purpose and then covers edge cases, making it remarkably information-dense without fluff.

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

  Completeness5/5

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

  Given the tool has no output schema, the description comprehensively explains the return fields (trust score, grade, recommendation, confidence, timestamps, recomputed flag) and all relevant edge cases (not-found, recompute limits, payment behavior). This makes the tool complete for both selection and invocation.

  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?

  Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: automatic tier selection, pricing for each tier, and the implication that resources not in the observation set still cost money. It also clarifies the 'resources' parameter semantics with the found:false behavior, adding value beyond the raw 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 uses a specific verb ('Score') and resource ('x402 endpoints') in a clear scope ('up to 500' in a 'SINGLE paid call'). It distinguishes from siblings explicitly by naming x402_trust_score as the alternative for fresh live probes.

  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?

  Provides explicit usage context: suitable for bulk scoring using cached data, with clear guidance that live probing is handled by x402_trust_score. It also warns about paying even for resources not found and explains the per-request recompute limits, helping agents decide when to call this tool.

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

• x402_trust_previewA
  5/5.0
  Behavior5/5

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

  Discloses complete behavioral details: returns three specific samples with full reports, is free, and cannot score user-chosen endpoints. No side effects, but as a read-only preview, no additional disclosure is needed. With no annotations, the description fully covers behavioral traits.

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

  Conciseness5/5

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

  Every sentence is informative and necessary. The description is front-loaded with the key purpose and constraints, and flows logically without fluff.

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

  Completeness5/5

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

  Given no output schema, the description fully explains what the sample reports contain (every field). It also addresses the use case and limitations. The tool is simple, and the description leaves no gaps.

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

  Parameters5/5

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

  The tool has zero parameters and schema coverage is 100%. The description adds meaning by explaining that you do not choose the endpoint, which clarifies the lack of parameters 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 is a free showcase returning complete trust reports for three sample endpoints (best, median, worst). It distinguishes from x402_trust_score (paid) by explicitly noting it cannot score a user-chosen endpoint.

  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?

  Explicitly states when to use (to preview paid output before paying) and when not to use (to evaluate your own endpoint, instead use x402_trust_score). Also notes it takes no arguments.

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