mcp-gauge

Name: mcp-gauge
Author: CHANGCHINFU

Server Details

Verify official facts with Bitcoin-anchored proof. 180+ signals, x402 pay-per-call.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.6% over 44 days
Last Tested: 2026-09-30 18:36
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: CHANGCHINFU/mcp-gauge
GitHub Stars: 0
Server Listing: mcp-gauge

TDQS

A4.5/5.0

Scored 2026-09-09 18:42 across 5 tools

Disambiguation5/5

Each tool maps to a distinct workflow stage: coverage discovery, x402 challenge retrieval, payment-channel status, single-record verification, and triangular cross-verification. The two payment-adjacent tools are clearly separated by one returning the challenge URL and the other reporting available channels and statuses.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: find_signal, get_official_record, purchase_options, verify_citation, verify_triangular. The two verify_* tools are parallel, and the verb-first naming makes the overall set predictable and easy to scan.

Tool Count5/5

Five tools is a well-scoped size for a niche payment-discovery and verification server. Each tool covers a necessary non-payment step in the workflow, and none feels redundant or like filler.

Completeness5/5

The set covers the full intended lifecycle: find coverage, obtain the payment challenge, learn payment channels, verify a delivered record, and verify an interweave line. Since paid data delivery is deliberately external to MCP and records are immutable attestations, the lack of create/update/delete or direct data-fetch tools is not a gap.

Available Tools

5 tools

find_signalFind which signals/entities are covered (free)A

Read-onlyIdempotent

Inspect

FREE coverage + freshness manifest: which signal_id lines exist, how many entities each covers, and fresh/recent/stale counts - so you can check "is my entity covered and how fresh" BEFORE paying. Optional filters: industry, signal_id, entity.

ParametersJSON Schema

Name	Required	Description
`full`	No	true = per-entity detail (larger); default compact summary
`entity`	No	object id, e.g. a USGS site id
`industry`	No	restrict to one domain, e.g. hydrology, agriculture, energy
`signal_id`	No	e.g. hydrology.river-level

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Screening-level disclaimer.
`error`	No	Present only when the call failed; human-readable reason.
`detail`	No	Present on some failures: the upstream endpoint's own error text.
`nature`	No	What this manifest is.
`totals`	No	signal_ids / industries / distinct_entities / freshness counts across the whole catalogue.
`signals`	No	One entry per signal line. Compact by default; pass full=true for per-entity detail.
`cache_note`	No	What the cache does and does not affect.
`cache_ttl_s`	No	Cache lifetime of this manifest in seconds.
`cache_policy`	No	Cache policy in force.
`freshness_rule`	No	How fresh/recent/stale are decided.
`update_status_rule`	No	How on_schedule / overdue / not_published / unknown are decided.
`freshness_thresholds`	No	The numeric thresholds behind freshness_rule.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety and mutability. The description adds behavioral context by noting the tool is 'FREE' and functions as a manifest, which is useful operational information not present in annotations. No contradiction found.

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 a single sentence that front-loads the key point ('FREE coverage + freshness manifest') and immediately explains the deliverable and use case. No wasted words; every phrase adds value.

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?

With an output schema present and strong annotations, the description covers the essential context: purpose, use case, and optional filters. It could mention the 'full' parameter's effect, but that is documented in the schema. Overall, it's 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?

Schema description coverage is 100%, so the schema fully documents all four parameters. The description only mentions the optional filters (industry, signal_id, entity) without adding new semantic detail beyond what the schema already provides. Baseline 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 states a specific purpose: it's a 'coverage + freshness manifest' that tells you which signal_id lines exist, how many entities each covers, and fresh/recent/stale counts. This clearly distinguishes it from sibling tools like get_official_record or verify_citation, which serve different functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this to check 'is my entity covered and how fresh' BEFORE paying. This implies a pre-purchase use case. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full guidance.

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

get_official_recordGet the x402 payment challenge for a paid recordA

Read-onlyIdempotent

Inspect

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.

ParametersJSON 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

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

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.

purchase_optionsHow can I actually buy this? (free)A

Read-onlyIdempotent

Inspect

