Skip to main content
Glama

JIDEC: Bitcoin-anchored public verification ledger (NENRIN)

by io.github.ogasurfproject-jpg

Cite and independently verify a JIDEC record

jidec_cite
Read-onlyIdempotent

Resolve and INDEPENDENTLY verify any JIDEC citation. Accepts 'jidec:path:', 'jidec:entry:', a bare 64-hex id, or a ledger URL. Fetches the record's exact bytes, recomputes SHA-256 locally, and confirms it equals the cited id. Returns integrity, Bitcoin anchoring status, the parsed record (verification path, claim, or v0 spec entry), and an explicit statement of what the proof does and does not cover. No trust in HORIZON SHIELD is required to accept the result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
citationYesjidec:path:<sha> | jidec:entry:<n> | 64-hex | ledger URL

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitsNo
lookupYesok = the ledger was read and the record exists. absent = the ledger was read and there is no such record. A read that FAILED never appears here: it comes back as a tool error (isError: true), so a consumer can never mistake this server's own failure for a statement about the ledger's contents.
bitcoinNo
citationNo
integrityYesThe whole point: claimed vs recomputed. match:false is an integrity FAILURE, which is a finding, not an error.
trust_noteNo
record_kindNo
resolved_entryNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "bitcoin": {
+      "properties": {
+        "status": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "citation": {
+      "type": "string"
+    },
+    "integrity": {
+      "description": "The whole point: claimed vs recomputed. match:false is an integrity FAILURE, which is a finding, not an error.",
+      "properties": {
+        "claimed_sha256": {
+          "type": "string"
+        },
+        "match": {
+          "type": "boolean"
+        },
+        "recomputed_sha256": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "match"
+      ],
+      "type": "object"
+    },
+    "limits": {
+      "type": "string"
+    },
+    "lookup": {
+      "description": "ok = the ledger was read and the record exists. absent = the ledger was read and there is no such record. A read that FAILED never appears here: it comes back as a tool error (isError: true), so a consumer can never mistake this server's own failure for a statement about the ledger's contents.",
+      "enum": [
+        "ok",
+        "absent"
+      ],
+      "type": "string"
+    },
+    "record_kind": {
+      "type": "string"
+    },
+    "resolved_entry": {
+      "type": [
+        "number",
+        "string",
+        "null"
+      ]
+    },
+    "trust_note": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "lookup",
+    "integrity"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already indicate read-only, open-world, and idempotent behavior, and the description adds valuable, non-obvious details: fetching exact bytes, recomputing SHA-256 locally, returning integrity and Bitcoin anchoring status, and providing an explicit statement of proof coverage. It also conveys the key trust property that no confidence in HORIZON SHIELD is required, which is beyond any annotation.

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 dense but every sentence contributes something: the inputs, the cryptographic verification process, the output contents, and the trust guarantee. There is no fluff or redundancy, and it is front-loaded with the primary purpose.

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 a single parameter, clear input syntax, and an output schema, the description is still thorough: it explains the response categories by mentioning integrity, anchoring status, parsed record, and coverage statement. It also addresses verification implications and scope of trust, making the tool complete enough for selection and invocation.

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 input schema already fully documents the citation parameter and lists the accepted formats. The description repeats those formats without adding much beyond making the syntax clearer by using 'bare 64-hex' and 'ledger URL'. This does not materially expand on the schema's coverage.

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 names a specific verb and resource: resolve and verify a JIDEC citation, and it explicitly states what that verification entails. It is easy to distinguish from sibling tools like jidec_list_paths or jidec_replay because it emphasizes integrity checking and independent proof rather than enumeration or replay.

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 for when to use the tool: whenever you have a JIDEC citation of any allowed form and need independent verification. It does not explicitly name alternatives or state when not to use it, but the accepted formats and verification purpose effectively convey the intended use.

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

All JIDEC: Bitcoin-anchored public verification ledger (NENRIN) toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a unique purpose: verifying a citation, explaining how to verify manually, listing anchored paths, and replaying a path to detect drift. There is no meaningful overlap between them.

Naming Consistency4/5

All tools share the jidec_ prefix and use snake_case, but the verb structure is irregular: jidec_cite and jidec_replay are simple verbs, jidec_list_paths is verb+noun, and jidec_how_to_verify is a phrase. Minor deviation from a uniform verb_noun pattern.

Tool Count5/5

Four tools is a focused, well-scoped set for a verification-oriented ledger server. Each tool serves a clear need without bloat or redundancy.

Completeness5/5

The domain is verifying and auditing Bitcoin-anchored JIDEC records, and the tools cover the full workflow: verify a citation, learn how to verify manually, list anchored paths, and re-check a path against the live system. No obvious dead ends or missing operations within the stated scope.

Resources