How do I use iqa-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@iqa-mcp run the published AE128-VECTOR-1 self-test and show the verification result" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

iqa-mcp

by Aicent-Stack

Overview Schema Source Related Servers Discussions Admin

Python

Local

iqa-mcp

PyPI License self-test M8ven Score

The IQA attestation primitives — derived intent addressing and AE-128 envelope verification — exposed as Model Context Protocol tools, so any MCP agent (Claude Desktop, Cline, your own client, an Uber-style MCP Gateway) can verify trust offline, fail-closed.

A thin, stateless wrapper around the published iqa-org 1.3.1 reference implementation. No network. No accounts. No key storage. No state.

PyPI · iqa-mcp · Apache-2.0 Spec · draft-li-rttp-iqa-addressing — Independent Submission, in review Landing page · iqa.org/MCP/

Why

Agent platforms are converging on MCP as the tool-calling layer, at industrial scale. What none of them standardize is trust semantics: what intent is being addressed, and whether the counterparty holds standing — verifiable without a network call. These four tools make that layer native to any MCP agent.

Related MCP server: vantic-mcp

Install

Requires Python ≥ 3.11.

# from PyPI — installs the `iqa-mcp` console command
pip install iqa-mcp

# launcher equivalents — same `iqa-mcp` command, they fetch and wrap the Python package above
npm install -g iqa-mcp        # or run once: npx iqa-mcp
cargo install iqa-mcp

# or run from source
pip install "iqa-org>=1.3.1" "mcp>=2"
python server.py            # stdio transport

All three install paths end at the same iqa-mcp command; the MCP client configuration below works unchanged for any of them.

MCP client configuration (Claude Desktop / Cline style):

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

(From source, use "command": "python", "args": ["/path/to/server.py"] instead.)

Tools

Tool	Input	Returns	Key needed
`derive_route_shard`	authority string	`SHA-256(authority)[0:16]` hex — the derived, action-independent intent address	no
`parse_envelope`	AE-128 frame hex	structural decode: version, lease, shard, organ, nonce, standing — fails closed on every layout rule	no
`verify_envelope`	frame hex + organ key	full verification: constant-time HMAC-SHA256 over the whole 128-byte frame (attestation zeroed) + lease check. REJECT is a result, not an error	yes (caller-supplied)
`published_vector`	—	the published AE128-VECTOR-1 (authority, test key, frame hex — see iqa-org) for byte-for-byte self-test	—

Try it in thirty seconds

published_vector            -> AE128-VECTOR-1: authority + test key + frame hex
parse_envelope(frame)       -> standing radiant · nonce 1 · lease unexpired
verify_envelope(frame, key) -> PASS
flip one byte of standing   -> REJECT (HMAC mismatch)

That last line is the point: tampering is not detected by anyone watching — the frame simply stops verifying, offline, for any verifier, forever.

Self-test

# installed from PyPI — runs against the iqa-mcp console script
python -m test_mcp

# or from a source checkout — runs against ./server.py
python test_mcp.py
# [PASS] 1 · list_tools        -> 4 tools
# [PASS] 2 · derive_route_shard -> 5c378581f92754d0bc88adaed84b7c5a
# [PASS] 3 · published_vector   -> f3b2a1c4.pillar.example
# [PASS] 4 · parse_envelope     -> standing radiant
# [PASS] 5 · verify_envelope    -> [PASS] radiant · nonce 1
# [PASS] 6 · tampered frame     -> REJECT (HMAC mismatch)
# [PASS] 7 · malformed hex      -> REJECT
# ALL 7/7 PASS

Design invariants

Inherited from the schemes:

Zero-parser — fixed offsets, no TLV, no heap-shaped parsing.
Fail-closed — malformed input is a REJECT result, never a normalised partial answer.
Offline — verification needs the frame, the key, and a hash function. Nothing else.
Stateless — the server stores nothing; the organ key is passed per call by the client and never persisted.

What this is not

Stated plainly, because evidence tooling that oversells is just marketing:

