mcp-gauge

Get the x402 payment challenge for a paid record

get_official_record

Read-onlyIdempotent

Returns the REAL x402 payment challenge (accepts[]: network / asset / payTo / amount) for the paid endpoint that serves a given signal_id+entity, or any listed endpoint addressed directly by path. This tool does NOT deliver paid data and does NOT take payment - MCP has no payment layer. Pay at the returned url with your own x402 client (USDC on Base or Solana, gasless EIP-3009; pay from a plain EOA) and you receive the record directly, with record_hash you can verify offline. This tool only fetches the 402 challenge; it delivers no paid data and collects no payment.

Input Schema

TableJSON Schema

Name	Required	Description
`dim`	No	which product: full read (gauge) or a single add-on; the price of each is in the 402 challenge this tool returns, never here
`path`	No	Alternative addressing: any listed endpoint path, optionally with its query string (e.g. "/gauge/chokepoint-region?loc=hormuz"). The full list of legal paths is the free /manifest?all=1. Use this for the bundles and census lines that are not addressed by signal_id+entity.
`entity`	No	which object within that line, e.g. the USGS site id 07010000
`signal_id`	No	which signal line, e.g. hydrology.river-level - use find_signal to list them

Output Schema

TableJSON Schema

Name	Required	Description
`got`	No	Present on failure: the HTTP status actually returned.
`hint`	No	Present on failure: the next thing to try, e.g. find_signal.
`note`	No	Standing statement that this server never takes payment.
`error`	No	Present only when the call failed; human-readable reason.
`detail`	No	Present on some failures: the upstream endpoint's own error text.
`method`	No	HTTP method to use at pay_at (always GET).
`pay_at`	No	URL to send the paid GET to.
`expected`	No	Present on failure: what was expected (an HTTP 402 challenge).
`how_to_pay`	No	How to sign and send the X-PAYMENT header; pay from a plain EOA.
`after_payment`	No	What the paid response carries and how to verify it offline.
`x402_challenge`	No	The upstream 402 body verbatim: x402Version + accepts[] (scheme / network / asset / payTo / amount).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedAug 23, 2026

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "path"
+    ]
+  },
+  {
+    "required": [
+      "signal_id",
+      "entity"
+    ]
+  }
+]

addedInput schema / properties / path

Added value: +{
+  "description": "Alternative addressing: any listed endpoint path, optionally with its query string (e.g. \"/gauge/chokepoint-region?loc=hormuz\"). The full list of legal paths is the free /manifest?all=1. Use this for the bundles and census lines that are not addressed by signal_id+entity.",
+  "type": "string"
+}

removedInput schema / required

Removed value: -[
-  "signal_id",
-  "entity"
-]

Changed1 schema field changedAug 20, 2026

changedInput schema / properties / dim / description

Previous value: -"which product: full read (gauge, $0.05) or a single add-on"New value: +"which product: full read (gauge) or a single add-on; the price of each is in the 402 challenge this tool returns, never here"

Changed3 schema fields changedJul 31, 2026

addedInput schema / properties / entity / description

Added value: +"which object within that line, e.g. the USGS site id 07010000"

addedInput schema / properties / signal_id / description

Added value: +"which signal line, e.g. hydrology.river-level - use find_signal to list them"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "description": "The real x402 payment challenge and how to pay it. No paid data is ever returned here. On failure this object is an error report instead.",
+  "properties": {
+    "after_payment": {
+      "description": "What the paid response carries and how to verify it offline.",
+      "type": "string"
+    },
+    "detail": {
+      "description": "Present on some failures: the upstream endpoint's own error text.",
+      "type": "string"
+    },
+    "error": {
+      "description": "Present only when the call failed; human-readable reason.",
+      "type": "string"
+    },
+    "expected": {
+      "description": "Present on failure: what was expected (an HTTP 402 challenge).",
+      "type": "string"
+    },
+    "got": {
+      "description": "Present on failure: the HTTP status actually returned.",
+      "type": "integer"
+    },
+    "hint": {
+      "description": "Present on failure: the next thing to try, e.g. find_signal.",
+      "type": "string"
+    },
+    "how_to_pay": {
+      "description": "How to sign and send the X-PAYMENT header; pay from a plain EOA.",
+      "type": "string"
+    },
+    "method": {
+      "description": "HTTP method to use at pay_at (always GET).",
+      "type": "string"
+    },
+    "note": {
+      "description": "Standing statement that this server never takes payment.",
+      "type": "string"
+    },
+    "pay_at": {
+      "description": "URL to send the paid GET to.",
+      "type": "string"
+    },
+    "x402_challenge": {
+      "description": "The upstream 402 body verbatim: x402Version + accepts[] (scheme / network / asset / payTo / amount).",
+      "type": "object"
+    }
+  },
+  "required": [],
+  "type": "object"
+}

First observedJul 30, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With annotations already covering readOnlyHint=true and idempotentHint=true, the description's safety profile is reinforced and adds key behavioral detail: no payment collection, no data delivery, external payment flow on USDC/Base/Solana, gasless EIP-3009, and EOA payments. The only minor gap is a lack of explicit error/edge-case behavior.

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

Conciseness4/5

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

The description is dense but every sentence carries behavioral or usage weight. It front-loads the core return value and ends with a concise negation. The length earned by adding payment context and alternatives; it is not padded with fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The combination of strong schema coverage, clear annotations, and an output schema cover the safety profile and parameters. The description fills the remaining gap by explaining the external payment flow, record_hash verification, and the distinction from paid data delivery. Minor missing details like explicit status or error outputs are negligible given the output schema.

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?

Schema coverage is 100% and the description adds meaning beyond it: it explains the challenge's price-in-challenge semantics, gives a concrete path example, and clarifies when to use path versus signal_id+entity (e.g., for bundles and census lines). The dim enum description is partially self-referential but still informs that pricing is in the 402.

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 clearly states the specific verb 'Returns' the x402 payment challenge for a paid record, and identifies the resource via signal_id+entity or path. It explicitly distinguishes itself from delivering paid data or taking payment, and its 'this tool does NOT deliver paid data' framing differentiates it from sibling tools like find_signal.

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 clear usage context: use this tool only to fetch the 402 challenge; pay externally with an x402 client; do not expect paid data delivery. It also explains when to use path addressing (/manifest?all=1) versus signal_id+entity, and implicitly excludes the tool from payment or data retrieval use cases.

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

All mcp-gauge 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.