Skip to main content
Glama
lkopietz3-byte

honesty-mcp

by lkopietz3-byte
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Verify a tamper-evident audit chain

verify_audit_chain

Re-verifies an audit hash chain, recomputing hashes and checking prevHash links to detect payload tampering, severed links, and truncation; use anchor or expectedMinLength to catch tail deletion.

Instructions

Independently re-verifies a hash chain from genesis: recomputes every entry's hash and confirms each entry's prevHash matches the preceding entry's entryHash. Detects a mutated payload (stored entryHash no longer matches recomputed hash) and a severed link or spliced-out middle entry (prevHash mismatch) with no options at all. Two DIFFERENT truncation attacks need two DIFFERENT options, and neither is on by default: (1) entries deleted from the end and NOT replaced -- pass expectedMinLength to catch a chain that's simply shorter than it should be (a tail deletion alone leaves no broken pointer for the walk to find); this does NOT catch truncate-and-re-append (deleting tail entries and then appending new, self-consistent ones to reach the same length again -- expectedMinLength sees the 'right' length and passes). (2) to catch truncate-and-re-append, pass anchor: an { index, entryHash } checkpoint you saved earlier from a source the chain's writer cannot edit (your own log, a separate append-only store). The chain is invalid unless the entry at anchor.index has exactly that entryHash -- this also catches a full rewrite from genesis, but entries after the anchor are only checked for internal consistency, not against anything external. Passing neither option means a truncate-and-re-append (or a full rewrite from genesis) can pass as 'valid'. Proves the chain is internally consistent and unaltered since it was hashed (and, with anchor, unaltered up to the anchor point); it does NOT prove nobody with write access ever rewrote the whole chain from genesis when no anchor is supplied (tamper-evident, not tamper-proof). Use this to audit a chain you did not produce yourself before trusting it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesThe chain to verify, exactly as stored/received.
anchorNoA checkpoint obtained earlier from somewhere the chain's writer cannot change (your own log, a separate append-only store) -- e.g. `{ index: chain.length - 1, entryHash: chain[chain.length - 1].entryHash }` saved right after you last trusted this chain. The chain is invalid unless it has an entry at `anchor.index` with exactly this entryHash. This is what actually catches truncate-and-re-append or a full rewrite from genesis -- `expectedMinLength` alone does not. Entries after the anchor are only checked for internal consistency, not against anything external.
expectedMinLengthNoIf you know how long the chain should be, pass it to catch entries deleted from the end and NOT replaced. Does NOT catch truncate-and-re-append (see `anchor`) -- a chain shortened and then extended back to this length with new entries passes this check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it names the two truncation attacks, states that neither is caught by default, distinguishes what `expectedMinLength` versus `anchor` each catch, and explicitly bounds the guarantee ('tamper-evident, not tamper-proof', post-anchor entries only internally consistent). No behavioral trait is left implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core operation, then the option/attack analysis. It is long for a tool description and repeats the truncate-and-re-append distinction in several places, but the density is largely justified by the subtle security semantics being conveyed.

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?

Covers what is verified, what attacks are and are not detected, and the limits of the guarantee. The one minor gap is that it never states the exact response shape (verdict field, per-entry error reporting), though there is no output schema to lean on for that.

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?

Schema description coverage is 100%, so the baseline is 3; the description goes beyond the schema by explaining the security semantics of the optional parameters (what each attack each one catches, and the consequence of omitting both). That is real added meaning over the structured fields, though the mechanics of `anchor` are also restated in the schema itself.

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?

States a precise verb and resource ('Independently re-verifies a hash chain from genesis') and immediately defines the exact operations performed (recomputes each entryHash, checks prevHash linkage). It is clearly distinguishable from the writer sibling append_audit_entry, which produces rather than checks chains.

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?

Gives explicit when-to-use ('Use this to audit a chain you did not produce yourself before trusting it') and, more importantly, tells the agent exactly which optional parameters to supply for which threat model and what silently passes if neither is given. This is unusually complete routing guidance for a verifier.

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

Deploy Server

Other Tools