Lumière PayCheck

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the tool is free and parameterless and characterizes the data as catalog-wide aggregates rather than per-endpoint detail, which is useful scoping context. It does not add anything beyond that (no rate limits, caching, or freshness caveats), so it is good but not rich.

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 the scope and returned content before the routing guidance. Every sentence carries information, though the verdict enumeration and the 'for context or reporting' example add a little redundancy that keeps it short of maximally tight.

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?

An output schema exists, so the description need not detail return values, and it still sketches the shape of the result (counts per verdict, last computed). With zero parameters, full annotation coverage, and explicit sibling routing, an agent has everything needed to select and invoke this tool correctly.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description's closing 'no parameters' statement is consistent with the empty input schema and confirms that no filtering or pagination options exist.

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?

States a specific verb and resource ('Get an overview of the whole monitored x402 catalog') and enumerates the exact content returned: endpoint counts, verdict breakdown (proceed, caution, avoid, free, insufficient_data), and last-computed timestamps. It explicitly distinguishes itself from siblings by naming check_endpoint, top_endpoints, and check_payment as the tools for single-endpoint or ranked-list needs.

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?

Gives explicit when-to-use ('for context or reporting, for example to tell a user how much of the x402 ecosystem passes checks') and explicit when-not ('says nothing about any single endpoint'), with a named alternative for each adjacent use case. Nothing is left to inference about routing between this and its siblings.

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?

Goes well beyond the annotations by disclosing that the check is free, that it reflects monitoring every 30 minutes and real test payments, that a brand-new endpoint may return insufficient_data, and that uncataloged endpoints return monitored:false. These are concrete behavioral traits an agent needs to interpret the result.

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 and return values, then usage routing, then caveats and a docs link. It is fairly long but nearly every sentence carries decision-relevant information; the trailing API docs URL is the only mildly extraneous element.

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?

An output schema exists, yet the description still helpfully previews the verdict vocabulary and edge-case return values. Combined with the weaker alternatives routing, an agent has everything needed to call this correctly and interpret results.

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?

One parameter with 100% schema description coverage, so the schema already explains the url format and example. The description adds no parameter-level guidance beyond what the schema provides, matching the baseline 3 when the schema carries the semantic load.

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

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

The description states a specific verb and resource ('Get the trust verdict for one x402 endpoint') and enumerates the returned signals (score, grade, verdict, uptime, payout incidents, buyer counts). It is instantly distinguishable from siblings like check_payment and top_endpoints.

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 routing: use this 'before you have a price quote,' use check_payment 'when you already have the 402 quote... and are about to pay,' and use top_endpoints 'to discover good endpoints rather than check a known one.' Both when-to-use and named alternatives are covered.

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 readOnly/idempotent/non-destructive, but the description adds behavior the annotations cannot: it is free, it does not make or block the payment itself, allow is true only when every rule passes, and the reasons list explains a false result. It also discloses the rule set being evaluated (trust verdict, cap, monitored price, payTo match, optional organic-share).

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 the core decision and the rule list, and every sentence carries new information (rules, optional rule, usage timing, alternative, safety profile, false-case behavior, docs link). It is dense and slightly long for a single paragraph, but there is no filler to cut.

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 an output schema present, return values need not be re-explained, yet the description still summarizes allow/reasons. For a 10-parameter decision tool it covers the decision logic, the preconditions, the alternative sibling, and a docs link — nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by framing three parameters in context (amount/payTo/network come from the 402 quote) and by naming minOrganicShare with its intent. It still leaves maxAmount, allowCaution, and requireVerified entirely to the schema, so it does not fully substitute for per-parameter reading.

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?

States a precise verb+resource ('Decide whether a specific x402 payment should go through') and immediately describes the return shape (allow true/false with reasons). It explicitly distinguishes itself from the sibling check_endpoint, so an agent can route without opening either schema.

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?

