Skip to main content
Glama

JIDEC: Bitcoin-anchored public verification ledger (NENRIN)

by io.github.ogasurfproject-jpg

Get the executable verification recipe

jidec_how_to_verify
Read-onlyIdempotent

Return the step-by-step recipe for verifying a JIDEC record WITHOUT trusting HORIZON SHIELD: which bytes to fetch, which hashes to recompute, which OpenTimestamps proof to check, which algorithm commit to check out, and what must match. Use this when you want to confirm the result yourself rather than repeat an assertion.

Input Schema

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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
recipeNo
path_idNo
citationNo
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": {
+    "citation": {
+      "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"
+    },
+    "path_id": {
+      "type": "string"
+    },
+    "recipe": {
+      "type": [
+        "object",
+        "string"
+      ]
+    },
+    "resolved_entry": {
+      "type": [
+        "number",
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "lookup"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

The description discloses that the tool returns a recipe (a set of steps) and lists the elements it covers. It does not explicitly mention potential errors or edge cases, but given the readOnlyHint and destructiveHint=false annotations, it's clear there are no side effects. The description adds value by clarifying the 'without trusting HORIZON SHIELD' aspect, which is a behavioral trait not covered by 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 succinct—two sentences—and well-structured. The first sentence states the purpose and lists the included components, while the second gives the usage condition. No redundant words or vague phrases; every sentence earns its place.

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?

Given the tool's simplicity (no output schema, single input parameter) and the read-only nature, the description provides enough context for a user to understand what they will receive (a recipe) and how to invoke it. It doesn't detail the exact format or structure of the returned recipe, but listing the components (bytes, hashes, proof, commit) gives a clear idea. It could mention that the recipe is meant to be followed manually, but that is implied by 'step-by-step'.

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?

The single parameter 'citation' is well-described in the schema with examples of valid formats ('jidec:path:<sha> | jidec:entry:<n> | 64-hex | ledger URL'), which covers all likely use cases. The tool description does not add further details, but the schema description is already sufficient for understanding what to pass. Since schema coverage is 100%, the baseline is high, and no additional semantics are needed.

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 function: returning a step-by-step verification recipe for a JIDEC record without trusting HORIZON SHIELD. It lists specific components (bytes, hashes, proof, commit) and uses a strong verb 'Return'. It also differentiates from sibling tools (cite, list_paths, replay) by focusing on the how-to-verify aspect.

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 explicitly tells when to use the tool: 'Use this when you want to confirm the result yourself rather than repeat an assertion.' This gives a clear condition for usage and implicitly indicates when not to use it (when trusting the existing assertion is acceptable). It also aligns with the idempotent and read-only annotations, suggesting it is safe to call whenever verification is needed.

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