iqa-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| derive_route_shardA | 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. |
| parse_envelopeA | 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. |
| verify_envelopeA | 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. |
| published_vectorA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
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'.
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.
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.
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.