Skip to main content
Glama

Verify a Truth Bear record (free)

verify_citation
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
record_hashYessha256:<64 hex>, or a >=8-hex prefix as posted publicly

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoScreening-level disclaimer.
errorNoPresent only when the call failed; human-readable reason.
foundNoWhether a published Truth Bear reading matches this hash.
scopeNoWhat this hash does and does not attest.
entityNoObject id the reading is about.
endpointNoAlways "gauge/verify".
verifiedNoWhether the canonical hash recomputed server-side matches the one supplied.
signal_idNoe.g. hydrology.river-level
ots_statusNoPer-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_refNoURL of the official source record.
undeterminedNotrue when the lookup itself failed (e.g. DB unavailable) - NOT a verdict of "fake".
record_statusNoThree-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_dateNoYYYY-MM-DD of the reading.
reverse_lookupNoPlain-language statement of exactly what this hash attests.
recomputed_hashNosha256:<64 hex> recomputed from the stored record.
hash_core_versionNoVersion of the canonical hash core used.
is_truth_bear_recordNotrue / false, or null when the check could not be run (see undetermined).
how_to_check_a_claimed_valueNoPresent when found: how to check a value someone claims.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema 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."
  2. Changed1 schema 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"
      +  ]
      +}
  3. Changed1 schema 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"
      +}
  4. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.