Skip to main content
Glama

mcp-gauge

by io.github.CHANGCHINFU

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
NameRequiredDescriptionDefault
dimNowhich product: full read (gauge) or a single add-on; the price of each is in the 402 challenge this tool returns, never here
pathNoAlternative 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.
entityNowhich object within that line, e.g. the USGS site id 07010000
signal_idNowhich signal line, e.g. hydrology.river-level - use find_signal to list them

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
gotNoPresent on failure: the HTTP status actually returned.
hintNoPresent on failure: the next thing to try, e.g. find_signal.
noteNoStanding statement that this server never takes payment.
errorNoPresent only when the call failed; human-readable reason.
detailNoPresent on some failures: the upstream endpoint's own error text.
methodNoHTTP method to use at pay_at (always GET).
pay_atNoURL to send the paid GET to.
expectedNoPresent on failure: what was expected (an HTTP 402 challenge).
how_to_payNoHow to sign and send the X-PAYMENT header; pay from a plain EOA.
after_paymentNoWhat the paid response carries and how to verify it offline.
x402_challengeNoThe upstream 402 body verbatim: x402Version + accepts[] (scheme / network / asset / payTo / amount).

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: finding coverage/freshness, fetching payment challenges, exploring payment options, and verifying citations. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscore separation (find_signal, get_official_record, purchase_options, verify_citation), making the set predictable and easy to navigate.

Tool Count5/5

With only 4 tools, the server is tightly scoped for its purpose—providing discovery, challenge retrieval, payment guidance, and verification. Each tool is essential and earns its place.

Completeness5/5

The tool set covers the entire user workflow: check coverage/freshness, obtain a payment challenge, understand payment channels, and verify records. There are no obvious gaps given that paid data is delivered outside the MCP.

Resources