This server compiles ISO 20022 audit evidence into sealed, tamper-evident packs, with optional Ed25519 signing and markdown reports. It operates as a read-only, local, idempotent, and closed-world process, but can optionally be exposed via authenticated HTTP (OAuth 2.1 or bearer token).
Build evidence packs: Combine readiness findings, remediation results, simulated bank responses, and metadata into a graded (A/B/C/F) pack.
Seal packs: Compute a deterministic SHA-256 digest for tamper evidence.
Verify seals: Recompute and compare a pack's digest to detect changes.
Render reports: Generate human-readable markdown compliance reports from packs.
Sign packs: Apply an Ed25519 digital signature using a configured private key for authenticity.
Verify signatures: Validate a detached Ed25519 signature against a provided public key.
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., "@iso20022-evidence-pack-mcp Seal a readiness evidence pack with findings and simulated bank responses."
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.
A fully local, closed-world Model Context Protocol (MCP) server that
compiles ISO 20022 readiness findings, remediation diffs, and simulated bank
responses into one sealed, exportable audit evidence pack. It is the audit
and certification sibling of
iso20022-readiness-suite-mcp
(which produces those findings) and
iso20022-bank-profile-mcp
in the ISO 20022 MCP Suite.
Tamper-evident by construction. The pack's seal is a deterministic SHA-256 digest over the pack's canonical JSON (the
digestfield excluded). Re-sealing identical content yields the identical digest, and changing any field breaks verification — so an auditor can detect undetected change. There is no network surface, no sub-servers, and no XML: every tool is a pure, local, deterministic transform over the JSON structures it is handed. v0.0.2, stdio transport (plus an optional authenticated HTTP transport), 6 tools including Ed25519 pack signing, Python 3.10+.
Related MCP server: compliance-aiops
The Model Context Protocol (MCP) is an open standard that lets AI agents
and assistants discover and call external tools in a uniform way.
iso20022-evidence-pack-mcp is the audit/certification end of the ISO 20022
MCP Suite: it takes the results that
iso20022-readiness-suite-mcp
produces — a readiness score with findings, an optional remediation result,
and any simulated bank responses — and folds them into one strongly-typed,
graded, sealed evidence pack that can be exported, verified, and rendered
as a compliance report.
An EvidencePack folds three loosely-typed inputs into one self-describing
document: a readiness result (message type, validity, score, findings), an
optional remediation result (fixes applied, residual findings), and any
simulated bank responses (accepted / rejected statuses). The pack is graded
(A / B / C / F from the readiness score) and sealed.
The seal is the point: it is a deterministic SHA-256 digest computed over the
pack's canonical JSON form (sorted keys, tight separators, with the digest
field itself excluded). Sealing the same content always yields the same value,
which is exactly what makes the pack tamper-evident — recomputing the seal
and comparing it to the one carried in the pack tells an auditor whether any
byte changed since it was sealed.
Every tool returns typed, JSON-serialisable data; on any failure — bad input,
unparseable JSON, a shape that does not match the pack schema — it returns an
{"error": ...} payload rather than raising into the client transport.
Website: https://sebastienrousseau.github.io/iso20022-evidence-pack-mcp/
Source code: https://github.com/sebastienrousseau/iso20022-evidence-pack-mcp
Bug reports: https://github.com/sebastienrousseau/iso20022-evidence-pack-mcp/issues
flowchart LR
A["iso20022-readiness-suite-mcp<br/>(readiness + remediation + simulation)"] -->|JSON results| B["iso20022-evidence-pack-mcp<br/>(build + seal)"]
B -->|sealed pack + digest| C["verify_seal<br/>(tamper check)"]
B -->|markdown report| D["render_markdown<br/>(compliance report)"]The server is fully local and closed-world: it holds no state, opens no sockets, and spawns no processes. You hand it JSON, it hands you a sealed pack.
iso20022-evidence-pack-mcp is the audit and certification server of a set
of coordinated, vendor-neutral MCP servers for the ISO 20022 migration.
Dependency ranges are kept aligned across the suite, so the servers co-install
cleanly in a single Python environment.
Server | Scope | Install |
Orchestration gateway: readiness scoring, remediation, clearing-profile linting, and bank-response simulation — the results this server folds in |
| |
Manage and serve bank-specific clearing profiles / rule packs as a first-class server |
| |
ISO 20022 postal-address classification, assessment, and remediation for the Nov 2026 structured-address cliff |
| |
Unified gateway meta-tools ( |
| |
ISO 20022 camt.05x bank statements: parse, validate, filter, reverse; MT94x migration; CBPR+ readiness |
| |
Generate & validate ISO 20022 pain.001 payment-initiation files (v03–v12, pain.008, SEPA) with rulebook checks |
| |
Reconcile ISO 20022 payments and statements; match initiations to their bank-side outcomes |
| |
Parse bank statements (MT940/MT942 and camt) into structured, agent-friendly data |
|
Where the readiness suite decides whether a payment is ready and fixes it, this server certifies the outcome: it turns those findings into a sealed, auditable artifact.
iso20022-evidence-pack-mcp runs on macOS, Linux, and Windows and requires
Python 3.10+ and pip. It pulls in only the MCP SDK and pydantic
automatically — there are no other runtime dependencies.
python -m pip install iso20022-evidence-pack-mcppython -m venv venv
source venv/bin/activate # macOS/Linux
venv\Scripts\activate # Windows
python -m pip install -U iso20022-evidence-pack-mcpFor the 10-minute install → MCP client config → first conversation tutorial,
see docs/quickstart.md.
Launch the server over stdio (the FastMCP default transport):
iso20022-evidence-pack-mcpRegister it with any MCP client (e.g. Claude Desktop) by adding it to the client's configuration:
{
"mcpServers": {
"iso20022-evidence-pack": { "command": "iso20022-evidence-pack-mcp" }
}
}The command speaks MCP on stdin/stdout — it is meant to be launched by an MCP client, not used interactively. The agent can then call the tools below.
You can also invoke the tools in-process — without a transport — straight through the FastMCP instance. This mirrors what an agent receives over stdio. The example below builds a sealed pack from a small readiness result, then shows the seal round-tripping (and breaking on tamper):
import asyncio
import json
from iso20022_evidence_pack_mcp import server
async def main() -> None:
async def call(name, args):
result = await server.server.call_tool(name, args)
# mcp 2.x returns a CallToolResult (read .content); 1.x
# returns the content list, or a (content, meta) tuple.
content = getattr(result, "content", None)
if content is None:
content = result[0] if isinstance(result, tuple) else result
return content[0].text if content else ""
readiness = json.dumps({
"message_type": "pacs.008.001.08",
"is_valid": True,
"readiness_score": 92,
"structural_errors": [],
"profile_findings": [],
})
# Fold the readiness result into a graded, sealed evidence pack.
built = json.loads(await call("build_evidence_pack",
{"readiness_content": readiness}))
pack, digest = built["pack"], built["digest"]
print(pack["grade"], digest) # -> A sha256:01388e3dfbea7d21...
# The seal round-trips: re-verifying the pack against its digest holds.
ok = json.loads(await call("verify_seal", {
"pack_content": json.dumps(pack),
"expected_digest": digest,
}))
print(ok["verified"]) # -> True
# Change any field and verification against the old digest fails.
tampered = {**pack, "grade": "F"}
bad = json.loads(await call("verify_seal", {
"pack_content": json.dumps(tampered),
"expected_digest": digest,
}))
print(bad["verified"]) # -> False
asyncio.run(main())All tools are read-only, local, idempotent, and closed-world. They return
JSON-serialisable data; on a validation or shape error they return an
{"error": ...} payload rather than raising.
build_evidence_pack — Fold a readiness result (plus an optional remediation result, optional simulated bank responses, and free-form metadata) into a graded, sealed evidence pack; returns the pack, its digest, and a rendered markdown report.
seal_pack — Compute the deterministic SHA-256 seal for an evidence pack (raw JSON).
verify_seal — Recompute a pack's seal and compare it to an expected digest.
render_markdown — Render an evidence pack as a markdown compliance report.
sign_pack — Sign a pack's canonical bytes with the operator's Ed25519 key (configured via the environment); returns the base64 detached signature, the PEM public key, and a key_id. Fails with EP_NO_SIGNING_KEY when no key is configured. See Signing evidence packs.
verify_pack_signature — Verify a detached Ed25519 signature over a pack's canonical bytes against a public key passed as an argument; returns verified and key_id.
The server speaks stdio by default — launched by a local MCP client, one process per operator, with no network surface and no authentication. For shared, multi-tenant deployments, v0.0.2 adds an optional streamable-HTTP transport:
iso20022-evidence-pack-mcp --transport=http --bind=127.0.0.1:8080--bind defaults to loopback 127.0.0.1:8080, so exposing the server (e.g.
--bind=0.0.0.0:8080) is an explicit opt-in. Starting the HTTP transport with
no auth configured is refused rather than serving an unauthenticated endpoint.
Two auth modes apply, strongest first:
OAuth 2.1 resource server (RFC 9728) — set the ISO20022_EVIDENCE_PACK_OAUTH_*
variables:
Variable | Required | Meaning |
| yes | Authorization-server issuer; the JWT |
| yes | This server's canonical resource URI (RFC 8707); the JWT |
| no | JWKS document URL (defaults to |
| no | Space-separated scopes every token must carry. |
Every request must present Authorization: Bearer <jwt>; the JWT is validated
against the JWKS (iss / aud / exp / nbf and any required scopes).
Protected-resource metadata is served at
/.well-known/oauth-protected-resource; failures are rejected 401 (or 403
for insufficient scope) with a WWW-Authenticate challenge.
Static dev-mode bearer token — set ISO20022_EVIDENCE_PACK_TOKEN to a
non-empty secret. Every request must then send Authorization: Bearer <secret>.
This is a single shared secret with no expiry and no scopes; use OAuth 2.1 in
production.
HTTP callers may also send an optional X-MCP-Tenant header, forwarded into a
tool-visible request context for multi-tenant scoping. The HTTP transport pulls
in extra dependencies (pyjwt[crypto], httpx, starlette, uvicorn); the
default stdio transport needs none of them. See
docs/transport.md for the full reference.
A pack's seal proves integrity — the content has not changed. A signature proves authenticity — a specific key attests to that content. v0.0.2 adds Ed25519 signing via two tools:
sign_pack signs the pack's canonical bytes — the exact same
serialization the seal digests, with the digest field excluded. Because the
signature covers the sealed content, it stays valid if only the digest
field changes but breaks if any sealed field changes. It returns the
base64 detached signature, algorithm "ed25519", the PEM public key, and a
key_id (ed25519:<16 hex>).
verify_pack_signature verifies a detached signature over a pack's canonical
bytes against a public key passed as a tool argument. Public keys are safe
to pass across the tool boundary; it returns verified and key_id.
The Ed25519 private key is configured by the operator at launch, via the environment:
ISO20022_EVIDENCE_PACK_SIGNING_KEY — the PEM private key inline, or
ISO20022_EVIDENCE_PACK_SIGNING_KEY_FILE — a path to a PEM key file.
The private key never crosses the MCP tool boundary. The server never
generates or persists private keys — key material is generated and custodied by
the operator, ideally in an HSM/KMS. With no key configured, sign_pack returns
EP_NO_SIGNING_KEY; a malformed key or signature returns EP_INVALID_INPUT.
Signing with an operator-supplied key is available today. Keyless (sigstore) and PKI signing with a verification trust root remain roadmap items.
Runnable, self-contained examples live in examples/. Each script
drives the public tools directly and needs no network or sub-server:
python examples/01_build_full_pack.pySee examples/README.md for the full catalogue, or run
them all with make examples.
The readiness suite and the evidence-pack server form a two-stage pipeline:
Readiness → results.
iso20022-readiness-suite-mcp
runs run_readiness_check (score + findings), remediate_payload
(automated fixes), and simulate_bank_response (a mocked pacs.002 outcome).
Each returns typed JSON.
Results → sealed pack. You hand those JSON results to
build_evidence_pack here. It normalises them into a strongly-typed pack,
grades the readiness score (A/B/C/F), and seals the whole thing with a
deterministic SHA-256 digest. verify_seal later proves the pack is
unchanged; render_markdown turns it into a human-readable compliance
report.
Because the seal is deterministic, the same inputs always produce the same digest — so a pack built today and re-sealed next quarter is provably the same pack, or provably not. The two servers stay decoupled: the readiness suite knows nothing about sealing, and this server knows nothing about how the findings were produced — it only folds and certifies them.
The server is open core: building, sealing, verifying, and rendering packs are open source and always available. Higher-tier capabilities that turn a tamper-evident pack into an authenticatable, durably archived artifact are commercial add-ons on the roadmap.
Capability | Tier |
Pack assembly + grading ( | Open Source |
Deterministic SHA-256 sealing + verification ( | Open Source |
Markdown compliance reports ( | Open Source |
Ed25519 signing with an operator key ( | Open Source |
Authenticated HTTP transport (OAuth 2.1 / RFC 9728, multi-tenant) | Open Source |
Keyless (sigstore) / PKI signing + verification trust root | Paid / Roadmap |
Long-term evidence storage + export formats (PDF/A, WORM archives) | Paid / Roadmap |
White-label reports + premium entitlement gating | Paid / Roadmap |
Nothing in the open-source tier is time-limited or feature-gated: the seal and the reports are fully functional today.
The seal is an integrity digest, not a cryptographic signature. It proves that a pack has not changed since it was sealed (tamper-evidence); it does not prove who produced the pack (authenticity). Anyone who can build a pack can also compute a valid seal for it, so a seal is a checksum, not a proof of origin.
Authenticity — binding a pack to a specific key — is what
sign_pack / verify_pack_signature add on top of
the seal: an Ed25519 signature over the pack's canonical bytes attests that the
holder of the operator's key produced that content. The seal and the signature
are complementary: the seal is integrity, the signature is authenticity. Note
that a signature is only as trustworthy as your provenance for the public key —
keyless (sigstore) / PKI signing with a verification trust root remains a
roadmap item (see ROADMAP.md). If you have configured no
signing key, treat a sealed-but-unsigned pack as integrity-checked only:
transmit and store it over channels you already trust, and do not represent it
as a signed one. See SECURITY.md for the full threat-model
note.
You have no MCP client. This server only makes sense paired with an MCP-aware host (Claude Desktop, the IDE plugins, an agent framework).
You need the readiness findings themselves. This server certifies
results; it does not produce them. Run
iso20022-readiness-suite-mcp
to score, remediate, and simulate first, then fold its output in here.
You need keyless / PKI signatures against a public trust root. The seal is a tamper-evidence digest, not a signature (see Seal vs signature). Ed25519 signing with an operator-supplied key ships in v0.0.2 (Signing evidence packs), but keyless (sigstore) / PKI signing with a verification trust root remains on the roadmap.
You want a zero-dependency network service. The default transport is stdio — one process per operator, launched by the client, no network surface. An optional authenticated HTTP transport (OAuth 2.1 / RFC 9728) ships in v0.0.2 (HTTP transport & authentication) for shared, multi-tenant deployments, but it pulls in extra dependencies and must be explicitly enabled.
You need streaming responses. Tool calls return whole values, not streams.
iso20022-evidence-pack-mcp uses Poetry and mise.
git clone https://github.com/sebastienrousseau/iso20022-evidence-pack-mcp.git && cd iso20022-evidence-pack-mcp
mise install
poetry install
poetry shellA Makefile orchestrates the quality gates (kept in lockstep with CI):
make check # all gates (REQUIRED before commit): lint + type-check + test
make test # pytest (100% line + branch coverage)
make lint # ruff + black
make type-check # mypy --strict
make security # bandit
make examples # run every examples/*.py end to endiso20022-evidence-pack-mcp returns errors as data — every tool catches the
documented validation and value errors and returns an {"error": ...}
envelope; it never propagates raw exceptions to the MCP client. Over the default
stdio transport the server has no network surface, spawns no sub-processes, and
parses no XML — its whole attacker-reachable surface is JSON parsed with the
standard library and validated against pydantic models. The optional HTTP
transport is off by default and, when enabled, refuses to start without OAuth 2.1
(RFC 9728) or a static dev-mode bearer token (see
HTTP transport & authentication). The pack
seal is a tamper-evidence digest, not a signature; Ed25519 signing
(sign_pack) adds authenticity on top (see
Seal vs signature). Reporting
practice, supported versions, the seal threat-model note, and the full
supply-chain posture (SLSA L3 provenance, PEP 740 attestations, SBOMs, and the
NIST SP 800-218 SSDF practice mapping) are documented in
SECURITY.md. Vulnerabilities go via GitHub Private
Vulnerability Reporting, not public issues.
README.md — this file
CHANGELOG.md — release notes
SECURITY.md — disclosure + supported versions + seal threat model
SUPPORT.md — how to get help
ROADMAP.md — what's next (keyless/PKI signing, long-term storage, premium entitlement)
MAINTAINERS.md — who can merge
docs/quickstart.md — 10-minute install → first conversation
docs/evidence-packs.md — the pack schema, the SHA-256 sealing model, Ed25519 signing, and the readiness → evidence pipeline
docs/transport.md — the optional HTTP transport and OAuth 2.1 (RFC 9728) authentication
glama.json — Glama directory manifest
mcp-name: io.github.sebastienrousseau/iso20022-evidence-pack-mcp
Licensed under the Apache License, Version 2.0. Any contribution submitted for inclusion shall be licensed as above, without additional terms.
Contributions are welcome — see the contributing instructions. Thanks to all contributors.
Built alongside the servers of the ISO 20022 MCP Suite and the Model Context Protocol Python SDK.
Fold readiness, remediation, and simulations into a sealed pack.
Args:
readiness_content: A readiness result, as JSON text.
remediation_content: An optional remediation result, as JSON text.
simulation_content: An optional JSON array of simulated responses.
metadata: Free-form audit metadata (institution, reference, ...).
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | Free-form audit metadata. | |
| readiness_content | Yes | A readiness result as raw JSON text. | |
| simulation_content | No | Optional simulated-responses JSON. | |
| remediation_content | No | Optional remediation JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Fold into a sealed pack' implying creation, but annotations declare readOnlyHint=true and destructiveHint=false, contradicting the implication of a side effect. No additional behavioral traits disclosed beyond the contradiction.
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 single-sentence front-loading is good, but the Args section is redundant with the schema, adding unnecessary length.
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?
While the description explains the tool's purpose and inputs, it omits description of the return value (though output schema exists). The contradiction with annotations undermines completeness. Adequate but with gaps.
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 100%, so baseline is 3. The description's Args block mirrors the schema without adding new semantics, formats, or constraints.
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 verb 'Fold into' and resource 'sealed pack', listing the three content types. It is specific but does not explicitly distinguish from sibling tools like seal_pack or sign_pack.
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?
No guidance on when to use this tool vs alternatives such as seal_pack, sign_pack, or render_markdown. The description implies usage for combining specific content types but does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a signed evidence pack to Amazon S3.
**Requires the ``[aws]`` extra** (``pip install
iso20022-evidence-pack-mcp[aws]``) and **reaches AWS S3 over the
network** -- unlike the closed-world tools, this one has a network
surface. Only the ``s3://`` scheme is supported; ``gs://`` / ``az://``
return a clear error. Returns the object's ``bucket``, ``key``, and
``etag``.
Args:
signed_pack_json: The signed pack to upload, as JSON text.
s3_uri: The destination, of the form ``s3://bucket/key``.
| Name | Required | Description | Default |
|---|---|---|---|
| s3_uri | Yes | Destination of the form s3://bucket/key. | |
| signed_pack_json | Yes | A signed evidence pack as raw JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by revealing that the tool reaches AWS S3 over the network, requires an optional package extra, restricts supported URI schemes, returns a clear error for unsupported ones, and returns bucket, key, and etag. This is meaningful behavioral context that the annotations alone do not provide.
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 well-organized, front-loads the core action, and uses short sections for requirements, behavior, return values, and arguments. Every sentence contributes useful information without excessive padding.
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 its two required parameters, full schema coverage, and existing output schema, the description covers the important nuance: network access, installation requirement, URI scheme restrictions, and returned fields. It is sufficiently complete for an agent to select and invoke the tool 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 percent and the Args section mirrors the schema descriptions closely. It adds a bit of plain-language context such as 'signed pack to upload' and the destination form, but does not substantially enrich parameter semantics beyond what the input schema already provides.
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 uploads a signed evidence pack to Amazon S3, with a specific destination scope (s3://). It distinguishes itself from sibling tools like sign_pack and verify_seal by identifying its unique network/upload function.
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?
It explicitly explains that the java [aws] package extra is required, that this tool has a network surface unlike the closed-world tools, and that only s3:// is supported with gs:// / az:// returning clear errors. It could slightly improve by naming specific sibling alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an evidence pack as a markdown compliance report.
Args:
pack_content: The evidence pack to render, as JSON text.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_content | Yes | An evidence pack as raw JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds context that the output is a markdown compliance report, which is useful beyond annotation hints. No contradiction with annotations.
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 extremely concise with only two sentences and an Args line, front-loading the purpose. Every sentence adds value, and there is no redundancy or fluff.
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 the simple single-parameter schema, comprehensive annotations, and presence of an output schema, the description provides sufficient context. It explains the input and output format, though it could optionally mention that the tool does not modify state (already covered by annotations).
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 100% with a clear description of 'pack_content' as 'An evidence pack as raw JSON text.' The description repeats this without adding new semantics, so it does not significantly enhance parameter understanding beyond the schema.
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 specifies the action ('Render'), the resource ('an evidence pack'), and the output format ('as a markdown compliance report'). It distinguishes this tool from siblings like build_evidence_pack (building) and seal_pack (sealing) by focusing on the rendering step.
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 when you have an evidence pack and need a markdown report, but it does not explicitly state when to use this tool versus alternatives like build_evidence_pack or sign_pack. No exclusions or 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.
Compute the deterministic SHA-256 seal for an evidence pack.
Args:
pack_content: The evidence pack to seal, as JSON text.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_content | Yes | An evidence pack as raw JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the seal is computed using SHA-256 and is deterministic, reinforcing idempotency and providing algorithmic detail. No contradictions with annotations.
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 extremely concise, consisting of two short sentences. It front-loads the core purpose without any filler or redundant explanation. Every sentence adds unique value.
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?
For a simple tool with one parameter and an output schema, the description is adequate but minimal. It does not explain what a 'seal' is, the output format, or how it fits into the pack workflow. The existence of an output schema mitigates the lack of return value details.
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% and both schema and description describe 'pack_content' identically as 'an evidence pack as raw JSON text'. The description adds no new semantic meaning beyond the schema, earning the baseline score.
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 computes a deterministic SHA-256 seal for an evidence pack, specifying the verb 'compute', resource 'evidence pack', and algorithm 'SHA-256'. This distinguishes it from siblings like 'verify_seal' (verification) and 'build_evidence_pack' (construction).
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 provides no explicit guidance on when to use this tool versus alternatives like 'verify_seal' or 'build_evidence_pack'. It only states what the tool does, forcing the agent to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign a pack's canonical content with the server's Ed25519 key.
The private key is configured by the operator via the environment (see
:mod:`iso20022_evidence_pack_mcp.signing`); it never crosses the tool
boundary. Returns the detached signature, the public key, and a key id;
fails with ``EP_NO_SIGNING_KEY`` when no key is configured.
Args:
pack_content: The evidence pack to sign, as JSON text.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_content | Yes | An evidence pack as raw JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: the private key is configured via environment, never crosses boundary, returns detached signature/public key/key id, and fails with EP_NO_SIGNING_KEY. No contradiction with annotations.
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 concise, with a clear one-line summary, followed by essential operational details. No extraneous sentences. The Args section is well-structured.
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?
For a simple tool with one parameter, strong annotations, and an output schema, the description covers key aspects: key configuration, return values, error condition. It is fully adequate for the agent.
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% for the single parameter. The description repeats that pack_content is 'the evidence pack to sign, as JSON text', which adds minimal value over the schema's description. 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 uses the specific verb 'Sign' and identifies the resource as 'a pack's canonical content'. It clearly distinguishes from sibling tools like 'verify_pack_signature' and 'seal_pack' by focusing on the signing operation.
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 places signing as part of a workflow (after building, before sealing) but does not explicitly state when not to use this tool or mention alternatives. However, the sibling context aids differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign a pack's SHA-256 canonical digest with AWS KMS.
**Requires the ``[aws]`` extra** (``pip install
iso20022-evidence-pack-mcp[aws]``) and **reaches AWS KMS over the
network** -- unlike the closed-world tools, this one has a network
surface. The private key never leaves KMS; the tool submits only the
pack's digest. Returns the pack with an ``aws_kms_signature`` block
attached.
Args:
evidence_pack_json: The evidence pack to sign, as JSON text.
key_arn: The ARN of the KMS ``SIGN_VERIFY`` key.
aws_region: The AWS region hosting the key.
| Name | Required | Description | Default |
|---|---|---|---|
| key_arn | Yes | The ARN of the KMS SIGN_VERIFY key. | |
| aws_region | No | The AWS region. | us-east-1 |
| evidence_pack_json | Yes | An evidence pack as raw JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: network reachability, private key never leaving KMS, submission of only the digest, and the return shape ('aws_kms_signature' block). No contradiction with annotations; readOnlyHint=false is consistent with 'returns the pack with a signature block attached'.
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 well-structured: purpose first, key caveats in bold, then an Args list. It is concise overall, but the Args section repeats schema content already visible to the agent, adding some redundancy without much new 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 the tool's open-world nature and existing output schema, the description covers the essential operational context: network access, installation requirement, cryptographic behavior, and return value. It is sufficiently complete for an agent to decide whether this tool fits the use case and invoke it safely.
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 100%, so the schema already documents all three parameters. The description's Args section mostly duplicates the schema text, with only minor added phrasing like 'hosting the key' and 'to sign', which does not materially deepen parameter understanding.
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?
Clearly states the verb ('Sign'), the resource (pack's SHA-256 canonical digest), and the method (AWS KMS). It also distinguishes itself from sibling tools by mentioning the network surface and that the private key never leaves KMS, unlike closed-world signing tools.
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?
Explicitly states the requirement for the [aws] extra and that this tool operates over the network, contrasting with closed-world tools. However, it does not name specific alternative tools (e.g., sign_pack_vault) or give explicit when-not-to-use criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign a pack's canonical bytes with HashiCorp Vault Transit.
**Requires the ``[vault]`` extra** (``pip install
iso20022-evidence-pack-mcp[vault]``) and **reaches a Vault server over the
network** -- unlike the closed-world tools, this one has a network
surface. POSTs to ``/v1/transit/sign/{key_name}`` and returns the pack
with a ``vault_signature`` block attached.
Args:
evidence_pack_json: The evidence pack to sign, as JSON text.
vault_url: The base URL of the Vault server.
key_name: The Transit key to sign with.
token: The Vault access token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The Vault access token. | |
| key_name | Yes | The Transit key name to sign with. | |
| vault_url | Yes | The base URL of the Vault server. | |
| evidence_pack_json | Yes | An evidence pack as raw JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint=true and destructiveHint=false, and the description adds meaningful context beyond that: it requires a pip extra, makes network calls, POSTs to a specific Vault endpoint, and returns a pack with a vault_signature block. This gives the agent a clear behavioral model without contradicting the annotations.
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 front-loaded with the core purpose, then uses bolded warnings for installation and network surface, then a compact Args list. It is appropriately sized for a tool with four parameters and a network dependency, though the Args section is somewhat redundant with the schema.
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 the output schema exists and annotations cover open-world behavior, the description provides enough extra context: installation requirement, network reach, endpoint, and return shape. It does not deeply discuss authentication edge cases or failure modes, but for this tool's complexity it is sufficiently complete.
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 100%, so the baseline is 3. The description's Args section largely repeats the schema's parameter descriptions without adding new semantics. The endpoint template '/v1/transit/sign/{key_name}' implicitly ties key_name to the API path, but this is minor incremental value.
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 opens with a specific verb+resource: 'Sign a pack's canonical bytes with HashiCorp Vault Transit.' It clearly distinguishes this tool from siblings like sign_pack_aws_kms and sign_pack by naming the Vault Transit backend, and it further differentiates by highlighting the network surface.
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 gives clear context for when to use this tool: when signing with Vault Transit, and it explicitly notes that it 'reaches a Vault server over the network -- unlike the closed-world tools.' It does not explicitly name alternatives or state when not to use it, but the closed-world contrast provides useful selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a container image signature with cosign.
**Reaches an external system**: shells out to a locally installed
``cosign`` binary (which contacts the registry and transparency log). No
optional Python extra is required, but the binary must be on ``PATH`` --
otherwise the tool returns an ``EP_EXTERNAL_TOOL`` error. For keyless
verification, supply ``certificate_identity`` and
``certificate_oidc_issuer``.
Args:
image_ref: The container image reference to verify.
certificate_identity: The keyless certificate identity (optional).
certificate_oidc_issuer: The keyless OIDC issuer URL (optional).
| Name | Required | Description | Default |
|---|---|---|---|
| image_ref | Yes | The container image reference to verify. | |
| certificate_identity | No | Keyless certificate identity. | |
| certificate_oidc_issuer | No | Keyless OIDC issuer URL. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it shells out to an external binary, contacts the registry and transparency log, may return an EP_EXTERNAL_TOOL error, and explains the optional keyless parameters. This is exactly the kind of disclosure that helps an agent anticipate side effects and failure modes.
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 well-structured and efficient: a one-sentence purpose, a bolded external-system warning, and a concise Args list. Every sentence carries meaningful information with no redundancy or filler.
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 the tool's complexity, the description covers the key operational aspects: external dependency, PATH requirement, error code, keyless mode, and all parameters. The output schema likely handles return-value details, so no additional output documentation is needed here.
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%, so the baseline is 3. The description adds meaning by explaining that certificate_identity and certificate_oidc_issuer are only needed for keyless verification, clarifying their role in context. This goes slightly beyond the schema's individual field descriptions.
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 verifies a container image signature with `cosign`, using a specific verb and resource. This distinguishes it from sibling tools like `verify_pack_signature` and `verify_slsa_provenance`, which target different artifact types.
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 gives clear context for use: verify a container image signature via cosign, with keyless verification enabled by supplying certificate identity and OIDC issuer. It notes the prerequisite of cosign being on PATH, but does not explicitly state when not to use the tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a detached Ed25519 signature over a pack's canonical content.
Args:
pack_content: The evidence pack to check, as JSON text.
signature: The base64-encoded detached signature.
public_key: The signer's PEM public key.
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | The base64 Ed25519 signature to check. | |
| public_key | Yes | The signer's PEM public key. | |
| pack_content | Yes | An evidence pack as raw JSON text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the specific algorithm (Ed25519) and the concept of 'canonical content,' which provides useful behavioral context beyond annotations. No contradictions.
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 main purpose is stated in a single sentence front-loaded. However, the Arg list repetition is redundant given the schema is provided; it adds length without new content. Otherwise efficient.
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 the tool's simplicity (3 required parameters, no enums, output schema present, strong annotations), the description covers the essentials: algorithm, input types, and purpose. It lacks error handling details but is complete enough for typical use.
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 100%, so the baseline is 3. The parameter descriptions in the tool definition largely duplicate the schema descriptions, adding no new information (e.g., 'base64-encoded' and 'PEM' are already in schema). Minimal value added.
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 action ('verify'), the cryptographic algorithm ('Ed25519'), and the resource ('detached signature over a pack's canonical content'). This unambiguously distinguishes it from sibling tools like 'sign_pack' and 'verify_seal'.
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 does not provide explicit guidance on when to use this tool versus alternatives. Usage context is implied by the tool's specific purpose, but no exclusions or when-not-to-use advice is given. Given sibling tools exist, a usage hint would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recompute a pack's seal and compare it to an expected digest.
Args:
pack_content: The evidence pack to check, as JSON text.
expected_digest: The seal the pack is expected to carry.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_content | Yes | An evidence pack as raw JSON text. | |
| expected_digest | Yes | The seal to check the pack against. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it compares to an expected digest but does not disclose additional traits beyond what annotations provide.
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 concise with minimal waste. Two sentences explain the main action and parameters.
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 the presence of an output schema and clear annotations, the description adequately covers the verification functionality. It could mention return result but output schema fills that gap.
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%, and the description's parameter explanations mirror the schema descriptions. No additional meaning is added beyond the schema.
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 uses specific verbs ('Recompute', 'compare') and clearly identifies the resource ('pack's seal'). It distinguishes from sibling tools like seal_pack (creates seal) and verify_pack_signature (verifies signature).
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 states the basic operation but does not explicitly guide when to use this tool versus siblings. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify an artifact's SLSA provenance with slsa-verifier.
**Reaches an external system**: shells out to a locally installed
``slsa-verifier`` binary (which may fetch metadata). No optional Python
extra is required, but the binary must be on ``PATH`` -- otherwise the
tool returns an ``EP_EXTERNAL_TOOL`` error.
Args:
artifact_path: Path to the artifact whose provenance is checked.
provenance_path: Path to the SLSA provenance attestation.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact_path | Yes | Path to the artifact to verify. | |
| provenance_path | Yes | Path to the SLSA provenance attestation. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds that it shells out to an external binary and may fetch metadata, and that it returns EP_EXTERNAL_TOOL if the binary is missing. This adds relevant behavioral context beyond annotations.
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 well-structured with a brief summary, a clear note about external dependencies, and a concise Args section. Every sentence adds value with no fluff.
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?
The tool has an output schema, which reduces the need to explain return values. The description covers prerequisites (binary on PATH) and error behavior, which is sufficient for a verification tool. It could mention the result format, but given the output schema exists, the completeness is adequate.
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 100%, and the description provides minimal additional meaning beyond the schema, just restating the relevant arguments. Baseline of 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 verifies an artifact's SLSA provenance using slsa-verifier, with a specific verb and resource. It distinguishes from siblings like verify_cosign_signature by specifying SLSA, but does not explicitly contrast with it.
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 indicates that the tool requires a locally installed slsa-verifier binary on PATH and that it may fetch metadata, but does not explicitly say when to use it over other verification tools like verify_cosign_signature or verify_seal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target a distinct operation (seal, build, render, export, verify external artifacts), but the three signing tools -- sign_pack, sign_pack_aws_kms, sign_pack_vault -- share the same core action and are distinguished mainly by backend. The three verify tools are also similar in name, though their inputs make the artifact types clear.
Tool names generally follow a verb_noun pattern (seal_pack, build_evidence_pack, render_markdown, export_pack_to_s3), and the provider-specific signing tools add a consistent _aws_kms/_vault suffix. Minor inconsistency exists between verify_seal, verify_pack_signature, verify_slsa_provenance, and verify_cosign_signature, which mix 'verify' with different object structures.
Eleven tools is well within the ideal range for a specialized evidence-pack domain. Each tool maps to a distinct phase of the lifecycle -- build, seal, verify, render, sign, export, and external provenance checks -- without redundant or filler tools.
The set covers the evidence-pack lifecycle well: creation, sealing, seal verification, rendering, local signing, signature verification, and S3 export. Notable gaps are the lack of KMS/Vault signature verification counterparts and no S3 retrieval/listing, but these are workaround-able rather than blocking for the core workflow.
Dated, signed compliance-evidence packs: gov-fact-grounded claims + exclusion screens + trap-facts.
Verify structured evidence and return machine-verifiable provenance, assurance, and receipts.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Timestamp & verify evidence on-chain, free. Proofpack: a portable BEEF+BUMP proof bundle per txid.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sebastienrousseau/iso20022-evidence-pack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