Not real-time governance. Gateways and policy engines decide in the moment; this server proves after the fact. The two compose; neither replaces the other.
Not a delegation scheme. v1.3.x intentionally specifies no delegation semantics — see the draft's honest-boundary notes.
Not a key custodian. The organ key never touches this server's state; verification is caller-supplied, per call. Never pass a production organ key through a host you do not control — whoever sees the key holds the verification power.
Not a benchmark. The demos at iqa.org execute real WebCrypto in the browser; this server wraps the same published primitives.

Status

Published on PyPI: https://pypi.org/project/iqa-mcp/ — current version in the badge above.
Transport: stdio. A hosted streamable-HTTP endpoint is under consideration; the tools are stateless, so hosting adds no custody.
Underlying schemes: iqa-org 1.3.1 (PyPI / npm / crates.io — four registries, byte-exact vectors, offline self-test).
Specification: draft-li-rttp-iqa-addressing — Independent Submission, in review.

Sister repositories

iqa-org — the reference implementation (addressing, envelope, verification).
rttp — the addressing scheme: design notes and open questions.
Organization discussions — start-here map and cross-repo threads.

Public record

Everything this tool wraps is public and checkable — no asking us:

Landing page: https://iqa.org/MCP/
Public record, dated: https://iqa.org/brief/
Live demos — the audit chain this tool joins: https://iqa.org/demo/compare/ · https://iqa.org/demo/delegation/
Whitepaper: https://iqa.org/whitepaper/ (also at rttp.com/whitepaper)
Internet-Draft: draft-li-rttp-iqa-addressing — Independent Submission, in review
The library this server wraps: iqa-org 1.3.1 on PyPI — four registries, byte-exact vectors, offline self-test

License

Apache-2.0 — © RTTP & IQA Organization

Available Tools

4 tools

derive_route_shardA

Read-onlyIdempotent

Derive the ROUTE_SHARD / intent shard for an authority: SHA-256 of the exact authority string, first 16 bytes, lowercase hex. Deterministic, offline, action-independent (SPEC sec. 3). No lookup, no registry, no network call.

ParametersJSON Schema

Name	Required	Description	Default
`authority`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the derivation is deterministic and action-independent with no network or registry access, plus a SPEC section reference. It largely reinforces rather than extends the annotation set, keeping it below a 5.

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?

Three tight sentences, front-loaded with the purpose and the exact formula, then the determinism/offline guarantees. Every clause carries information; nothing is filler.

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 single-parameter pure-computation tool with an output schema and full annotation coverage, the description supplies the algorithm, the output encoding (16 bytes, lowercase hex) and the determinism guarantees. Nothing needed to invoke it correctly is missing.

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 coverage is 0%, so the description carries the burden for the single 'authority' parameter, and it does so meaningfully: 'SHA-256 of the exact authority string' signals that the raw string is hashed without normalization or trimming. It stops short of specifying encoding, whitespace or case handling explicitly.

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 specific verb (derive) and resource (ROUTE_SHARD / intent shard for an authority) and pins down the exact algorithm: SHA-256 of the authority, first 16 bytes, lowercase hex. This precision makes it clearly distinguishable from the envelope-processing siblings, and 'no lookup, no registry' rules out the lookup-style tools.

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?

It implies when the tool applies (deterministic, offline, action-independent, per SPEC sec. 3) but never names an alternative or states an explicit when-not-to-use condition. The 'no lookup, no registry, no network call' line hints at what it is not, which is useful but not framed as routing guidance.

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

parse_envelopeA

Read-onlyIdempotent

Structural decode of one AE-128 attestation envelope (128 bytes, hex). No organ key needed. Fails closed on every layout rule of the companion draft sec. 2/sec. 4 -- malformed input is never normalised into a partial result.

ParametersJSON Schema

Name	Required	Description	Default
`envelope_hex`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds genuinely new behavior: it fails closed on layout rules and never normalises malformed input into a partial result. It also covers the auth aspect (no key required), which annotations do not.

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?

Three dense sentences, front-loaded with the operation and scope, with no filler. The reference to 'companion draft sec. 2/sec. 4' is slightly opaque jargon, but each clause carries information.

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?

