See what actually settles on x402: wash-adjusted volume, payTo checks. Free, no key, no signup.
Scored across 4 tools
Each tool targets a distinct output—aggregate stats, mismatch feed, specific payout check, and trust score. The closest pair, payto_check and trust_score, could both be used before payment, but their descriptions clearly separate payout-address verification from wash-aware scoring.
All names are lowercase snake_case two-word compounds following a readable descriptor-plus-output pattern. The pattern is consistent enough, though 'payto_check' is slightly awkward and none use a strict verb-first convention.
Four tools is well-scoped for a niche x402 settlement-index service. Each tool covers a distinct need without redundancy or padding.
The set covers the core domain well: aggregate wash-adjusted stats, mismatch discovery and verification, and seller trust scoring. Minor gaps such as browsing all endpoints or accessing raw unadjusted totals exist but are outside the server's stated purpose.
Get wash-adjusted x402 settlement volume per chain — spend that survives removal of funded loops and self-dealing cycles, which can differ from raw transfer totals by orders of magnitude. Returns clean settlement count, clean volume in USD and an as-of date per chain. Takes no arguments. Free, no key. These are the figures published on merona.io.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | Scope and method pointer. |
| clean | No | One entry per chain. |
| error | No | Present only on backend failure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the calculation logic (wash-adjusted, removing funded loops and self-dealing cycles), the potential orders-of-magnitude difference from raw totals, and the return contents (clean settlement count, volume in USD, as-of date). It also emphasizes no cost and no API key, which are behavioral facts not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long: first sentence states the purpose and key caveat, second sentence enumerates the return fields, and third sentence covers access requirements. Every sentence adds value; no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is comprehensive. It explains what is returned, the statistical significance of the numbers, and the access requirements. It also addresses potential confusion about why these figures differ from raw transfer totals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered. The description explicitly states 'Takes no arguments', reinforcing the schema. Since there are no parameters to explain, this is a solid baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Get wash-adjusted x402 settlement volume per chain' and clarifies the core value proposition (spend that survives removal of funded loops and self-dealing cycles). This clearly states what the tool does and differentiates it from siblings, which are unrelated 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?
It provides implicit usage guidance by explaining the difference from raw transfer totals and indicating that these are the figures published on merona.io. It also states 'Takes no arguments. Free, no key' which sets expectations for usage. There is no explicit alternative exclusion, but the unique purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List x402 endpoints currently advertising one payout address while asking payers for another, from merona's nightly probe of the public catalog — the top 10 entries with advertised vs live addresses, full counts and as-of dates (complete feed, uncapped: merona.io/mismatches.json). Takes no arguments. Free, no key. Use payto_check instead when you already have a specific address or endpoint to check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| meta | No | Feed provenance: generated-at, counts, method pointer. |
| error | No | Present only on backend failure. |
| catalog_vs_live | No | Endpoints advertising one payout address while asking payers for another (top 10). |
| payto_rotation_count | No | Endpoints with dated payout-address rotation history. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: data source ('merona's nightly probe'), scope ('public catalog'), output contents ('advertised vs live addresses, full counts and as-of dates'), and the complete feed URL. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and subject, then adds necessary context in short, clear sentences. Every clause earns its place: source, output details, complete feed link, no-args, no-key, and alternative tool.
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-argument, read-only feed with an output schema and annotations, the description fully covers purpose, source, limitations (top 10 vs. complete feed), the alternative tool, and access requirements. Nothing critical 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?
The tool has zero parameters, and the input schema is empty. The description explicitly confirms 'Takes no arguments,' which is consistent with the schema. With no parameters to elaborate on, baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('List') and a precise resource ('x402 endpoints currently advertising one payout address while asking payers for another'), making the tool's purpose unmistakable. It also distinguishes itself from the sibling tool payto_check by explicitly directing targeted lookups there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use payto_check instead when you already have a specific address or endpoint to check.' It also clarifies that the tool takes no arguments, is free, and requires no key, giving clear conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an x402 endpoint or wallet pays out where it claims to, before your agent sends funds. Takes one wallet address or endpoint URL. Returns any catalog-vs-live payout mismatch, dated payout-rotation history, and whether the address has settled on chain. Free, no key. Use mismatch_feed instead to list every known mismatch. Records are dated facts, not accusations, and no record found is not a clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Wallet address (0x… or base58) or endpoint URL/hostname to look up. |
| Name | Required | Description |
|---|---|---|
| note | No | Interpretation guidance — dated facts, not accusations. |
| error | No | Present only on backend failure. |
| query | No | The query as interpreted. |
| matches | No | Mismatch/rotation records touching the query; empty when none known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context about how to interpret results: 'Records are dated facts, not accusations' and 'no record found is not a clearance'. It also discloses access requirements ('Free, no key') and clarifies the tool's scope by distinguishing it from the broader mismatch_feed.
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 deliver purpose, usage timing, return values, alternative tool, and interpretation caveats without redundancy. The first sentence immediately states the core function, and every subsequent sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the description covers when to use, what it returns (mismatch, rotation history, on-chain settlement), how to interpret results, and points to the alternative tool. With a robust output schema and annotations, this is fully complete for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for query already covers the full input semantics ('Wallet address (0x… or base58) or endpoint URL/hostname'), so the description's mention of 'wallet address or endpoint URL' adds no new meaning. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether an x402 endpoint or wallet pays out where it claims to', making the tool's function unmistakable. It further differentiates from siblings by explicitly directing users to mismatch_feed for listing every known mismatch.
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?
It explicitly states when to use the tool ('before your agent sends funds') and identifies the alternative for a different need (mismatch_feed). The warning 'no record found is not a clearance' provides critical usage guidance and prevents misinterpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a specific seller wallet before paying it: wash-aware m.Score with an A–F grade, component breakdown, wash flags including multi-hop cycle detection, and the snapshot SHA so the result can be re-derived independently. Requires chain and address. Free — no key or payment needed. Optional: pass payment= to pay $0.001 via x402 and receive a settlement-receipted response.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain the seller settles on, e.g. base, polygon, solana. | |
| address | Yes | Seller wallet address to score. | |
| api_key | No | merona API key. Alternative to per-call x402 payment. | |
| payment | No | Base64 X-PAYMENT payload for a single x402 payment. |
| Name | Required | Description |
|---|---|---|
| tier | No | unrated | provisional | verified. |
| error | No | Present only on failure. |
| grade | No | A–F letter; null means unrated (evidence gate, not an adverse signal). |
| score | No | Numeric m.Score behind the letter. |
| delivery | No | Paid-probe delivery evidence, when merona has bought from this seller: status delivery_verified (dated) or charged_unserved (payment settled, request refused; settlement tx included). This score covers base/polygon/solana, but delivery evidence is base-only today (see PROBE_COVERAGE_CHAINS) — null here on polygon/solana means no probe was possible, not a clean record. |
| components | No | Score component breakdown. |
| snapshot_sha256 | No | Snapshot hash for independent re-derivation. |
| payment_required | No | x402 payment instructions; present only when the call is unpaid. |
| suggested_action | No | Deterministic action hint (PROCEED/CAUTION/INVESTIGATE/DECLINE/INSUFFICIENT_EVIDENCE) with reasons and rule version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral details: the score is wash-aware, includes multi-hop cycle detection, provides a snapshot SHA for independent re-derivation, and explains the free vs. paid settlement-receipted response path. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose. Every clause adds useful information—the output features, the free nature, and the optional payment—with no redundancy or 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?
Given the tool's moderate complexity, the description covers the core use case, free vs. optional payment behavior, and key output characteristics. An explicit alternative to sibling tools and potential edge cases would improve completeness, but the presence of rich annotations and an output schema means the description doesn't need to over-explain.
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 the baseline is 3. The description goes beyond the schema by explicitly stating that chain and address are required, and by giving a concrete usage example for the optional payment parameter ('pass payment=<base64 X-PAYMENT payload>'). This adds value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Score a specific seller wallet before paying it'. It details the output (wash-aware m.Score, A–F grade, component breakdown, wash flags, snapshot SHA), distinguishing it from sibling tools that handle stats, mismatch feeds, or payment checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: score before paying a seller, and it's free with no key or payment needed. It also explains the optional x402 payment path. However, it does not explicitly contrast with sibling tools or give when-not-to-use scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
trust_score1 field changedOutput schema / properties / delivery / descriptionPrevious value: -"Paid-probe delivery evidence, when merona has bought from this seller: status delivery_verified (dated) or charged_unserved (payment settled, request refused; settlement tx included)."New value: +"Paid-probe delivery evidence, when merona has bought from this seller: status delivery_verified (dated) or charged_unserved (payment settled, request refused; settlement tx included). This score covers base/polygon/solana, but delivery evidence is base-only today (see PROBE_COVERAGE_CHAINS) — null here on polygon/solana means no probe was possible, not a clean record."clean_stats3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / descriptionAdded value: +"This tool takes no arguments."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Wash-adjusted settlement figures per chain.",
+ "properties": {
+ "clean": {
+ "description": "One entry per chain.",
+ "items": {
+ "properties": {
+ "as_of": {
+ "description": "Measurement date (UTC).",
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "clean_settlements": {
+ "type": "integer"
+ },
+ "clean_volume_usd": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "description": "Present only on backend failure.",
+ "type": "string"
+ },
+ "note": {
+ "description": "Scope and method pointer.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}mismatch_feed3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / descriptionAdded value: +"This tool takes no arguments."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "The current public mismatch feed.",
+ "properties": {
+ "catalog_vs_live": {
+ "description": "Endpoints advertising one payout address while asking payers for another (top 10).",
+ "type": "array"
+ },
+ "error": {
+ "description": "Present only on backend failure.",
+ "type": "string"
+ },
+ "meta": {
+ "description": "Feed provenance: generated-at, counts, method pointer.",
+ "type": "object"
+ },
+ "payto_rotation_count": {
+ "description": "Endpoints with dated payout-address rotation history.",
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}payto_check1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Match results for the queried wallet/endpoint.",
+ "properties": {
+ "error": {
+ "description": "Present only on backend failure.",
+ "type": "string"
+ },
+ "matches": {
+ "description": "Mismatch/rotation records touching the query; empty when none known.",
+ "type": "array"
+ },
+ "note": {
+ "description": "Interpretation guidance — dated facts, not accusations.",
+ "type": "string"
+ },
+ "query": {
+ "description": "The query as interpreted.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}trust_score1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "The seller's score, or x402 payment instructions when called without api_key/payment.",
+ "properties": {
+ "components": {
+ "description": "Score component breakdown.",
+ "type": "object"
+ },
+ "delivery": {
+ "description": "Paid-probe delivery evidence, when merona has bought from this seller: status delivery_verified (dated) or charged_unserved (payment settled, request refused; settlement tx included).",
+ "type": "object"
+ },
+ "error": {
+ "description": "Present only on failure.",
+ "type": "string"
+ },
+ "grade": {
+ "description": "A–F letter; null means unrated (evidence gate, not an adverse signal).",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "payment_required": {
+ "description": "x402 payment instructions; present only when the call is unpaid.",
+ "type": "object"
+ },
+ "score": {
+ "description": "Numeric m.Score behind the letter.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "snapshot_sha256": {
+ "description": "Snapshot hash for independent re-derivation.",
+ "type": "string"
+ },
+ "suggested_action": {
+ "description": "Deterministic action hint (PROCEED/CAUTION/INVESTIGATE/DECLINE/INSUFFICIENT_EVIDENCE) with reasons and rule version.",
+ "type": "object"
+ },
+ "tier": {
+ "description": "unrated | provisional | verified.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}payto_check1 field changedInput schema / properties / query / descriptionAdded value: +"Wallet address (0x… or base58) or endpoint URL/hostname to look up."trust_score4 fields changedInput schema / properties / address / descriptionAdded value: +"Seller wallet address to score."Input schema / properties / api_key / descriptionAdded value: +"merona API key. Alternative to per-call x402 payment."Input schema / properties / chain / descriptionAdded value: +"Chain the seller settles on, e.g. base, polygon, solana."Input schema / properties / payment / descriptionAdded value: +"Base64 X-PAYMENT payload for a single x402 payment."clean_statsmismatch_feedpayto_checktrust_scoreLive x402 endpoint trust/diligence check before you pay it. $0.02/call via x402.
We buy from x402 endpoints with real USDC and publish delivery outcomes. Check before you spend.
Which x402 service actually works: uptime, valid 402, and settlements proven on-chain.
Check an x402 endpoint before your agent pays it: avoid / caution / ok, proven on-chain.
Add one secure layer between your agents and this server.
