Blog · 2026-10-09 · Dual-Pillar series · Tooling

Four MCP tools, thirty seconds to verify a cryptographic proof

iqa-mcp · v1.0.2 · PyPI / npm / crates.io · Apache-2.0 · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)

Author: Aicent Stack · Part of the Dual-Pillar series · Tooling

The previous two pieces covered the dual-pillar design: addresses are derived (rttp://), evidence is an envelope (iqa://). However much design talk there is, nothing beats running a piece of cryptographic evidence with your own hands — this piece does one thing only: in 30 seconds, take you from receiving evidence to verifying it, and then breaking it yourself.

1. What it is

iqa-mcp is a small MCP server that packs the dual-pillar protocol's capabilities into four tools. Any MCP-compatible client — Claude Desktop, Cline, your own agent stack — can call them directly.

Three engineering disciplines, on the record: stateless (the server stores nothing; keys are passed in by the caller each time and discarded after use); fail-closed (malformed input is always refused, never charitably downgraded); offline (all verification runs locally — zero network, zero third parties).

2. Install: three roads, one command

pip install iqa-mcp          # Python ≥ 3.11
npm install -g iqa-mcp       # or one-shot: npx iqa-mcp
cargo install iqa-mcp

Client configuration (Claude Desktop / Cline style):

{
  "mcpServers": {
    "iqa": { "command": "iqa-mcp" }
  }
}

All three roads land on the same iqa-mcp command; the configuration is universal.

3. The 30-second hands-on chain

Step 1 · published_vector: fetch the public conformance vector AE128-VECTOR-1 — the authority string, the documented test key, the lease, the full 128-byte frame (hex). A fixed value pinned in the specification.

Step 2 · parse_envelope(frame): structured decoding. No key required; read out magic, version, lease, subject shard, standing, field by field... the slightest format non-compliance is refused — malformed input never yields "partial parse results".

Step 3 · verify_envelope(frame, test key): constant-time whole-frame HMAC-SHA256 verification plus lease check. Output: [PASS] — byte for byte, anyone reproduces the same result.

Step 4 · flip one byte: change any byte in the frame and verify again. Output: REJECT.

No error dialog, no "tampering detected" toast. The frame simply, quietly stops verifying — tampering does not need a watchman to be stopped; it fails the mathematical gate on its own.

4. Division of labor among the four tools

derive_route_shard: derive a 16-byte intent shard from any authority string — the address is a mathematical fact, no registry;
parse_envelope: structured decoding (keyless), fail-closed on every layout rule;
verify_envelope: whole-frame verification plus lease check, fail-closed — REJECT is a conclusion, not an exception;
published_vector: the public conformance vector — making "reproducible" a documented claim.

A design point worth pausing on: the organ key is passed in by the caller, not hosted — whoever sees the key holds the verification power. The server deliberately never touches it.

5. The honest boundary

iqa-mcp is the tool surface, not a new protocol — the protocol lives in the dual pillars (RTTP + IQA) and the draft; it hosts no keys; it does no real-time risk control; whether the four-tool split is optimal is under open consultation (the specification is still under review — nothing is carved in stone).

Repos: github.com/Aicent-Stack/iqa-mcp · Landing page and full evidence chain: iqa.org · Addressing pillar: rttp.com

One sentence: don't trust this article — run the vector; in 30 seconds you will have your own answer.