Skip to main content
Glama

frank_verify

Read-only

Verifies the integrity of the FRANK governance chain by checking every hash link and comparing the chain head against an external anchor, detecting tampering, edits, or gaps.

Instructions

Re-hash the entire FRANK governance chain and verify every prev_hash → hash link, detecting tampering, edits, or gaps. Returns the verification verdict, including where the chain breaks if it does.

Also checks the chain's head against the externally-held anchor at $WILLOW_HOME/constitutional/frank_head_anchor.json when one exists (#280): a chain can be internally consistent (every link valid) and still not be the same chain it was yesterday — that's what an edit-then-rechain() relink looks like from outside the database. anchor_status reports which case applied: "anchored" (compared; valid reflects both internal consistency AND the head match), "unanchored" (no anchor file — most installs, opted out), "untrusted" (anchor file failed the ownership/permission trust check), or "unreadable" (missing/malformed). Only "anchored" means the head was actually compared; the other three are reported explicitly rather than silently treated as a pass. Use willow-mcp frank-anchor (CLI-only — never an MCP tool, so an agent cannot mint its own anchor) to create or refresh one.

On a head mismatch, anchor_in_chain says which of the two causes it is. True means the anchored head is still in the chain at anchor_index, so the anchored entries are untouched and entries_since_anchor rows were simply appended after them — an anchor that has gone stale, not a tampered chain. False means the anchored head is nowhere in this chain, which is what an edit-then-rechain() relink looks like; investigate before re-anchoring, because refreshing the anchor would erase the only external record that the chain ever differed. anchor_count is the row count recorded when the anchor was taken. A broken LINK (broken_at set) also carries reason: "prev_hash linkage" (rows reordered, inserted or deleted) or "entry_hash mismatch" (a row's own content edited), plus the last good head reached before the break. Read-only; may take a moment on a long ledger.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
app_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.2.3

TDQS

A4.1/5.0
Behavior5/5

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

With annotations already declaring readOnlyHint=true, the description still adds substantial behavioral detail: anchor trust-check failures, explicit anchor_status values, the distinction between internal consistency and head mismatch, and what edit-then-rechain looks like externally. The description also states it is read-only and may be slow on long ledgers, which is useful beyond the annotations.

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?

The description is long but front-loaded with the core purpose and packed with genuinely relevant edge-case semantics. Every added detail about anchor_status, anchor_in_chain, and broken link reasons earns its place, though the density makes it slightly harder to scan quickly.

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?

There is no output schema, so the description correctly takes responsibility for explaining return semantics: verdict, anchor_status values, anchor_in_chain interpretation, anchor_count, broken_at, reason, and last good head. For a verification tool with this complexity, the description is remarkably complete and actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one required parameter, app_id, with 0% schema description coverage, yet the description never explains what app_id should be or how to determine its value. The only available meaning is the generic title 'App Id', with no additional guidance in the description to compensate.

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: re-hash the FRANK governance chain and verify every prev_hash→hash link to detect tampering, edits, or gaps. It clearly distinguishes this from related tools by emphasizing external anchor comparison and the verdict it returns.

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 about when anchor-related cases apply and instructs the agent to use the CLI-only `willow-mcp frank-anchor` rather than an MCP tool for creating/refreshing anchors. It does not explicitly compare against sibling verification tools like knowledge_verify, but the operational guidance is otherwise strong.

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