A
licenseNot graded
qualityB
maintenanceEnables AI agents to sign and verify actions with ML-DSA-65 digital signatures, providing tamper-proof receipts that can be verified offline without any secrets.
MIT
Affixio MCP
Officialby AffixIO
This server gives an agent a local, signed yes/no record and policy gating for actions, while keeping PII on the host.
attest_action: Record a local action and get a signed ML-DSA-65 attestation with timestamp, action id, and proof id; optional outcome, context hash, policy id, and non-PII summary are supported.
verify_action: Validate an action attestation or receipt and return
validtrue/false with a reason.gate_tool_call: Gate a privileged agent tool call and return a signed allow/deny decision based on policy, amount limits, and blocked argument patterns.
Local-first security: raw tool args are never persisted, only SHA-256 digests; proving runs offline via the affixio SDK in HMAC mode.
Fail-closed enforcement: unknown tools, over-limit amounts, blocked patterns, and malformed proofs deny.
Environment configuration supports API key, state directory, agent id, allowed tools, max amount, currency, and blocked patterns.
Click on "Deploy 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., "@Affixio MCPattest that I deployed the production release"
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.
Affixio MCP
Local stdio MCP server that wraps the affixio SDK. It gives agents a signed yes or no record that an action happened on the host.
The SDK stays as it is: install with npm i affixio. This package only adds a local MCP front end for catalog listings and platform wraps.
Run it with npx @affixio/mcp@0.1.0. PII never leaves the host: tool arguments are hashed, never stored, and proving runs offline on the machine.
Install
npm i -g @affixio/mcp@0.1.0
affixio-mcpOr without installing:
npx -y @affixio/mcp@0.1.0Check it works:
affixio-mcp probeRelated MCP server: hive-mcp-spire
Client config
Claude Desktop config file, Examples dir has ready files:
{
"mcpServers": {
"affixio": {
"command": "npx",
"args": ["-y", "@affixio/mcp@0.1.0"],
"env": {
"AFFIX_API_KEY": "local_operator",
"AFFIX_MCP_HOME": "${HOME}/.affix-mcp"
}
}
}
}Cursor uses the same mcpServers shape. Copy examples/claude-desktop-mcp.json or examples/cursor-mcp.json.
Tools
Only three tools ship. No identity, age, KYC, MRZ, passport, licence, vehicle, admin, OAuth, or cloud passthrough. Those stay on the Hub MCP.
attest_action: action plus optional outcome, context hash, policy id. Returns a signed action attestation with timestamp, action id, ML-DSA-65 signature, and proof id.
verify_action: attestation or receipt in, valid true or false plus reason out.
gate_tool_call: tool name plus args hash or summary plus policy in, allow or deny plus signed decision out. Call before privileged agent tool calls.
Env config
AFFIX_API_KEY: licence key, defaults to local_operator for offline use
AFFIX_API_BASE: override API base, unset means SDK default
AFFIX_MCP_HOME: state dir, defaults to ~/.affix-mcp
AFFIX_MCP_AGENT_ID: default agent id
AFFIX_MCP_ALLOWED_TOOLS: comma list, empty means any tool may attest
AFFIX_MCP_MAX_AMOUNT: optional numeric cap, denies above it
AFFIX_MCP_CURRENCY: currency code, default GBP
AFFIX_MCP_BLOCKED_PATTERNS: comma list, default sk_live_, AKIA, PRIVATE KEY
Security
Local first. Proving runs offline via the affixio SDK in HMAC mode, signed ML-DSA-65. Gate decisions are fail closed: unknown tools, over-limit amounts, blocked arg patterns, and malformed proofs all deny. Raw tool args never persist; the record keeps a sha256 digest only.
Dev
npm install
npm test
npm run probeLicense
Apache-2.0. See LICENSE.
Available Tools
3 toolsattest_actionA
Record a local action and return a signed yes-or-no ACTION attestation. PII stays on the host.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action id or name, for example payments.create | |
| outcome | No | yes or no. Defaults to yes. | yes |
| agent_id | No | Optional agent id | |
| policy_id | No | Optional policy id | |
| context_hash | No | Optional sha256 of host-side context. Raw context is never sent. | |
| details_summary | No | Optional short non-PII summary. Only its hash is stored. |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It meaningfully discloses that the tool records a local action, returns a signed yes/no attestation, and keeps PII on the host. It could add more about persistence or output format, but the provided privacy and signing behavior is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences, with the primary purpose front-loaded and the privacy constraint in a separate clear sentence. Every word earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description gives the essential purpose and privacy stance but does not fully explain the attestation's return structure or when to choose this over sibling tools. The schema covers parameters well, but the overall contract is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all six parameters, so schema coverage is 100%. The description adds only indirect context, such as 'yes-or-no' matching the outcome parameter and 'PII stays on the host' relating to context_hash and details_summary. This meets the baseline without adding substantial parameter-specific detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Record'), a resource ('a local action'), and an output ('a signed yes-or-no ACTION attestation'). This makes the core purpose clear, though it does not explicitly contrast itself with verify_action or gate_tool_call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'PII stays on the host' implies a privacy-preserving use case, and 'Record a local action' suggests when this tool is appropriate. However, there is no explicit guidance about when to prefer this tool over the sibling tools verify_action or gate_tool_call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gate_tool_callB
Policy gate for one privileged agent tool call. Returns allow or deny plus a signed decision.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Tool arguments. Only a sha256 digest is kept in the decision record. | |
| tool | Yes | Tool name, for example payments.create | |
| amount | No | Optional cost or amount | |
| agent_id | No | Optional agent id | |
| currency | No | Optional currency code | |
| resource | No | Optional resource label | |
| policy_id | No | Optional policy id |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions returning a signed decision, which is good, but it doesn't disclose key behaviors: what happens if the tool is denied, whether the tool call is executed, or any side effects. This is a policy gate, so agents need to know it might block actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, one clear sentence, and front-loaded with the purpose. It's efficient but could be slightly better organized with more detail on usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, policy gating, privileged calls), the description is thin. It doesn't cover return values (no output schema), side effects, or how the decision is signed. For a security-related tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for parameters, so the baseline is 3. The description adds no additional semantics beyond what's in the schema, which is acceptable but doesn't elevate the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates a privileged agent tool call and returns allow/deny plus a signed decision, distinguishing it from attest_action and verify_action. However, it's a bit generic and could be more specific about the policy-gating aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's for privileged tool calls, but it doesn't explicitly state when to use it over attest_action or verify_action. The sibling names suggest attest_action is for attestation and verify_action for verification, but the description doesn't clarify the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_actionC
Verify a local ACTION attestation and return valid true or false with a reason.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| proof | No | Attestation proof hex | |
| envelope | No | Optional proof envelope from attest_action | |
| circuit_id | No | Circuit id, default simple_yesno | simple_yesno |
| attestation | No | Optional full attestation object holding proof and envelope |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that the tool is local and returns a boolean with a reason, but does not clarify whether it is read-only, if it has side effects, or how errors are surfaced. The term 'verify' implies non-mutating, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundancy. The core action and output are front-loaded. It is appropriately concise, though it could include a hint about usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, nested objects, and no output schema, the description is minimal. It does not explain what constitutes a valid attestation, how the proof and envelope relate, or what the 'reason' format is. An agent might call it correctly for the simplest case but lacks context for the optional parameters and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all four parameters. The description adds no parameter-specific detail beyond the general notion of 'attestation'. It does not clarify the relationship between proof, envelope, and attestation, or how to choose among them, but the schema descriptions partially cover this. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Verify a local ACTION attestation') and a clear outcome ('return valid true or false with a reason'). Distinguishes from sibling attest_action (which creates attestations) and gate_tool_call (likely gating) by its verification role, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus siblings. It does not mention prerequisites, when verification is appropriate, or why one would choose this over attest_action or gate_tool_call. Usage is only implied by the verb 'verify'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
attest_action - First observed
gate_tool_call - First observed
verify_action
TDQS
A3.7/5.0
Scored across 3 tools
Disambiguation5/5
Each tool targets a distinct stage in the attestation workflow: gating a tool call, recording an action, and verifying an attestation. There is no ambiguity between them, as the verb and noun clearly separate purposes.
Naming Consistency5/5
All three tool names follow a consistent verb_noun pattern: gate_tool_call, attest_action, verify_action. This makes the naming predictable and easy to reason about.
Tool Count5/5
With only three tools, the server is tightly scoped to its attestation/gating purpose without unnecessary bloat. Each tool serves a necessary role in the workflow.
Completeness5/5
The tool set covers the full lifecycle of attestation: gating a call, creating an attestation, and verifying it. No obvious gaps exist for the stated domain.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Post-quantum, tamper-evident receipts for agent actions. Ed25519 + ML-DSA-65, offline verify.
Pre-action attestation perimeter for AI agents — 8 primitives, signed C18 receipt per call.
Human-in-the-loop approval for agent actions, with verifiable action-bound receipts.
Agentic identity trust: precision decisioning, cryptographic release tokens, hash-chained proof
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceProvides tools to sign and verify post-quantum attestations of AI agent actions (mint, trajectory, coherence) using ML-DSA-65 signatures, with offline verification always free.MIT
garlofficial
AlicenseNot gradedqualityBmaintenanceCryptographic verification for AI agent actions — ECDSA-secp256k1 signed Action Receipts anchored on Base, multi-dimensional trust vectors, capability tokens, and offline-verifiable on-chain proof. 29 tools.2Apache 2.0- AlicenseNot gradedqualityBmaintenanceA public-safe research prototype for controlling AI-agent tool actions with deterministic policy, risk-based human approval, time-bound authorization and a tamper-evident audit chain.1MIT