Start here — what iqa-mcp is, and where it's being discussed

iqa-mcp is a small, Apache-2.0 MCP server exposing four tools for offline-verifiable attestation of agent/tool interactions: derive_route_shard (intent-address derivation from any authority, no registry), parse_envelope (128-byte AE-128 attestation envelope), verify_envelope (constant-time HMAC-SHA256 full-frame verification + lease check, fail-closed), and published_vector (conformance test vectors for byte-level self-checks).

The specification is draft-li-rttp-iqa-addressing (IETF Independent Submission, in review); the reference implementation is iqa-org v1.3.1 (PyPI / npm / crates.io). Sibling discussions live in the rttp and iqa-org repos — addressing design questions belong there; tooling and integration questions belong here.

To ground the discussion, we have submitted the same complementary-evidence-layer proposal to seven ecosystems, each adapted to that project's actual feature set and etiquette — gateway/agent maintainers are the audience this tool is built for:

• alibaba/UnifiedModel — Discussion #111
• docker/mcp-gateway — Discussion #596
• TheLunarCompany/lunar — Discussion #86
• aliyun/ai-agent-handbook — Issue #15
• uber/ADR — Issue #163
• cloudflare/agents — Discussion #2534
• higress-group/higress — Discussion #5037

Open threads we'd especially like input on: whether the four-tool split is right, which integrations to sketch first (gateway plugins, agent subclasses, sensor pipelines), and anything in the envelope handling that would block real deployments. Critical feedback welcome — the spec is in review, not carved in stone.