A
licenseNot graded
qualityF
maintenanceBitcoin data for AI agents. Pay-per-query via x402 micropayments. No API keys. No subscriptions. No tokens.
MIT
mcp-gauge
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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- CHANGCHINFU/mcp-gauge
- GitHub Stars
- 0
- Server Listing
- mcp-gauge
TDQS
A4.5/5.0
Scored across 4 tools
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.
Available Tools
5 toolsfind_signalFind which signals/entities are covered (free)ARead-onlyIdempotentInspect
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 | Default |
|---|---|---|---|
| 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 recordARead-onlyIdempotentInspect
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 | Default |
|---|---|---|---|
| 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)ARead-onlyIdempotentInspect
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)ARead-onlyIdempotentInspect
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)ARead-onlyIdempotentInspect
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. Dates show when Glama detected each change.
1 tool update
- Added
verify_triangular
1 tool update
- Added
purchase_options
1 tool update
- Changed
verify_citation1 field changed- changed
Output schema / properties / ots_status / descriptionPrevious 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 update
- Changed
get_official_record3 fields changed- added
Input schema / anyOfAdded value: +[ + { + "required": [ + "path" + ] + }, + { + "required": [ + "signal_id", + "entity" + ] + } +] - added
Input schema / properties / pathAdded 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" +} - removed
Input schema / requiredRemoved value: -[ - "signal_id", - "entity" -]
1 tool update
- Changed
verify_citation1 field changed- added
Output schema / properties / record_statusAdded 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 update
- Changed
get_official_record1 field changed- changed
Input schema / properties / dim / descriptionPrevious 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 update
- Changed
find_signal7 fields changed- added
Output schema / properties / signals / items / properties / entities / items / properties / overdue_daysAdded value: +{ + "description": "How many days past the declared cycle this object is.", + "type": "number" +} - added
Output schema / properties / signals / items / properties / entities / items / properties / update_statusAdded value: +{ + "description": "on_schedule | overdue | not_published | unknown, for this object.", + "type": "string" +} - changed
Output schema / properties / signals / items / properties / industry / descriptionPrevious value: -"Domain the line belongs to."New value: +"Domain the line belongs to; null when the line is not classified." - changed
Output schema / properties / signals / items / properties / industry / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Output schema / properties / signals / items / properties / latest_observed_at / descriptionPrevious 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." - changed
Output schema / properties / signals / items / properties / latest_observed_at / typePrevious value: -"string"New value: +[ + "string", + "null" +] - changed
Output schema / properties / signals / items / properties / max_overdue_days / typePrevious value: -"integer"New value: +"number"
3 tool updates
- Changed
find_signal2 fields changed- added
Input schema / properties / industry / descriptionAdded value: +"restrict to one domain, e.g. hydrology, agriculture, energy" - changed
Output 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" +}
- Changed
get_official_record3 fields changed- added
Input schema / properties / entity / descriptionAdded value: +"which object within that line, e.g. the USGS site id 07010000" - added
Input schema / properties / signal_id / descriptionAdded value: +"which signal line, e.g. hydrology.river-level - use find_signal to list them" - changed
Output 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" +}
- Changed
verify_citation1 field changed- changed
Output 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 updates
- First observed
find_signal - First observed
get_official_record - First observed
verify_citation
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Pay-per-call government data over x402: provenance chains, Ed25519 attestations, no API keys.
Pay-per-call crypto intelligence: 19 tools over 10+ live sources, USDC via x402.
Three independent sensors read pre-price Bitcoin flows every 30s and reject almost everything. When they converge, a call is emitted with evidence — and the public rejection funnel proves how often it stays silent. Auditable in one call. Free tier; Pro 50 USD/month or 0.01 USD/query via x402.
Crypto price-event settlement verdicts and US building-permit data, paid per call in USDC.
Related MCP Servers
- AlicenseAqualityDmaintenancePay-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.798MIT
- AlicenseAqualityAmaintenancePay-per-call ($0.005-$0.03 USDC) market and on-chain data API for AI agents and trading bots via the x402 protocol — no signup, no API key. Exposed as a remote MCP server with 12 tools — one free onboarding tool (dump-risk), the rest pay-per-call (kimchi premium, funding rate APR, DEX slippage, token security, arbitrage spread, and more).414MIT
- FlicenseAqualityCmaintenancePay-per-call tools for AI agents including trust checks, due diligence, market data, and human-verified approvals, settled in USDC on Base via the x402 protocol.16-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.