With an output schema present, return values need not be described; the description instead covers input format, key requirement, and failure semantics. Only explicit sibling routing is missing for a tool with three neighbors.

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 0% and the schema only labels the field 'Envelope Hex', so the description carries the burden — and it does, specifying the input is a single 128-byte hex envelope. It does not clarify casing, prefix, or exact byte-length validation behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Structural decode of one AE-128 attestation envelope') with a concrete size/format qualifier (128 bytes, hex). The 'No organ key needed' clause implicitly distinguishes it from the sibling verify_envelope, though no sibling is named explicitly.

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?

There is no explicit when-to-use/when-not statement or named alternative. The keyless framing ('No organ key needed') implies this is the structural-only counterpart to verify_envelope, but the agent must infer that routing rather than being told.

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

published_vectorA

Read-onlyIdempotent

Return AE128-VECTOR-1, the published conformance vector (companion draft sec. 6): the example authority, the documented test organ key, the lease, and the full 128-byte frame as hex. Feed these into verify_envelope and you must get [PASS] -- byte for byte, offline.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely new behavioral context: the output is a fixed published fixture expected to round-trip to [PASS] byte-for-byte and works offline, which tells the agent the result is deterministic and self-contained.

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?

Two sentences, front-loaded with the vector identifier and its section reference, with no filler. The middle list of payload components is information-dense but slightly crowded against the usage clause.

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?

An output schema exists, so return-value documentation is not required, yet the description still summarizes the payload composition and the expected verification outcome. For a zero-parameter, read-only fixture tool, an agent has everything needed to select and call it correctly.

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 takes zero parameters, so per the rubric the baseline is 4. The description correctly adds nothing about inputs, and instead spends its words describing the returned payload, which is the relevant semantic content for a no-arg tool.

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 specific verb+resource (return the published conformance vector AE128-VECTOR-1) and enumerates its payload components (authority, organ key, lease, 128-byte frame). It also names the sibling it feeds into (verify_envelope), so an agent can distinguish it from derive_route_shard and parse_envelope without opening a schema.

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 second sentence gives a clear use context: feed the output into verify_envelope, expecting [PASS] byte-for-byte, offline. That establishes the tool as a deterministic test fixture. However, it does not state when NOT to use it or contrast it with the other siblings (derive_route_shard, parse_envelope).

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

verify_envelopeA

Read-onlyIdempotent

Full AE-128 verification (companion draft sec. 4): constant-time HMAC-SHA256 over the whole 128-byte frame with the attestation field zeroed, plus the optional lease check. organ_key is the organ's shared test/deployment key (this server is stateless and stores nothing). REJECT is a result, not an error: a flipped byte anywhere breaks the MAC.

ParametersJSON Schema

Name	Required	Description	Default
`now`	No
`organ_key`	Yes
`check_lease`	No
`envelope_hex`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior, and the description adds real context beyond them: constant-time comparison, the attestation field being zeroed, the server being stateless ('stores nothing'), and crucially that REJECT is a result rather than an error. It does not discuss rate limits or failure modes beyond the MAC, but the added value is substantial.

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?

Three dense sentences, front-loaded with the core operation and zero filler. The result-semantics clarification is placed last, which is sensible, though the jargon load ('companion draft sec. 4', 'AE-128') assumes reader familiarity.

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?

An output schema exists, so return values need not be explained, and the description covers the verification semantics and result interpretation adequately. The only real gap is the undocumented `now` parameter, which an agent cannot infer from either the schema or the description.

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?

Schema coverage is 0%, so the description carries the full burden. It explains organ_key well ('shared test/deployment key', stateless server) and touches check_lease ('optional lease check'), but the `now` parameter is never mentioned and envelope_hex is only implied by '128-byte frame'. Partial compensation for a four-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full AE-128 verification') and names the concrete mechanism (HMAC-SHA256 over the 128-byte frame), so an agent can distinguish it from parse_envelope. It stops short of explicitly contrasting itself with the siblings, so it is clear but not sibling-differentiated.

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?

