iso20022-evidence-pack-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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| build_evidence_packC | Fold readiness, remediation, and simulations into a sealed pack. |
| seal_packA | Compute the deterministic SHA-256 seal for an evidence pack. |
| verify_sealA | Recompute a pack's seal and compare it to an expected digest. |
| render_markdownA | Render an evidence pack as a markdown compliance report. |
| sign_packA | Sign a pack's canonical content with the server's Ed25519 key. |
| verify_pack_signatureA | Verify a detached Ed25519 signature over a pack's canonical content. |
| sign_pack_aws_kmsA | Sign a pack's SHA-256 canonical digest with AWS KMS. |
| sign_pack_vaultA | Sign a pack's canonical bytes with HashiCorp Vault Transit. |
| export_pack_to_s3A | Upload a signed evidence pack to Amazon S3. |
| verify_slsa_provenanceA | Verify an artifact's SLSA provenance with |
| verify_cosign_signatureA | Verify a container image signature with |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| audit_readiness_compliance | Guide an analyst through a readiness/compliance audit of a pack. The guidance teaches the full evidence-pack workflow (build, seal or sign, verify, then render) and asks for a prioritized remediation checklist. Args: evidence_pack_id: An optional pack identifier to anchor the audit; when omitted, the guidance covers assembling a pack from scratch. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| evidence_pack_schema | The EvidencePack Pydantic model as a JSON schema. |
| error_codes | The stable error codes returned inside tool payloads. |
TDQS
Scored across 11 tools
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.