merona — x402 settlement index

mismatch_feed

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedAug 7, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / description

Added value: +"This tool takes no arguments."

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

First observedAug 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

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

Usage Guidelines5/5

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.

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?