Usage is implied by the mechanism description and the 'optional lease check' phrasing, which hints at when check_lease applies. There is no explicit when-to-use/when-not statement or routing to parse_envelope or published_vector.

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.

4 tool updatesv1.0.2Oct 18, 2026
- First observedderive_route_shard
- First observedparse_envelope
- First observedpublished_vector
- First observedverify_envelope

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.9/5.0

Scored 2026-10-18 19:20 across 4 tools

Disambiguation4/5

The four tools have largely distinct purposes: derive_route_shard computes a shard, parse_envelope does structural decoding, verify_envelope does cryptographic verification, and published_vector returns a test fixture. parse_envelope and verify_envelope both operate on the same 128-byte envelope, which could momentarily confuse an agent, but the descriptions clearly separate 'structural, no key' from 'HMAC verification with organ_key'.

Naming Consistency4/5

Three tools follow a clean verb_noun snake_case pattern (derive_route_shard, parse_envelope, verify_envelope) with consistent imperative verbs. The fourth, published_vector, is a noun phrase rather than a verb_phrase, a minor deviation from the otherwise predictable convention.

Tool Count4/5

Four tools is a tight, well-scoped surface for a narrow cryptographic verification domain (derive, parse, verify, plus a self-test vector). It leans slightly thin, but each tool clearly earns its place with no redundancy.

Completeness4/5

The surface covers the full verify-a-lifecycle: deriving the intent shard, decoding the envelope, verifying it, and a published conformance vector for offline self-testing. The main gap is the absence of an encode/build or key-generation counterpart, though that may be intentionally out of scope for a stateless verifier.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

AccordTrace A
io.github.Kosta1985
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Security AI & Machine Learning
91
Trust Gate A
io.github.CWNApps
Post-quantum, tamper-evident receipts for agent actions. Ed25519 + ML-DSA-65, offline verify.
Security Autonomous Agents
72
hyperframesrender-mcp
com.clauxel.hyperframesrender
A paid remote MCP for HyperFrames, built to return verdicts, receipts, usage logs, and audit-ready J
Monitoring Virtualization Security
2
CrossingKey MCP B
com.crossingkeyintelligence
Agent-native MCP for governed commerce, x402 payments, paid capabilities, and verifiable receipts.
Payments & Billing Autonomous Agents
281

Related MCP Servers

fallvault-mcp
Security
sjgant80-hub
A
license
Not graded
quality
D
maintenance
MCP server for sovereign AES-256-GCM backup encryption and decryption. Enables encrypting, decrypting, verifying, and scoring passphrases with zero network calls.
Updated 3 months ago (2026-07-09 15:41 UTC)
MIT
vantic-mcpofficial
Security Autonomous Agents
vanticlabs
A
license
Not graded
quality
B
maintenance
Enables MCP hosts to verify agent spending mandates and receipts, providing stateless tools for authorization, chain verification, credential verification, and DID resolution.
Updated 3 months ago (2026-07-31 14:50 UTC)
Apache 2.0
technocore
Autonomous Agents Security
noncesense67-spec
A
license
Not graded
quality
B
maintenance
Provides MCP tools for interacting with the Technocore agent protocol, including signed messaging, nonce management, DID verification, end-to-end encrypted communication, and untrusted data fencing.
Updated 18 days ago (2026-10-01 05:46 UTC)
12 npm
Apache 2.0
mneme-ai
Autonomous Agents Knowledge & Memory Security
patsa2561-art
A
license
Not graded
quality
B
maintenance
Enables AI agents to operate through a local, signed boundary that blocks prompt injection and secret leakage, verifies outputs, preserves cross-session memory, and provides offline-verifiable receipts. It also exposes 900+ MCP tools for discoverable agent actions.
Updated 4 months ago (2026-07-01 02:16 UTC)
7
MIT

iqa-mcp

Why

Install

Tools

Try it in thirty seconds

Self-test

Design invariants

What this is not

Status

Sister repositories

Public record

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

vantic-mcpofficial