Gives the exact moment to use it ('right before a payment, with the amount, payTo, and network from the endpoint's 402 quote') and names the alternative with the condition that selects it ('Use check_endpoint instead if you only want an endpoint's grade without a quote in hand'). Both when-to-use and when-to-use-something-else are explicit.

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 annotations already declare a safe read-only, idempotent, non-destructive profile, and the description goes further by disclosing that the call itself does not perform the purchase, that payment happens through an x402 client on the returned report URL, and that unmonitored endpoints return 404 and are never charged. That is genuinely non-obvious behavior beyond the annotations, though actual billing mechanics (rate limits, cost of the quote call) remain unspecified.

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?

Purpose and the critical 'doesn't buy the report' caveat are front-loaded in the first two sentences, and the later sentences add routing, pricing, and edge-case value. It is a dense paragraph whose later clauses, such as the catalog of other paid checks, are slightly tangential to the core call.

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?

An output schema exists, so return values need not be re-explained, and the description still flags what the response contains plus the 404 edge case and a docs link. For a one-parameter read tool with annotations, an agent has everything needed to call it correctly.

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

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

With a single parameter at 100% schema description coverage, the schema already documents 'url' fully including the path requirement. The description implies the URL is an x402 endpoint but adds no format or validation detail beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Get instructions for buying the detailed paid report on one x402 endpoint') and names the exact contents returned (score breakdown, price quote, wallet and price history). It explicitly distinguishes its scope from the free check_endpoint result, so an agent can separate it from its siblings without opening a schema.

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?

Gives an explicit trigger ('Use it only when the free check_endpoint result isn't enough and the user wants the full history'), names the alternative by name, and clarifies the downstream action ('doesn't buy the report itself'). Nothing about when or when-not to call it is left to inference.

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 cover mutation/idempotency safety, and the description adds substantial context beyond them: reports never change a grade alone, independent confirmations move the endpoint up the paid-test queue, serious problems trigger a re-test, on-chain verification happens within 24 hours on Base or Solana, and the self-reporting ban. This is exactly the kind of behavioral disclosure annotations do not carry.

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 the core action and submission options, and every sentence conveys information about eligibility, inputs, or effects. It is dense and the long parenthetical clauses make it slightly heavy, but there is little true filler.

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 7-parameter, nested-object tool with an output schema (so return values need not be described), the description covers submission routes, verification mechanics, eligibility limits, and downstream consequences of reporting. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is already 86%, so the schema carries most parameter meaning. The description still adds value by explaining the receipt-vs-url+tx choice, enumerating the answer fields, and clarifying 'outcome' as a shortcut for answers, going beyond the raw schema text.

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?

States a specific verb and object ('report whether you got what you paid for' after paying an x402 endpoint) and clearly frames it as feedback on a paid call, which separates it from siblings like check_endpoint, check_payment, and get_full_report. An agent can identify the task without opening the schema.

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 it (after paying an x402 endpoint), eligibility ('free, optional, and open to every agent'), the two submission paths (receipt from an allow decision vs url + tx), and constraints ('one report per payment; the seller's own wallet can't report on itself'). Alternatives and exclusions are named, not implied.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds non-annotation context: it is free and rankings refresh as monitoring runs every 30 minutes. That freshness cadence is genuinely useful for an agent deciding whether to re-query, though nothing is said about pagination or result-size behavior.

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

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

Three sentences, front-loaded with the core purpose before the sibling routing, and every clause carries information. Slightly dense when enumerating returned fields, but no filler.

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?

An output schema exists, so return values need not be enumerated in prose, and the description still names the key fields and the ranking rule. Combined with annotations and a fully documented parameter, an agent has what it needs to call this correctly; only pagination/truncation behavior is left unstated.

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

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

Schema coverage is 100% and the single limit parameter is fully documented with range and default in the schema. The description adds no syntax or meaning beyond that, so the baseline of 3 applies.

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?

States a specific verb (List) and resource (x402 endpoints) with explicit inclusion criteria (verdict proceed or caution, no payout-wallet incidents), ordering (best first), and returned fields (score, grade, verdict, test-payment delivery). An agent can distinguish this from check_endpoint and get_full_report without opening a schema.

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?

Gives both the positive use case ('discover reliable endpoints or pick between providers') and explicit routing to alternatives ('To evaluate one specific endpoint use check_endpoint; to approve a payment use check_payment'). The when-to-use decision is fully specified.

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