US government data (USGS/NOAA/SEC/FDA) with cryptographic proof; x402 pay-per-call, no API key
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: find_signal covers discovery/coverage, get_official_record fetches a payment challenge, and verify_citation validates a record hash. There is no overlap in functionality.
All tool names follow a consistent lowercase snake_case verb_noun pattern: find, get, verify. The naming is predictable and uniform.
Three tools is well-scoped for the server's narrow domain of Truth Bear record access and verification. Each tool earns its place, and the count falls within the typical 3-15 range.
The tool surface covers the full intended workflow: discover coverage and freshness, obtain a payment challenge for a paid record, and verify any record hash. The lack of a tool for actual paid data delivery is by design since MCP has no payment layer.
find_signalFind which signals/entities are covered (free)AFREE 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.
| 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 |
| 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. |
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.
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.
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.
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.
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.
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 recordAReturns the REAL x402 payment challenge (accepts[]: network / asset / payTo / amount) for the paid endpoint that serves a given signal_id+entity. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| dim | No | which product: full read (gauge, $0.05) or a single add-on | |
| entity | Yes | which object within that line, e.g. the USGS site id 07010000 | |
| signal_id | Yes | which signal line, e.g. hydrology.river-level - use find_signal to list them |
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint and idempotentHint, the description adds valuable context beyond those: it clarifies the tool does not take payment, does not deliver paid data, and that MCP has no payment layer. It also details the payment flow (USDC on Base/Solana, EIP-3009, plain EOA) and mentions record_hash verification, giving the agent a comprehensive understanding of behavioral boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then clarifies limitations and provides actionable payment details. Every sentence earns its place with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (x402 protocol, payment integration), the description fully covers its role: fetching a challenge, not collecting payment, and guiding the agent through the external payment flow. With an output schema present and rich annotations, the description is sufficient for an agent to understand what the tool does and how to integrate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100% with detailed descriptions including the dim enum and examples for entity. The description's mention of signal_id+entity adds a slight relational context but mostly confirms what the schema already states. Per calibration, baseline 3 is appropriate since the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Returns the REAL x402 payment challenge') and clearly identifies the resource (the paid endpoint for a signal_id+entity). It also explicitly distinguishes itself from sibling tools by stating it does NOT deliver paid data and does NOT take payment, which differentiates it from find_signal and verify_citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: when you need the x402 payment challenge for a paid record. It explains the follow-up steps (pay at the returned url with your own x402 client) and implies this is the only payment-related step, though it does not explicitly name alternatives or exclusions. The schema description for signal_id also points to find_signal, adding helpful context.
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)AFREE. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| record_hash | Yes | sha256:<64 hex>, or a >=8-hex prefix as posted publicly |
| 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 | Legacy compatibility field; external timestamp anchoring was ruled out of implementation on 2026-07-23, so this stays "pending" forever. |
| 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". |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, reducing the burden. The description adds meaningful context: server-side hash recomputation, the nature of the output (genuineness + reverse lookup), and that it is free with no API key. This goes beyond the structured metadata without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with redundancy ('FREE' and 'No payment, no API key' both convey the same point), but it is well-structured and front-loaded with the core function. Overall, each sentence contributes to understanding, though minor trimming would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description fully covers what the tool does, when to use it, and what it returns. It includes operational context (free, no API key) and guides the agent's decision-making without needing to restate output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (record_hash) with a full description, including the allowed SHA-256 format or prefix. The description does not add additional parameter-level detail beyond what is in the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool's function: taking a record_hash, recomputing the canonical hash server-side, and returning both an authenticity verdict and a plain-language reverse lookup. It clearly distinguishes from siblings by focusing on verification rather than finding or retrieving records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check a citation you were handed by another agent or document BEFORE relying on it,' giving clear when-to-use guidance. It does not name alternative tools or exclusions, but the context is sufficient for an agent to differentiate from find_signal or get_official_record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.