merona — x402 settlement index

payto_check

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	Wallet address (0x… or base58) or endpoint URL/hostname to look up.

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 7, 2026

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"
+}

Changed1 schema field changedAug 6, 2026
- addedInput schema / properties / query / description
```
Added value: +"Wallet address (0x… or base58) or endpoint URL/hostname to look up."
```
First observedAug 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

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 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.

Usage Guidelines5/5

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.

All merona — x402 settlement index tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?