FREE. Ask how to pay for a listed endpoint and get every channel with its REAL status - including the ones that are wired but not open yet. Three channels exist: x402 micropayment (for an agent with a funded USDC wallet on Base), a stateless subscription Bearer token (for a person or team - no wallet, no private key, no account), and a card rail. This tool takes no payment and holds no key; it only tells you which doors exist and which are open today.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	A listed endpoint path (e.g. "/gauge/grid-reliability-region") to get its price alongside the channels. Omit it to get the channel list on its own. The full list of legal paths is the free /manifest?all=1.

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	present only when the buy endpoint could not be reached
`price`	No	the listed price, present only when asked_about matches a listed endpoint
`title`	No	the listing title of that endpoint, when it has one
`detail`	No	the upstream error text, when there is one
`endpoint`	No	always "/buy" - which endpoint answered
`free_first`	No	what stays free and how to avoid paying for a lookup with no data
`asked_about`	No	the path you asked about, or null if you asked for the channel list on its own
`ways_to_buy`	No	every payment channel with its REAL status - including channels that are wired but not open yet
`note_unknown_path`	No	present only when asked_about matched no listed endpoint

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: it states the tool takes no payment, holds no key, and only reports which doors exist and are open. It also clarifies that 'wired but not open' channels are included, which is a non-obvious trait. No contradictions 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 four sentences, each earning its place: opens with 'FREE' to set expectations, states the core function, enumerates the three channels with relevant audience details, and closes with a clarification that it's purely informational. No fluff, and the key purpose is front-loaded.

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?

Given that an output schema exists (so return values are covered), the description provides all necessary context: what the tool does, the three channels, the free nature, and the fact it only reports status. It also mentions the /manifest endpoint for legal paths. No critical information is missing for an agent to correctly call this 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?

Schema description coverage is 100%, so the parameter 'path' is fully documented in the schema. The tool description does not add additional meaning about the parameter; it focuses on the channels and tool behavior. Per the baseline rule, when the schema covers the parameter fully and the description adds no new value, a score 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 clearly states the tool's purpose: to retrieve payment channels and their status for a listed endpoint. It uses a specific verb ('get'), a specific resource ('listed endpoint'), and explicitly names the three channels. Sibling tools (find_signal, get_official_record, verify_citation) are unrelated, so there's no confusion about which tool to use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool ('Ask how to pay for a listed endpoint') and provides context about omitted path behavior via the schema. It doesn't explicitly name alternatives or exclusion criteria, but given the sibling tools serve completely different purposes (signals, records, citations), the usage context is clear enough. It also directs users to /manifest?all=1 for legal paths, which is helpful.

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

verify_citationVerify a Truth Bear record (free)A

Read-onlyIdempotent

Inspect

FREE. Given a record_hash from any Truth Bear record, look it up and recompute the canonical hash server-side, returning whether it is a genuine Truth Bear official record plus a plain-language reverse lookup of what exactly that hash attests. Use this to check a citation you were handed by another agent or document BEFORE relying on it. No payment, no API key.

ParametersJSON Schema

Name	Required	Description	Default
`record_hash`	Yes	sha256:<64 hex>, or a >=8-hex prefix as posted publicly

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Screening-level disclaimer.
`error`	No	Present only when the call failed; human-readable reason.
`found`	No	Whether a published Truth Bear reading matches this hash.
`scope`	No	What this hash does and does not attest.
`entity`	No	Object id the reading is about.
`endpoint`	No	Always "gauge/verify".
`verified`	No	Whether the canonical hash recomputed server-side matches the one supplied.
`signal_id`	No	e.g. hydrology.river-level
`ots_status`	No	Per-record field, unused: individual records are not stamped one by one. Anchoring happens per write-batch - see GET /gauge/anchor?hash= for the Merkle inclusion proof and, once the calendar confirms, the Bitcoin block number.
`source_ref`	No	URL of the official source record.
`undetermined`	No	true when the lookup itself failed (e.g. DB unavailable) - NOT a verdict of "fake".
`record_status`	No	Three-state disclosure. state="active" for a normal record; a non-active state (e.g. "quarantined") means the record is genuine and its hash still verifies, but we have since flagged it as not fit for delivery - do NOT rely on the reading itself. Carries since (UTC ISO) and reason when non-active.
`snapshot_date`	No	YYYY-MM-DD of the reading.
`reverse_lookup`	No	Plain-language statement of exactly what this hash attests.
`recomputed_hash`	No	sha256:<64 hex> recomputed from the stored record.
`hash_core_version`	No	Version of the canonical hash core used.
`is_truth_bear_record`	No	true / false, or null when the check could not be run (see undetermined).
`how_to_check_a_claimed_value`	No	Present when found: how to check a value someone claims.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context: the operation is free, requires no API key, recomputes the hash server-side, and returns both authenticity and a plain-language interpretation. 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?

