Skip to main content
Glama

anchor

Emit a compact, externally-publishable hash snapshot of the full write and erasure history. Publish it to a witness log to detect retroactive rewriting and verify consistency later.

Instructions

TAMPER-EVIDENT MEMORY / transparency log: emit a HEAD COMMITMENT — a compact, externally-publishable snapshot {n_writes, writes_tip, n_tombstones, tombstones_tip, ts, sth_hash} that hash-commits to the ENTIRE write + erasure history at this instant. It is a hash commitment and carries NO signature from this server: a key the store operator holds is the very thing it must not depend on, so the signature comes from outside (a witness co-signs sth_hash; see verify_cosigned_anchor and inspeximus anchor). Publish it somewhere the store operator cannot retroactively alter (a public log, a third-party witness, the auditor's own records). This closes the one hole verify_writes() cannot: an operator who HOLDS the receipt key can rewrite AND re-sign the whole history so it still verifies internally — but they cannot make the rewritten tip equal an anchor an outsider already witnessed. Record this now; check later with verify_consistency(). (RFC 6962 model; the external witnessing is the auditor's job.) Quickstart, install to a verified co-signed anchor: docs/TRANSPARENCY.md, or inspeximus anchor in the shell.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.20.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden, and it delivers: it states the tool emits an unsigned hash commitment, does not depend on the operator-held key, and must be cosigned externally. It also discloses the threat model and the exact fields included in the snapshot.

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 first sentence front-loads the core purpose and output fields, and subsequent sentences add necessary security and usage context. It is verbose, with some redundancy around the signature model, but each section earns its place for a security-sensitive tool.

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?

Despite having no output schema or annotations, the description provides the full snapshot shape, related verification tools, external publishing guidance, and a documentation pointer. An agent has enough to call the tool correctly and understand its trust assumptions.

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 tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description adds no parameter-specific detail because none exists.

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 opens with a specific verb and resource: 'emit a HEAD COMMITMENT' that hash-commits to the entire write and erasure history. It names the output snapshot fields and differentiates itself from related tools by explaining it closes a gap that verify_writes() cannot.

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?

It explicitly instructs when to act ('Record this now; check later with verify_consistency()') and names the relevant alternatives (verify_cosigned_anchor, inspeximus anchor, verify_writes). It also states a prerequisite: publish the commitment where the operator cannot retroactively alter it, and explains why verify_writes is insufficient.

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