x402 payment-request parser with a limited token list. Does not sign, approve or judge payments.
Scored across 4 tools
Each tool has a fairly distinct purpose: parsing requests, retrieving receipts, listing the server's own tool catalog, and looking up known assets. catalog and x402_known_assets are both reference-lookup tools, which creates mild overlap, but their descriptions distinguish them well.
Names mix conventions: a bare noun (catalog), a verb_noun (get_receipt), and two x402_-prefixed tools (x402_known_assets, x402_parse_payment_request). The x402_ prefix is a readable grouping cue, but the verb styles are inconsistent across the set.
Four tools is well-scoped for a focused, read-only payment-request parser. It is on the lean side, but each tool earns its place without redundancy.
The surface covers parsing requests, recovering lost results via receipts, and the reference data needed to interpret them, which matches the stated read-only parsing domain. Deliberate exclusions (verification, authorization) are documented rather than gaps, though no explicit discovery step for supported inputs exists.
List the tools of this server with prices, data sources, licensing, daily limits and data freshness.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| legal | Yes | |
| terms | Yes | URL of the terms of service. |
| tools | Yes | Every tool of this server with its price. |
| paused | Yes | Operator pause flags (true = paused). |
| server | Yes | |
| payment | Yes | |
| provenance | No | Freshness receipts for every upstream source used. |
| daily_limits | Yes | Daily limits of paid calls (calls, usd, timezone) or a misconfiguration notice. |
| fetch_status_values | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds the content categories returned (prices, licensing, limits, freshness), which is useful context, but an output schema exists and would surface the same structure, so the incremental disclosure is modest.
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?
A single front-loaded sentence with no filler; every clause enumerates distinct payload content, so nothing is wasted.
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 no parameters, a read-only annotation, and an output schema present, the description need not explain return values or safety. It is nearly complete for this simple tool; only a hint about when to reach for it is absent.
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, so there is nothing for the description to disambiguate. Baseline 4 applies under the '0 params' rule.
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?
Clear verb ("List") plus resource ("the tools of this server") and an enumeration of the payload contents (prices, data sources, licensing, daily limits, freshness). It is plainly distinguishable from siblings like get_receipt or drone_flight_check, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given; usage is only implied by the discovery framing ("the tools of this server"). An agent can infer this is the entry point for learning available tools and pricing, but nothing states that intent directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-fetch the stored result of a settled paid call by its receipt_id, for when the response was lost after payment. Free. Unknown or unsettled receipt ids return RECEIPT_NOT_FOUND. Results are kept for 90 days after settlement.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | The receipt_id returned with a paid result ("rcpt_" + 64 hex characters). |
| Name | Required | Description |
|---|---|---|
| tool | Yes | Name of the paid tool that produced the result. |
| terms | Yes | URL of the terms of service. |
| result | Yes | The stored result, exactly as returned by the paid call. |
| payment | Yes | |
| provenance | Yes | Freshness receipts for every upstream source used. |
| receipt_id | Yes | Receipt id of the settled paid call ("rcpt_" + 64 hex). Use with get_receipt. |
| settled_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past readOnlyHint=true by disclosing cost ('Free'), the failure mode and error code (RECEIPT_NOT_FOUND for unknown/unsettled ids), and the retention window (90 days after settlement). These are exactly the runtime traits an agent needs before calling.
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 short sentences, front-loaded with the action and the receipt_id, followed by behavioral facts. No filler, no restatement of the title.
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 no explanation, and the description still covers cost, error behavior, and retention limits. Nothing an agent needs to call this 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 description coverage is 100% and the schema already specifies the receipt_id format ('rcpt_' + 64 hex characters, maxLength 80). The description only names the identifier without adding format or constraint detail, so the schema does the real work.
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 ('re-fetch'), specific resource ('stored result of a settled paid call'), and the keying mechanism ('by its receipt_id'). The 're-fetch ... for when the response was lost' framing clearly separates it from the unrelated sibling tools.
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 triggering scenario: use it when a paid call's response was lost after payment. It also implies the boundary condition (unknown or unsettled ids are not valid targets), but does not name an alternative tool or state a when-not clause for other lookup paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. The limited reference list this server compares token addresses with: known assets (network, contract, symbol, decimals) with sources and check dates, known CAIP-2 networks, scheme names from the x402 specs, and payment flows. A table match is not proof that an asset or a merchant is genuine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| terms | Yes | URL of the terms of service. |
| assets | Yes | Known assets per CAIP-2 network. |
| schemes | Yes | |
| networks | Yes | |
| provenance | Yes | Version and sources of the bundled asset table. |
| payment_flows | Yes | |
| registry_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds value beyond them: it states the call is free, characterizes the list as 'limited', notes that entries carry sources and check dates (staleness context), and warns that a match is not proof of authenticity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the key qualifier ('Free.') front-loaded and the content enumeration following. The field list is somewhat dense but each item is informative rather than redundant; nothing reads as padding.
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 zero-parameter read-only reference lookup with an output schema, the description supplies the necessary scope (what tables exist) and the crucial limitation (a match is not proof of authenticity). An agent has enough to decide when the lookup is worthwhile and how much to trust it.
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; there is nothing for the description to disambiguate. The enumerated return fields (network, contract, symbol, decimals) are descriptive of output rather than input, so they add no parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and enumerates its contents: known assets (network, contract, symbol, decimals) with sources and check dates, CAIP-2 networks, x402 scheme names, and payment flows. It is clearly distinguishable from get_receipt or x402_parse_payment_request, though it never names those siblings to route the agent explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the 'Free.' prefix signals cost-free lookup and the closing caveat warns that a table match is not proof of genuineness. There is no explicit statement of when to call this versus the sibling tools, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Decode one x402 v2 payment request (base64 PAYMENT-REQUIRED header, PaymentRequired JSON or MCP tool result) and list every accepts option with exact atomic and decimal amounts. Token addresses are compared with a limited reference list. status: parsed, ambiguous (options differ in recipient, network or amount; none is chosen), malformed or unsupported. Does not verify the merchant, authorize a transfer, assess fraud risk, or guarantee any payment. URLs in the input are never fetched.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | Yes | The payment request. A string: the base64 PAYMENT-REQUIRED header value (a leading 'PAYMENT-REQUIRED:' is allowed) or JSON text. An object: the PaymentRequired JSON, or for transport mcp the tool result (structuredContent, _meta x402/error or content[0].text). | |
| transport | No | Where the request came from: http (402 response) or mcp (paid tool result). Default http. | http |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| note | Yes | |
| terms | Yes | URL of the terms of service. |
| errors | Yes | |
| parsed | Yes | The decoded request with every accepts option (null unless status is parsed or ambiguous). |
| status | Yes | parsed = the checked x402 v2 structure had no defects (not a statement about the merchant or whether to pay). ambiguous = options differ in recipient, network or amount; none was chosen. malformed / unsupported = could not be fully read. |
| evidence | Yes | |
| warnings | Yes | |
| mismatches | Yes | |
| provenance | Yes | Version and sources of the bundled asset table. |
| comparisons | Yes | |
| unsupported | Yes | |
| decoded_from | Yes | |
| checked_scope | Yes | |
| payment_required_location | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-openWorld, but the description adds substantive behavior: the four possible outcomes (parsed, ambiguous, malformed, unsupported), how ambiguity is resolved (options differ in recipient, network or amount and none is chosen), the limited token reference list, and the no-fetch guarantee. These prevent an agent from treating a parse as verification or expecting a network resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five dense sentences, front-loaded with the cost signal and the core action, then outputs, then limits. Every clause carries information (formats, statuses, guardrails) and nothing is padding.
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, the description need not enumerate return fields, and it still supplies the status vocabulary and the ambiguity rule. Combined with complete parameter coverage and full annotations, an agent has everything needed to call and interpret 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?
Schema description coverage is 100%, so both parameters already carry full definitions including the string/object union and the transport enum. The description largely restates those input forms and adds only the note about the limited token reference list, 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 (decode) and resource (one x402 v2 payment request), enumerates the accepted input encodings, and says exactly what the output is: every accepts option with atomic and decimal amounts. The scope line ('Does not verify the merchant, authorize a transfer...') draws the boundary against neighbors like get_receipt and x402_known_assets without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Free.' prefix and the explicit negative list (does not verify merchant, authorize transfer, assess fraud, guarantee payment; URLs never fetched) tell the agent when this tool is the wrong choice. However, it never names an alternative sibling or states a positive trigger condition (e.g. 'use before signing a 402 response'), so routing is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
catalogget_receiptx402_known_assetsx402_parse_payment_requestRead-only on-chain receipt check for x402 payments; confirm settlement before trusting a tx.
x402 v2 payment requests; relays compatible clients' signed payments to the existing product API.
Authorize and prove autonomous x402/AP2 agent payments with cryptographic receipts.
Pay-per-use web extract, token prices, and wallet balances via x402 USDC micropayments.
Add one secure layer between your agents and this server.