Three sentences with no filler. The free/no-key detail, core operation, and usage guidance are front-loaded and each 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?

Given the single well-documented parameter, an output schema, and robust annotations, the description covers all necessary context for correct invocation: what it does, when to use it, cost/auth requirements, and what to expect.

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 already fully describes record_hash, including accepted formats (sha256 or hex prefix). The description restates that it is a record_hash but does not add meaningful semantic detail beyond the schema, so the baseline score of 3 applies.

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 states a specific verb ('look it up and recompute'), a clear resource (Truth Bear record via record_hash), and the exact outcome (whether it is genuine plus a plain-language attestation). This clearly distinguishes it from sibling tools by framing it as citation verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is explicit when-to-use guidance: 'Use this to check a citation you were handed by another agent or document BEFORE relying on it.' It does not explicitly name when not to use it or compare with find_signal/get_official_record, but the intended context is unambiguous.

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

verify_triangularCross-check a line of official series & recompute the verdict (free)A

Read-onlyIdempotent

Inspect

FREE. Cross-verify one GAUGE interweave line: it returns each official series ("leg") in the line with its own record_hash, current/previous values, expected direction and per-leg minMove deadband, plus a count-style state (directions_matched / direction_mismatch / inverse_consistent / not_comparable / insufficient) and N-of-M. Everything needed to recompute the verdict OFFLINE is in the response - verify each leg hash with verify_citation, then recompute dir=sign(current-previous) with the minMove deadband. Descriptive only: no forecast, no causation, no advice. No payment, no API key.

ParametersJSON Schema

Name	Required	Description	Default
`line`	Yes	which interweave line, e.g. "E" (state vs national unemployment) or "F" (drought vs crop). Public demo lines are E and F.
`entity`	Yes	the object within the line, as US-<ST>, e.g. "US-TX" (case-insensitive). Required.

Output Schema

ParametersJSON Schema

Name	Required	Description
`legs`	No	one entry per official series in the line.
`line`	No	the line code you asked for, e.g. E or F.
`note`	No	standing disclaimer: direction is observed, not a trend/forecast/causation claim.
`error`	No	Present only when the call failed; human-readable reason.
`state`	No	directions_matched \| direction_mismatch \| inverse_consistent \| not_comparable \| insufficient. A count/observation, NOT an adjudication.
`title`	No	letter-only title (e.g. "線E"); never a phenomenon name.
`detail`	No	Present on some failures: the upstream endpoint's own error text.
`entity`	No	the external contract code, e.g. US-TX.
`nature`	No	neutral English disclosure; may be null.
`reason`	No	stale \| missing_current_or_previous \| below_min_move \| period_misaligned \| no_active_drought \| parallel_display \| null.
`matched`	No	N: how many REQUIRED legs had measured dir === expect this window.
`required`	No	M: number of required legs. The public claim is exactly "N of M moved in the registered direction".
`statement`	No	the locked, neutral disclosure sentence with N/M substituted.
`pair_state`	No	inverse-pair lines (F/FW) only: holds_stress \| holds_relief \| broken \| insufficient \| not_comparable; absent/null on other lines.
`verify_hint`	No	exactly how to recompute the state offline from each leg (record_hash + dir=sign(Δ) with minMove deadband).
`snapshot_window`	No	the {from,to} window the legs were read over, or null.

TDQS

A4.5/5.0

Behavior5/5

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

Even with readOnlyHint/idempotentHint annotations, the description adds substantial behavior: the response contains everything needed for offline recomputation, the tool is descriptive-only ('no forecast, no causation, no advice'), and it requires no payment or API key. This gives the agent a clear expectation of side-effect-free, self-contained behavior beyond the 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 purpose ('FREE. Cross-verify one GAUGE interweave line...'), then packs the response contents, the offline recompute instruction, and the constraints into four tight sentences. Every clause earns its place; only minor redundancy exists between 'FREE' and 'No payment, no API key,' which is not enough to penalize.

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?

