Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Agent Compliance Passport MCP verify the compliance passport of did:meok:my-agent"
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.
In a world of unverifiable AI claims, we sell the auditor's math.
The Agent Compliance Passport is a single signed, portable credential an AI agent carries proving it is compliant with EU AI Act, GDPR, HIPAA, and nine other frameworks. Any other agent verifies the passport offline, in microseconds, with no network and no phone-home before transacting.
This is the Mavis 7-file MCP server that issues, verifies, and exchanges those passports.
Every AI vendor ships a "trust center." Every AI agent makes compliance claims. None of it is cryptographically verifiable. Two agents transacting in 2026 still exchange Word documents and Slack screenshots.
The Agent Compliance Passport fixes this:
Portable — one signed JSON blob travels with the agent.
Verifiable offline — the public key is enough. No API call. No vendor lock-in. The verifier does the math, not the vendor.
Structured — a per-article claim status across 11 frameworks, with a machine-readable schema for the whole regulation set.
Cheap to issue — a +1 cent per passport cost. Free for the first
1,000 / month.
A2A-ready — the exchange_credentials tool is the handshake.
Positioning (from BREAKTHROUGH_INSIGHTS.md):
The Anti-Billion-Dollar-Whale. The big platforms will sell you "AI compliance" at $500K/yr. We sell the math the auditor needs to check the claim, for free, open-sourced, and runnable on a Raspberry Pi.
Related MCP server: TrustAtom MCP Server
git clone https://github.com/meok-ai/meok-compliance-passport-mcp
cd meok-compliance-passport-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e .The package depends on mcp>=0.9.0, pydantic>=2.0, cryptography>=42.0,
and httpx>=0.25.
Issue a passport, verify it offline, exchange it in a handshake. Six lines.
from meok_compliance_passport_mcp.server import (
issue_passport, verify_passport, exchange_credentials,
)
passport = issue_passport( # signed, 365-day, Ed25519
agent_id="did:meok:my-agent-001",
agent_type="llm_agent",
frameworks=["eu_ai_act", "gdpr"],
claims={"eu_ai_act": {"article_9": "compliant"}},
)
print(verify_passport(passport)) # {'valid': True, ...} -- OFFLINE
print(exchange_credentials(
passport, counterparty_id="did:meok:peer-007"
)) # {'authorized': True, 'scope': [...], ...}issue_passport(agent_id, agent_type, frameworks, claims) -> PassportSigns and returns a Passport. The signature is Ed25519 over a canonical
(sorted-keys, no-whitespace) JSON encoding of every field except the
signature itself.
Field | Type | Description |
| str |
|
| str | one of |
| list | subset of 11 supported frameworks |
| dict |
|
| str |
|
| str | ISO 8601 UTC ( |
| str | ISO 8601 UTC, default |
| str | 32-byte Ed25519 public key, hex |
| str | 64-byte Ed25519 signature, hex |
| str | Key ID, derived from public key |
verify_passport(passport) -> {valid, issuer, expires_at, frameworks_covered}100% offline. No network. Reconstructs the canonical payload from the
passport, runs the Ed25519 verification, and checks the expiry. Returns
valid: False with a reason on any failure (bad signature, malformed
key, expired, etc.).
This is the auditor's math. The math is open, the math is portable, and the math runs on a Raspberry Pi in microseconds.
exchange_credentials(agent_id_passport, counterparty_id) -> {authorized, scope, expires}The A2A handshake. Two agents meet, each presents its passport, and the
verifier produces a short-lived authorization token whose scope is the
intersection of the frameworks the presented passport covers. Default
token TTL: 60 seconds.
Article 50 of the EU AI Act imposes transparency obligations on providers and deployers of AI systems that interact with natural persons. Sub-paragraphs cover:
Informing users they are interacting with an AI system (Art. 50(1))
Disclosure of emotion-recognition / biometric categorisation (Art. 50(3))
Deepfake disclosure (Art. 50(4))
AI-generated content marking (Art. 50(4))
The passport has first-class support for ai_act_article_50 as one of its
eleven frameworks. An agent's claims map can carry per-sub-article status
(e.g. transparency_50: compliant) and the verifier enforces it just like
any other framework.
This server is the keystone companion to meok-compliance-gateway, which provides the underlying zero-knowledge and signature machinery. The passport adds the agent identity and the portable claim. Together they are the auditor's math.
The full verification path uses only the public key, the signature, and
the fields in the passport. No phone-home. No meok.ai API call.
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
from cryptography.exceptions import InvalidSignature
from meok_compliance_passport_mcp.server import Passport, ISSUER_PUBLIC_KEY_HEX
def verify_with_public_key(passport: Passport) -> bool:
pub = Ed25519PublicKey.from_public_bytes(bytes.fromhex(passport.public_key))
payload = passport.canonical_payload()
try:
pub.verify(bytes.fromhex(passport.signature), payload)
return True
except InvalidSignature:
return FalseYou can publish ISSUER_PUBLIC_KEY_HEX anywhere — on-chain, in DNS, in
a transparency log — and any third party can verify any passport without
ever talking to us.
The exchange_credentials tool is the production primitive for the
Agent-to-Agent (A2A) handshake. In a typical flow:
Agent A calls issue_passport(...) once, at startup.
Agent B does the same.
When A and B meet, each presents its passport.
Each calls verify_passport(peer_passport) — offline.
Each calls exchange_credentials(peer_passport, my_did).
The resulting scope is the agreed regulatory surface for the
transaction.
Token TTL is 60 seconds by default, so this is meant to be re-run on every meaningful interaction, not cached.
Key | Framework |
| EU AI Act (high-risk system obligations) |
| EU AI Act Article 50 (transparency) |
| EU General Data Protection Regulation |
| US Health Insurance Portability and Accountability Act |
| AICPA SOC 2 Trust Services Criteria |
| ISO/IEC 42001 AI Management System |
| NIST AI Risk Management Framework |
| EU Cyber Resilience Act |
| EU Digital Operational Resilience Act |
| EU NIS2 Directive |
| GPAI Code of Practice |
Per-article schema hints for each framework are exported as
REGULATION_SCHEMA in server.py. They are not enforced at issue time —
they are a documentation surface for downstream tooling (a UI, a
gap-analysis engine, a regulator's report generator).
Tier | Quota | Price |
Free | 1,000 passports / mo | $0 |
Pro | 100,000 passports / mo | $499 / mo |
Enterprise | Unlimited | Talk to us |
Issue cost is on the order of a fraction of a cent — the bottleneck is
signature verification, which is +1 ms per check, offline. The
exchange_credentials handshake is free for both parties.
The package exposes a console script:
meok-compliance-passport-mcpThis speaks the Model Context Protocol over stdio. To wire it into an MCP
host (Claude Desktop, Cursor, etc.), add it to your mcp.json:
{
"mcpServers": {
"meok-compliance-passport": {
"command": "meok-compliance-passport-mcp",
"args": []
}
}
}Once wired, the three tools above are callable as native MCP tools.
The bundled private key is deterministic and public. It exists so
the demo works out of the box and so anyone can reproduce the
signature for verification. Replace it with the meok-compliance-gateway
KMS in production. The constant TEST_PRIVATE_KEY in server.py
is the single line to swap.
Verification is intentionally offline. The server never makes a
network call during verify_passport or exchange_credentials.
exchange_credentials re-runs verify_passport internally. There
is no fast path that skips signature checking.
MIT. See LICENSE.
© 2026 meok.ai. The auditor's math is open.
A2A handshake. Two agents present their passports and negotiate a short-lived authorization token whose scope is the intersection of the frameworks the presented passport covers. Returns {authorized, scope, expires}.
| Name | Required | Description | Default |
|---|---|---|---|
| counterparty_id | Yes | DID of the counterparty agent. | |
| agent_id_passport | Yes | The Passport presented by the calling agent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool involves negotiation, returns a token with intersection scope, and lists exact return fields. It does not explain potential failures or side effects, but the core behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured sentences. The first sentence explains the action, the second states the return format. No unnecessary words; every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by specifying return fields. It covers the main use case but could mention prerequisites (e.g., having a valid passport) or error states. Overall, it is sufficiently complete for a tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters. The description adds value by explaining the negotiation process and output format, though it slightly implies both agents submit passports while the schema only expects one. This minor inconsistency is offset by the useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an A2A handshake where two agents exchange passports to negotiate a short-lived authorization token. It uses specific verbs ('present', 'negotiate') and resources ('passports', 'authorization token'), and the purpose is distinct from siblings issue_passport and verify_passport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates the tool is used when an agent needs to obtain a token from a counterparty based on passport verification. It does not explicitly state when not to use it or provide alternatives, but the context of sibling tools makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue a signed Agent Compliance Passport. The passport is a portable Ed25519-signed credential carrying the agent's DID, type, the compliance frameworks it asserts conformance to, and per-article claim status. Valid for 365 days by default.
| Name | Required | Description | Default |
|---|---|---|---|
| claims | No | Map of framework -> article -> status (compliant | in_review | self_declared | remediation_in_progress | non_compliant). | |
| agent_id | No | DID-style identifier. Auto-generated if omitted. | |
| agent_type | No | llm_agent | |
| frameworks | No | Frameworks this passport asserts. Defaults to all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It describes the passport (Ed25519-signed, 365-day validity) but does not disclose side effects, idempotency, rate limits, or whether issuance stores the passport. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no unnecessary words. Every sentence adds value, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (0 required), no output schema, and nested objects, the description explains the passport's components and default validity. It is mostly complete, though could clarify post-issuance behavior (e.g., storage vs. return).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 properties have descriptions). The description adds context about passport structure and default validity but does not significantly enhance parameter understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool issues a signed Agent Compliance Passport and explains its purpose. It distinguishes from siblings (exchange_credentials, verify_passport) by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (issuing passports) but does not explicitly state when to use this tool versus alternatives like exchange_credentials or verify_passport. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a passport offline. Checks the Ed25519 signature and expiry. Returns {valid, issuer, expires_at, frameworks_covered}. No network is required - this is the auditor's math.
| Name | Required | Description | Default |
|---|---|---|---|
| passport | Yes | The Passport object to verify. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cryptographic check, expiry verification, return structure, and offline nature (no network required). No destructive or authorization hints are needed for a read-only verification tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence states the core purpose, the second adds key details (checks, return, context). Perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing details on failure behavior (throws error vs. returns invalid flag) and passport object structure. Simple tool but lacks completeness for an agent to construct the input correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds no meaning beyond the schema's minimal description. The nested passport object lacks documentation of its required fields (e.g., signature, issuer), leaving the agent under-informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (verify a passport offline), specific checks (Ed25519 signature and expiry), and return value structure. It distinguishes from siblings (exchange_credentials, issue_passport) by emphasizing offline verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for offline verification, but does not explicitly state when not to use it or mention alternative tools. No prerequisites or constraints are provided beyond offline context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0exchange_credentialsissue_passportverify_passportEach tool has a clearly distinct purpose: issuing passports, verifying them offline, and exchanging credentials for authorization. No overlap or ambiguity exists.
All tool names follow a consistent verb_noun pattern with snake_case (exchange_credentials, issue_passport, verify_passport), making them predictable and easy to understand.
Three tools for a passport system is reasonable, covering the core operations of issuance, verification, and credential exchange. However, it is slightly minimal for a full lifecycle.
The set covers creation, offline verification, and A2A handshake, but notably lacks passport revocation or listing capabilities, which are common in such systems.
Command your AI agents: verifiable passports, credential injection, full audit, revoke in 60s.
First A2A registry where AI agents discover & transact with compliance firms - audits, permits.
Register every AI agent, log every action, prove it. EU AI Act compliance built in.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CSOAI-ORG/meok-compliance-passport-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
