The TrustAtom MCP Server provides cryptographic signing, verification, querying, and compliance reporting for AI decisions:
Sign AI decisions (create_trustatom): Cryptographically sign any AI decision (e.g., APPROVE_LOAN, TRIAGE_PATIENT, DEPLOY) using Ed25519 + SHA-256 in under 3ms, producing a tamper-proof receipt with optional context, risk_score (0.0–1.0), and auto-mapped compliance tags.
Verify receipts (verify_trustatom): Confirm the authenticity and integrity of an existing receipt by checking its Ed25519 signature and detecting any tampering.
Query the receipt ledger (query_receipts): Retrieve stored receipts filtered by actor, action, decision outcome (ALLOW/DENY), or limit — useful for audits.
Generate compliance reports (get_compliance_report): Aggregate receipts into framework-mapped reports (HIPAA, SOX, NIST, SOC2, CMMC, ISO27001) suitable for board reporting or Authorization to Operate (ATO) packages.
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., "@TrustAtom MCP Server Sign this clinical triage decision for HIPAA compliance"
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.
⚠️ Superseded by trust-gate-mcp
This repository is no longer the recommended way to mint Trust Gate receipts. It is kept public as a reference implementation and for historical context.
Use
trust-gate-mcpinstead:pip install trust-gate-mcp
This repo
trust-gate-mcpSigning
Ed25519 only
Ed25519 + ML-DSA-65 (FIPS 204), + SLH-DSA with liboqs
Tools
4
7
Receipt
envalways
SANDBOXreflects real environment
Published
no —
@cwn/trustatom-mcpwas never released to npmyes, on PyPI
Hosted
—
Maintained
no
yes
The
npx/npm installinstructions below therefore only work from a git clone. There is no@cwn/trustatom-mcppackage on the npm registry.
Cryptographic receipts for AI decisions. 5 minutes to your first receipt.
Every AI decision in your org is unsigned — and your auditor is going to ask about it. TrustAtom signs every decision with Ed25519 and returns a verifiable receipt in under 3ms.
Related MCP server: DCL Evaluator
git clone https://github.com/CWNApps/trustatom-mcp
cd trustatom-mcp
npm install
npm run keygen # Generate Ed25519 key pair
npm test # Run 8 eval tests{
"mcpServers": {
"trustatom": {
"command": "npx",
"args": ["tsx", "src/server.ts"],
"cwd": "/path/to/trustatom-mcp",
"env": { "TRUSTATOM_KEY_PATH": "./keys/trustatom_keys.json" }
}
}
}Then in Claude: "Sign this AI decision with TrustAtom" → receipt issued automatically.
Tool | Description | When |
| Sign a decision, return receipt | At every AI decision point |
| Verify an existing receipt | During audit, dispute resolution |
| Query the receipt ledger | Compliance reporting |
| Framework-mapped report | Board report, ATO package |
You: "Our clinical AI just triaged patient #4422 as ESI-3 with 67% confidence.
Sign this decision for HIPAA compliance."
Claude (via TrustAtom MCP):
✅ Receipt ta_7f3a2b signed in 1.2ms
Action: TRIAGE_PATIENT
Decision: ALLOW
Compliance: HIPAA:164.312(b), HL7
Risk Score: 0.80
Signature: ed25519:abc123...What the auditor sees: "On Mar 7 at 14:22, clinical-ai-v2 classified patient #4422 as ESI-3. Receipt ta_7f3a2b is Ed25519-signed. Control: HIPAA 164.312(b)."
TrustAtom auto-maps actions to framework controls:
Action | Frameworks |
| HIPAA 164.312(b), HL7 |
| SOX 302, FCRA |
| SOX 302, SEC 17a-4 |
| NIST PR, SOC2 CC6.1 |
| NIST PR/RS, SOC2 A1.2 |
Custom | NIST PR (default) |
Signing: <3ms average (Ed25519 + SHA-256)
Verification: <1ms
Receipt size: ~500 bytes JSON
Your AI Agent
↓ (MCP call)
TrustAtom MCP Server (local)
├── Ed25519 key pair (you own the keys)
├── SHA-256 evidence hash
├── Compliance auto-mapping
└── In-memory ledger (pluggable to Neo4j/SQLite)
↓
Receipt returned to your agent8 tests covering signing, verification, tampering detection, compliance mapping, risk scoring, and performance:
npm test
# ✅ Signs a decision and returns a valid receipt
# ✅ Verifies an authentic receipt
# ✅ Detects tampered receipt
# ✅ Auto-maps TRIAGE_PATIENT to HIPAA compliance tags
# ✅ Auto-maps APPROVE_LOAN to SOX compliance tags
# ✅ Computes risk score from action when not provided
# ✅ Signs DENY decisions with same integrity
# ✅ Signs within 3ms target for production use
# Results: 8 passed, 0 failedNeed hosted infrastructure with SLA? Contact hello@cyberwarriornetwork.com
Tier | Calls/day | Price |
Developer | 1,000 | Free |
Professional | 100,000 | $299/mo |
Enterprise | Unlimited | $2,499/mo |
Cyber Warrior Network — Trust Gate: Policy-gated AI decisions with cryptographic receipts.
No Receipt. No Trust.
Sign an AI decision and return a cryptographic receipt. Every AI decision that matters should have a receipt. Signing takes <3ms. Receipt is Ed25519-signed + SHA-256-hashed.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | The AI agent or system making the decision | |
| action | Yes | The action being decided (e.g., APPROVE_LOAN, TRIAGE_PATIENT, DEPLOY, TRADE_SIGNAL) | |
| context | No | Additional context for the decision (risk factors, confidence scores, etc.) | |
| decision | Yes | The decision outcome | |
| risk_score | No | Risk score 0.0-1.0 (auto-computed if not provided) | |
| compliance_tags | No | Compliance framework tags (e.g., HIPAA, SOX, NIST:PR, SOC2:CC6.1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about performance ('Signing takes <3ms'), cryptographic details ('Ed25519-signed + SHA-256-hashed'), and the auto-computation feature for risk_score. However, it doesn't cover error conditions, authentication requirements, rate limits, or what happens if the signing fails.
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 efficiently structured with three sentences: purpose statement, importance rationale, and technical/performance details. Every sentence adds value without redundancy, and it's front-loaded with the core function.
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 (6 parameters, cryptographic operations) and lack of annotations/output schema, the description is moderately complete. It covers the purpose, importance, and some behavioral traits but lacks details on error handling, response format, or integration constraints that would help an agent use it correctly in varied scenarios.
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 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain format examples for 'action' or 'context' beyond the schema's descriptions). Baseline 3 is appropriate when the schema does the heavy lifting.
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 purpose with specific verbs ('sign an AI decision', 'return a cryptographic receipt') and distinguishes it from siblings by focusing on creation/signing rather than retrieval (get_compliance_report, query_receipts) or verification (verify_trustatom). It also explains why this matters ('Every AI decision that matters should have a receipt').
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 clear context about when to use this tool ('Every AI decision that matters should have a receipt') and implies usage for creating signed records of decisions. However, it doesn't explicitly contrast with alternatives like query_receipts for retrieval or verify_trustatom for verification, nor does it specify exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a compliance report mapped to a specific framework. Aggregates all receipts tagged with the specified framework.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Compliance framework (HIPAA, SOX, NIST, SOC2, CMMC, ISO27001) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates and aggregates, implying a read operation that processes data, but lacks details on permissions, rate limits, output format, or whether it's a safe read-only operation. This is a significant gap for a tool with no 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 and front-loaded with two clear sentences that directly explain the tool's function without unnecessary words. Every sentence earns its place by stating the action and scope efficiently.
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 complexity of generating a report, lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects like data processing, error handling, or what the report contains, leaving gaps for an AI agent to understand the tool fully.
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?
The schema description coverage is 100%, with the parameter 'framework' fully documented in the input schema. The description adds minimal value beyond the schema by implying the framework is used to tag receipts, but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 purpose: 'Generate a compliance report mapped to a specific framework. Aggregates all receipts tagged with the specified framework.' It specifies the verb ('generate'), resource ('compliance report'), and scope ('framework'), but does not explicitly differentiate from sibling tools like 'query_receipts' or 'verify_trustatom', which might have overlapping or related functions.
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 guidance on when to use this tool versus alternatives. It mentions aggregating receipts tagged with a framework, but does not specify prerequisites, exclusions, or compare it to sibling tools such as 'query_receipts' (which might retrieve receipts without generating a report) or 'verify_trustatom' (which could involve validation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the receipt ledger for audit or compliance reporting. Filter by time range, action, actor, or decision.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | No | Filter by actor/agent | |
| limit | No | Max receipts to return (default: 20) | |
| action | No | Filter by action type | |
| decision | No | Filter by decision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions querying for audit/compliance reporting but doesn't disclose critical traits like whether this is a read-only operation, if it requires specific permissions, rate limits, pagination behavior, or what the response format looks like. For a query tool with zero annotation coverage, this is a significant gap.
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 and front-loaded, stating the purpose in the first clause. It efficiently lists filtering options in a single sentence without unnecessary details. However, it could be slightly more structured by separating purpose from usage context.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'receipt ledger' contains, the return format, or behavioral aspects like safety and limitations. For a query tool with four parameters and no structured output documentation, more context is needed to guide effective 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?
The description adds minimal value beyond the input schema, which has 100% coverage. It lists filterable fields (time range, action, actor, decision) but doesn't provide additional semantics like format examples or constraints. Since the schema already documents all parameters thoroughly, the baseline score 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's purpose: 'Query the receipt ledger for audit or compliance reporting.' It specifies the verb (query) and resource (receipt ledger) with a clear use case (audit/compliance reporting). However, it doesn't explicitly differentiate from sibling tools like 'get_compliance_report' or 'verify_trustatom,' which might have overlapping audit/compliance functions.
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 guidance on when to use this tool versus alternatives. It mentions filtering capabilities but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'get_compliance_report' for reporting or 'verify_trustatom' for verification tasks. This leaves the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the integrity of an existing TrustAtom receipt. Confirms the Ed25519 signature is authentic and the receipt hasn't been tampered with.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | The TrustAtom receipt ID (e.g., ta_01hx9k...) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral context. It states the verification purpose but doesn't disclose critical traits like required permissions, rate limits, error conditions, or what happens on failure (e.g., returns error vs null). The mention of 'Ed25519 signature' adds some technical context, but overall disclosure is inadequate for a security-focused 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 concise sentences with zero waste: the first states the purpose, and the second adds technical specificity. It's front-loaded and appropriately sized for a single-parameter tool.
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 complexity (security verification), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values (e.g., success/failure indicators, timestamps), error handling, or dependencies on other tools. For a tool with no structured behavioral data, more context is needed.
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 the 'receipt_id' parameter. The description implies the parameter is used for verification but doesn't add syntax, format, or validation details beyond what the schema provides (e.g., examples of valid IDs). Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('verify integrity'), target resource ('existing TrustAtom receipt'), and technical details ('Ed25519 signature authenticity', 'tampering check'). It distinguishes from siblings like 'create_trustatom' (creation vs verification) and 'query_receipts' (listing vs validation).
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a receipt ID from another operation), exclusions, or comparisons to siblings like 'get_compliance_report' or 'query_receipts' for related verification tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: create_trustatom signs decisions, get_compliance_report generates reports, query_receipts searches the ledger, and verify_trustatom validates receipts. The descriptions clearly differentiate their functions, eliminating any ambiguity.
All tool names follow a consistent verb_noun pattern (create_trustatom, get_compliance_report, query_receipts, verify_trustatom), using snake_case throughout. This predictability makes the tool set easy to navigate and understand.
With 4 tools, this server is well-scoped for its purpose of cryptographic receipt management and compliance. Each tool serves a distinct role in the lifecycle (create, query, report, verify), and the count is neither too sparse nor bloated.
The tool set provides complete coverage for the domain of AI decision receipt management: create_trustatom handles creation, query_receipts enables retrieval, get_compliance_report supports reporting, and verify_trustatom ensures integrity. No obvious gaps exist for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed AI actions with signed, verifiable receipts: free keyless reads, human-approved writes.
Runtime AI governance: decision gates, human approval, hash-chained audit, compliance mapping.
Register every AI agent, log every action, prove it. EU AI Act compliance built in.
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CWNApps/trustatom-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