With an output schema present, the description still adds what the agent needs for correct invocation: the recompute workflow, the relationship to verify_citation, the descriptive-only scope, and the free access. Sibling differentiation (no forecast, no payment) is effectively conveyed even though not all siblings are named.

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?

Schema description coverage is 100%, with both `line` and `entity` already explained (including examples and case-insensitivity). The description does not add param-specific meaning beyond the schema, so the baseline of 3 applies; the tool description's detail is about the response, not the parameters.

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: 'Cross-verify one GAUGE interweave line,' then lists the exact response components (record_hash, current/previous values, expected direction, minMove deadband, state, N-of-M). This clearly differentiates it from siblings like verify_citation (a hash-checker) and find_signal (forecast-focused), especially with 'Descriptive only: no forecast, no causation, no advice.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use it to cross-verify a line and recompute the verdict offline, and explicitly routes hash verification to verify_citation ('verify each leg hash with verify_citation'). It also states exclusions ('no forecast, no causation, no advice') and that it is free ('No payment, no API key'), which implies when not to use paid or predictive siblings, though it does not name those siblings explicitly.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 6, 2026
- Addedverify_triangular
1 tool updateAug 27, 2026
- Addedpurchase_options

1 tool updateAug 27, 2026

Changedverify_citation1 field changed

changedOutput schema / properties / ots_status / description

Previous value: -"Legacy compatibility field; external timestamp anchoring was ruled out of implementation on 2026-07-23, so this stays \"pending\" forever."New value: +"Per-record field, unused: individual records are not stamped one by one. Anchoring happens per write-batch - see GET /gauge/anchor?hash= for the Merkle inclusion proof and, once the calendar confirms, the Bitcoin block number."

1 tool updateAug 23, 2026

Changedget_official_record3 fields changed

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"
-]

1 tool updateAug 21, 2026

Changedverify_citation1 field changed

addedOutput schema / properties / record_status

