A
licenseB
qualityC
maintenanceEnables revision-bound source audits with exact article fingerprinting, claim-to-source mapping, quotation verification, and immutable JSON evidence reports for prepublication review.
9
MIT
JIDEC: Bitcoin-anchored public verification ledger (NENRIN)
Server Details
Cite and independently verify Bitcoin-anchored construction-estimate audit records.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ogasurfproject-jpg/horizon-shield
- GitHub Stars
- 1
- Server Listing
- HORIZON SHIELD KIRA
Available Tools
4 toolsjidec_citeCite and independently verify a JIDEC recordARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | jidec:path:<sha> | jidec:entry:<n> | 64-hex | ledger URL |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| limits | No | |
| lookup | Yes | 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. |
| bitcoin | No | |
| citation | No | |
| integrity | Yes | The whole point: claimed vs recomputed. match:false is an integrity FAILURE, which is a finding, not an error. |
| trust_note | No | |
| record_kind | No | |
| resolved_entry | No |
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.
jidec_how_to_verifyGet the executable verification recipeARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | jidec:path:<sha> | jidec:entry:<n> | 64-hex | ledger URL |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| lookup | Yes | 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. |
| recipe | No | |
| path_id | No | |
| citation | No | |
| resolved_entry | No |
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.
jidec_list_pathsList anchored verification pathsARead-onlyIdempotentInspect
List the anchored JIDEC verification paths (most recent first), with purpose, verdict and Bitcoin anchoring status.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | How many anchored paths the ledger returned. 0 means the ledger answered and holds none. It never means the ledger could not be read — that is an error. |
| paths | No | |
| lookup | Yes | 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. |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds the ordering (most recent first) and the specific fields returned, which provides some additional behavioral context. However, it does not elaborate on the openWorldHint (results may change) or any other behavioral nuances like rate limits or external data sources. With annotations in place, the description adds limited but not negligible value, so a 3 is fair.
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, well-structured sentence. It front-loads the main action ('List the anchored JIDEC verification paths') and then specifies ordering and key fields. There is zero filler content, and every word adds value. It is concise and to the point, perfectly structured for quick consumption by an agent.
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 the tool has no parametersley and includes an output schema (which presumably documents the returned fields), the description only needs to explain the purpose and distinguishing features. It clearly states the list is anchored verification paths, sorted most recent first, with purpose, verdict, and anchoring status. There is no missing information for an agent to decide whether to call this tool. The annotations cover safety, and the output schema covers structure. The description is complete for this simple read-only operation.
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 input schema has zero parameters, so there is nothing to document. The description does not need to explain parameters; it only clarifies what the tool lists grain order. According to the rubric, with 0 parameters, a baseline of 4 is given. There is no conflict or missing info, so this score is justified.
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 verb 'List' with a specific resource ('anchored JIDEC verification paths'), and explicitly mentions the sorting (most recent first) and key fields (purpose, verdict, Bitcoin anchoring status). It naturally distinguishes itself from sibling tools like jidec_cite, jidec_how_to_verify, and jidec_replay, which perform different actions. This is a precise, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to retrieve a list of anchored verification paths. It does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. The context of sibling tools suggests a list operation is intended for inspection before citing or verifying, but this is not spelled out. There is no mention of when not to use it or any special conditions. This is minimal but not misleading, so a 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jidec_replayRe-observe an anchored path and report driftARead-onlyIdempotentInspect
Re-observe an anchored JIDEC verification path against the live system right now and report drift. Returns MATCH (the live system still matches what was anchored) or DRIFT (it changed), node by node. Nodes that cannot be re-observed server-side are reported as deferred, never counted as drift.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | jidec:path:<sha> | jidec:entry:<n> | ledger URL |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| lookup | Yes | 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. |
| verdict | No | MATCH or DRIFT. Nodes that could not be re-observed are deferred, never counted as drift. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe, read-only, idempotent operation. The description adds valuable behavioral context: it returns MATCH or DRIFT node by node, and nodes that cannot be re-observed are deferred rather than counted as drift. This goes beyond basic safety and explains edge-case handling.
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 three sentences: first states the primary action, second explains the return values (MATCH/DRIFT), and third clarifies the deferred behavior. No filler or redundancy; it is well-structured and 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?
For a tool with a single parameter and rich annotations, the description is fully adequate. It explains the core operation, result interpretation, and an important edge case (deferred nodes). The presence of an output schema further reduces the need to detail return formats.
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 provides 100% coverage for the single 'citation' parameter with clear format examples. The description does not add new parameter-level detail beyond referring to 'anchored path', so the baseline score of 3 applies as the schema handles the heavy lifting.
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: 'Re-observe an anchored JIDEC verification path against the live system right now and report drift.' It specifies the resource (anchored JIDEC verification path) and the action (re-observe and report), and distinguishes itself from siblings by focusing on drift detection with MATCH/DRIFT output.
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 provides clear usage context: this tool is for checking current alignment of an anchored path via re-observation. It does not explicitly name alternatives or exclusions relative to sibling tools, but the focus on drift reporting implies when to use it. A 4 reflects clear context without explicit exclusions.
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.
4 tool updates
- Changed
jidec_cite1 field changed- changed
Output 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" +}
- Changed
jidec_how_to_verify1 field changed- changed
Output 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" +}
- Changed
jidec_list_paths1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "count": { + "description": "How many anchored paths the ledger returned. 0 means the ledger answered and holds none. It never means the ledger could not be read — that is an error.", + "type": "number" + }, + "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" + }, + "paths": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "lookup", + "count" + ], + "type": "object" +}
- Changed
jidec_replay1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "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" + }, + "verdict": { + "description": "MATCH or DRIFT. Nodes that could not be re-observed are deferred, never counted as drift.", + "type": "string" + } + }, + "required": [ + "lookup" + ], + "type": "object" +}
4 tool updates
- First observed
jidec_cite - First observed
jidec_how_to_verify - First observed
jidec_list_paths - First observed
jidec_replay
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
Independent pre-transaction audit for construction estimates. Free, and every verdict recomputes.
Bitcoin-anchored, tamper-evident audit-permanence layer for AI agents, FRE 902(13)/(14)-shaped.
Deterministic AI liability attribution with Bitcoin-anchored proof certificates.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides cryptographic truth infrastructure for AI agents, enabling them to seal content with SHA-256 and Ed25519, verify receipts, anchor them to Bitcoin via OpenTimestamps, generate citations, and audit chains of receipts.5501MIT
markovian-mcpofficial
AlicenseAqualityDmaintenanceBitcoin-anchored provenance for AI outputs; enables stamping, verifying, and tracing outputs with offline-verifiable canonical roots.3Apache 2.0- FlicenseNot gradedqualityCmaintenanceCryptographically anchored, tamper-evident evidence receipts for AI agents — verified run receipts, existence-at-time proofs, and cited answers from an anchored public record. Remote MCP with proof-gated settlement; attests existence and integrity, never truth.-
Try in Browser
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.