Added value: +{
+  "description": "Three-state disclosure. state=\"active\" for a normal record; a non-active state (e.g. \"quarantined\") means the record is genuine and its hash still verifies, but we have since flagged it as not fit for delivery - do NOT rely on the reading itself. Carries since (UTC ISO) and reason when non-active.",
+  "properties": {
+    "note": {
+      "description": "Why the record is kept queryable on purpose.",
+      "type": "string"
+    },
+    "reason": {
+      "description": "Short machine-readable reason code.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "since": {
+      "description": "UTC ISO second-precision timestamp of when we flagged it.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "state": {
+      "description": "\"active\" or a withdrawal state such as \"quarantined\".",
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

1 tool updateAug 20, 2026

Changedget_official_record1 field changed

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"

1 tool updateJul 31, 2026

Changedfind_signal7 fields changed

addedOutput schema / properties / signals / items / properties / entities / items / properties / overdue_days

Added value: +{
+  "description": "How many days past the declared cycle this object is.",
+  "type": "number"
+}

addedOutput schema / properties / signals / items / properties / entities / items / properties / update_status

Added value: +{
+  "description": "on_schedule | overdue | not_published | unknown, for this object.",
+  "type": "string"
+}

changedOutput schema / properties / signals / items / properties / industry / description

Previous value: -"Domain the line belongs to."New value: +"Domain the line belongs to; null when the line is not classified."

changedOutput schema / properties / signals / items / properties / industry / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```

changedOutput schema / properties / signals / items / properties / latest_observed_at / description

Previous value: -"ISO timestamp of the newest observation in the line."New value: +"ISO timestamp of the newest observation; null when the line has never published."

changedOutput schema / properties / signals / items / properties / latest_observed_at / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
changedOutput schema / properties / signals / items / properties / max_overdue_days / type
```
Previous value: -"integer"New value: +"number"
```

3 tool updatesJul 31, 2026

Changedfind_signal2 fields changed

addedInput schema / properties / industry / description

Added value: +"restrict to one domain, e.g. hydrology, agriculture, energy"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Coverage + freshness manifest. On failure this object is an error report instead (see error/detail).",
+  "properties": {
+    "cache_note": {
+      "description": "What the cache does and does not affect.",
+      "type": "string"
+    },
+    "cache_policy": {
+      "description": "Cache policy in force.",
+      "type": "string"
+    },
+    "cache_ttl_s": {
+      "description": "Cache lifetime of this manifest in seconds.",
+      "type": "number"
+    },
+    "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"
+    },
+    "freshness_rule": {
+      "description": "How fresh/recent/stale are decided.",
+      "type": "string"
+    },
+    "freshness_thresholds": {
+      "description": "The numeric thresholds behind freshness_rule.",
+      "type": "object"
+    },
+    "nature": {
+      "description": "What this manifest is.",
+      "type": "string"
+    },
+    "note": {
+      "description": "Screening-level disclaimer.",
+      "type": "string"
+    },
+    "signals": {
+      "description": "One entry per signal line. Compact by default; pass full=true for per-entity detail.",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "checkup": {
+            "description": "Latest patrol result for the line (full mode).",
+            "type": "object"
+          },
+          "description": {
+            "description": "What the line measures (full mode).",
+            "type": "string"
+          },
+          "entities": {
+            "description": "Per-entity detail; present only when full=true.",
+            "items": {
+              "additionalProperties": true,
+              "properties": {
+                "data_age_hours": {
+                  "description": "Age of the observation in hours.",
+                  "type": "number"
+                },
+                "entity": {
+                  "description": "Object id.",
+                  "type": "string"
+                },
+                "entity_name": {
+                  "description": "Human-readable object name.",
+                  "type": "string"
+                },
+                "freshness": {
+                  "description": "fresh | recent | stale.",
+                  "type": "string"
+                },
+                "observed_at": {
+                  "description": "ISO timestamp of the observation.",
+                  "type": "string"
+                },
+                "vintage_days": {
+                  "description": "Age of the underlying source vintage in days.",
+                  "type": "number"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "entities_count": {
+            "description": "How many objects the line covers.",
+            "type": "integer"
+          },
+          "factory": {
+            "description": "Internal collector name (full mode).",
+            "type": "string"
+          },
+          "freshness_counts": {
+            "description": "fresh / recent / stale counts for the line.",
+            "type": "object"
+          },
+          "industry": {
+            "description": "Domain the line belongs to.",
+            "type": "string"
+          },
+          "latest_observed_at": {
+            "description": "ISO timestamp of the newest observation in the line.",
+            "type": "string"
+          },
+          "max_overdue_days": {
+            "description": "Largest overdue gap in the line, in days.",
+            "type": "integer"
+          },
+          "record_type": {
+            "description": "Kind of record the line emits (full mode).",
+            "type": "string"
+          },
+          "signal_id": {
+            "description": "e.g. hydrology.river-level",
+            "type": "string"
+          },
+          "signal_id_label": {
+            "description": "Human-readable line name (full mode).",
+            "type": "string"
+          },
+          "temporal_cycle": {
+            "description": "Publication cycle declared by the upstream source (full mode).",
+            "type": "string"
+          },
+          "update_status": {
+            "description": "on_schedule | overdue | not_published | unknown.",
+            "type": "string"
+          },
+          "update_status_counts": {
+            "description": "Per-status entity counts.",
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "totals": {
+      "description": "signal_ids / industries / distinct_entities / freshness counts across the whole catalogue.",
+      "type": "object"
+    },
+    "update_status_rule": {
+      "description": "How on_schedule / overdue / not_published / unknown are decided.",
+      "type": "object"
+    }
+  },
+  "required": [],
+  "type": "object"
+}

Changedget_official_record3 fields changed

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

Changedverify_citation1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Verdict for one record_hash. On failure this object is an error report instead (see error/detail).",
+  "properties": {
+    "endpoint": {
+      "description": "Always \"gauge/verify\".",
+      "type": "string"
+    },
+    "entity": {
+      "description": "Object id the reading is about.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Present only when the call failed; human-readable reason.",
+      "type": "string"
+    },
+    "found": {
+      "description": "Whether a published Truth Bear reading matches this hash.",
+      "type": "boolean"
+    },
+    "hash_core_version": {
+      "description": "Version of the canonical hash core used.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "how_to_check_a_claimed_value": {
+      "description": "Present when found: how to check a value someone claims.",
+      "type": "string"
+    },
+    "is_truth_bear_record": {
+      "description": "true / false, or null when the check could not be run (see undetermined).",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "note": {
+      "description": "Screening-level disclaimer.",
+      "type": "string"
+    },
+    "ots_status": {
+      "description": "Legacy compatibility field; external timestamp anchoring was ruled out of implementation on 2026-07-23, so this stays \"pending\" forever.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "recomputed_hash": {
+      "description": "sha256:<64 hex> recomputed from the stored record.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reverse_lookup": {
+      "description": "Plain-language statement of exactly what this hash attests.",
+      "type": "string"
+    },
+    "scope": {
+      "description": "What this hash does and does not attest.",
+      "type": "string"
+    },
+    "signal_id": {
+      "description": "e.g. hydrology.river-level",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "snapshot_date": {
+      "description": "YYYY-MM-DD of the reading.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "source_ref": {
+      "description": "URL of the official source record.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "undetermined": {
+      "description": "true when the lookup itself failed (e.g. DB unavailable) - NOT a verdict of \"fake\".",
+      "type": "boolean"
+    },
+    "verified": {
+      "description": "Whether the canonical hash recomputed server-side matches the one supplied.",
+      "type": "boolean"
+    }
+  },
+  "required": [],
+  "type": "object"
+}

3 tool updatesJul 30, 2026
- First observedfind_signal
- First observedget_official_record
- First observedverify_citation

Related MCP Connectors

Clink Forge C
com.clinkforge
Pay-per-call government data over x402: provenance chains, Ed25519 attestations, no API keys.
Government Data Blockchain
1711
x402-alpha A
io.911fund.x402
Pay-per-call crypto intelligence: 19 tools over 10+ live sources, USDC via x402.
Cryptocurrency Blockchain
192
Genesis402 by UnyKorn (x402 pay-per-call)A
io.github.FTHTrading
360 pay-per-call APIs for AI agents over x402 and MPP, settled in USDC on Base ($0.001-$0.25 a call, no account or API key). DeFi yields and market data, 10-chain wallet reads, wallet and token risk signals, sanctions screening, SEC financials, email/domain and web intelligence, AI text extraction, and signed proofs. Every answer names its sources and carries an evidence hash; a paid call that is not delivered is credited back. Built and run by UnyKorn LLC.
AI & Machine Learning Blockchain Payments & Billing
211
Academic Evidence Pack A
io.github.jmxisnext
Signed citation-integrity reports + retraction-checked evidence packs, paid per call via x402/USDC.
Research & Data Payments & Billing
61

Related MCP Servers

btcfi-api
Blockchain Cryptocurrency Finance
aiindigo925
A
license
Not graded
quality
D
maintenance
Bitcoin data for AI agents. Pay-per-query via x402 micropayments. No API keys. No subscriptions. No tokens.
Updated 6 days ago (2026-09-25 04:40 UTC)
MIT
clearsigned-mcp
Search Agent Orchestration Research & Data
diawest82
A
license
A
quality
C
maintenance
Enables agents to verify claims against live web evidence with calibrated confidence, paying per call via x402 and receiving offline-verifiable signed receipts.
Updated 5 days ago (2026-09-26 04:12 UTC)
3
MIT
CorteX402
Blockchain Cryptocurrency Finance
Ooak21
A
license
A
quality
D
maintenance
Pay-per-call x402 data products on Base mainnet — sanctions screening, aviation weather, mortgage rates, US property dossier, title chain, wallet balance, and agent session auth. Every call settles in USDC with an on-chain receipt, no accounts or API keys.
Updated 4 months ago (2026-06-07 00:54 UTC)
7
27 npm
MIT
AlphaPipeline
Blockchain Cryptocurrency Finance
parkyucheol-del
A
license
A
quality
A
maintenance
Pay-per-call ($0.005–$0.03 USDC) market, on-chain, and prediction-market data API for AI agents and trading bots via the x402 protocol — no signup, no API key. Exposed as a remote MCP server with 15 tools: pre-trade token security (honeypot/liquidity checks), kimchi premium, funding rate APR, DEX slippage, Polymarket arbitrage & liquidity audits, and Hyperliquid HIP-4 prediction-market odds.
Updated 2 hours ago (2026-09-30 16:55 UTC)
4
15
MIT

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources