Achromat MCP server
OfficialClick 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., "@Achromat MCP serverCan you recall the compliant version of this payment call before I run it?"
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.
Achromat MCP server
An MCP server that lets any MCP host (Claude Desktop, an IDE, an agent framework) use Achromat MOM as native tools. MOM keeps verified memory of tool calls that policy blocked and the corrected calls that were then allowed. With this server your agent can ask for the compliant version of a call before it acts, and check a call against live policy, without you writing any integration code.
The server runs on your machine as a child process of the host and talks to it over stdio. It signs every request to MOM with an Ed25519 key that stays on your machine: only signatures leave it, never the key.
Add it to Claude Desktop
Open the configuration file:
OS | Path |
macOS |
|
Windows |
|
Add the server under mcpServers, then restart Claude Desktop:
{
"mcpServers": {
"achromat": {
"command": "npx",
"args": ["-y", "@achromat-ai/mcp-server"]
}
}
}That is the whole setup. Requires Node.js 20 or newer; -y lets npx install the package without asking. Other MCP hosts take the same command and arguments in their own configuration.
Related MCP server: correctover-mcp-server
First use: your agent sets up the identity
Every request to MOM is signed, so the server needs a key that MOM knows. You do not create or register one yourself. The first time you use the server it has no key, so it offers a single tool, achromat_register_identity, and your agent will ask you whether to set up an identity. If you say yes, the server:
generates an Ed25519 key pair on your machine,
does a short proof of work (about a second; it is how MOM limits automated sign-ups),
registers the public key with MOM, and
saves the private key to
~/.achromat/achromat_agent_key.pem, readable only by you.
Then achromat_recall and achromat_calibrate appear in place of the registration tool. If your host does not refresh its tool list by itself, restart it once.
What leaves your machine: the public key, the proof of work, and a signature proving you hold the private key. The private key never does. MOM keeps a record of the registration and limits it to 10 a day per network.
The key file is the identity. Keep it private, out of git and out of screenshots, and back it up: it cannot be recovered if you lose it. The server never overwrites an existing key file, and it only saves the file once MOM has accepted the key, so a failed attempt leaves nothing behind.
Choosing where the key lives
By default the key is at ~/.achromat/achromat_agent_key.pem. To use another path, set ACHROMAT_AGENT_KEY_FILE in the host configuration. This works for a new key (the server creates it there) and for one you already have:
{
"mcpServers": {
"achromat": {
"command": "npx",
"args": ["-y", "@achromat-ai/mcp-server"],
"env": {
"ACHROMAT_AGENT_KEY_FILE": "/Users/you/keys/achromat_agent_key.pem"
}
}
}
}On Windows use the full path with escaped backslashes, for example "C:\\Users\\you\\keys\\achromat_agent_key.pem". A leading ~ is expanded by the server. A desktop app may start the server with a different home directory than your terminal has, so spelling the path out removes any doubt.
An existing key must be an unencrypted PKCS#8 Ed25519 PEM file that MOM already knows.
Run from source
git clone https://github.com/achromat-ai/achromat-mcp-server.git
cd achromat-mcp-server
npm install
npm run buildPoint the host at the build instead of npx:
{
"mcpServers": {
"achromat": {
"command": "node",
"args": ["/absolute/path/to/achromat-mcp-server/dist/index.js"]
}
}
}To try the tools in a browser without a host, use the MCP Inspector:
npm run inspectTools
achromat_register_identity
Offered only while there is no key file. Creates and registers an identity as described above. It requires user_confirmed: true, which the agent may set only after you have agreed; the tool description tells it to ask first.
Parameter | Required | Description |
| yes | Must be |
achromat_recall
Call this before running a tool that policy might block (payments, credit decisions, robot or plant commands, shell, SQL, web requests). It asks whether a verified compliant version of the call already exists. On a match you get compliant_arguments, a steering_directive and the rule that applied. Use the whole compliant_arguments object as your template, keep any [VERIFIED_STATE] placeholders exactly as written, and change only your own operational values.
Parameter | Required | Description |
| yes |
|
| yes | The exact name of the tool you are about to call. |
| yes | What you are trying to do, in plain words (16 to 1000 characters, at least 3 words). No amounts, identifiers or personal data. |
| yes | The arguments you intend to send, as a non-empty JSON object using the tool's real key names. Only the names of the keys (and their nesting) are used for semantic matching, never the values, so real key names find the right lesson and an invented shape finds the wrong one or none. |
achromat_calibrate
Call this when recall found nothing, or when the stakes are high. It evaluates the call against live policy and returns the verdict, the steering directive and the receipt id. A BLOCK comes with a trap_id: fix the arguments as the directive says and call the tool again with the same task_description and the trap_id. An ALLOW means the call complies. A block followed by an allow becomes a lesson for other agents.
Parameter | Required | Description |
| yes | As above. |
| yes | As above. |
| yes | Use exactly the same wording on the retry: it is what pairs a block with its fix. |
| yes | The arguments of the call to check. A non-empty JSON object. |
| no | Only on a retry: the |
Never put secrets or credentials in arguments or task_description; the service rejects them.
The tools use the name tool_name; the service's own field is tool, and the server maps between them.
Lesson text (rules, directives, arguments) comes from the community. The server labels it as data in every answer, and your agent should use it only to choose parameter values.
Configuration
Variable | Default | Meaning |
|
| Where the agent's Ed25519 private key is, or will be created. |
|
| The service origin. Must be |
Whether the key file exists decides which tools are offered, and it is checked at startup and right after a registration. If you delete, move or replace the key file while the host is running, restart the host. The key itself is read on the first tool call, so a wrong key never makes the server disappear from your host: the tool call returns a message saying what to fix.
When something goes wrong
Every failure comes back to the agent as a readable tool result, with the next step.
What you see | Cause and fix |
Only | There is no key file yet. That is the normal first state. Say yes when your agent asks. |
| An identity is already set up there. To start over, move or delete the file and restart the host. |
| The folder is not writable. Fix its permissions or set |
| MOM limits sign-ups per network (10 a day). Wait, or try from another network. Nothing was created. |
| A network problem. Nothing was created; try again. |
| Rare. The message gives the path where the key was saved; move it to the path you want. Do not delete it. |
| An existing key must be unencrypted PKCS#8 Ed25519. |
| Run |
| A key file exists but MOM does not know it. Move or delete the file and restart the host to create a new identity. |
| The key was revoked or rotated. Move or delete the file and restart the host. |
| Your clock is more than 60 seconds off. The server corrects for this by itself using the service's clock; if it still fails, check your system time. |
| Recall allows 240 an hour per key and 50 distinct lessons a day; calibrate allows 120 an hour. Wait for the time given. |
| The service lists the offending fields. Often a credential or personal data in the text or arguments. |
Server logs go to stderr, which hosts write to their own MCP log files (Claude Desktop keeps them in its logs folder; on macOS that is under ~/Library/Logs/Claude/). The server never logs keys, signatures or request contents.
If the host cannot start npx, it may not see the PATH your terminal does (common with nvm). Put the absolute path of npx or node in command.
Development
npm run typecheck # source and tests
npm test # vitest
npm run build # compile to dist/ and mark dist/index.js executable
npm start # run the built server on stdio (waits for a host)stdout is the protocol channel, so the server writes nothing else to it.
The signing and registration code follows the byte-level contract in the agent protocol (sections 2 and 3), and the tests reproduce its published self-check vectors exactly: the request signature, and the proof-of-work nonce. Ed25519 is deterministic, so a change that alters a single byte of what is signed fails them.
The proof of work searches on several worker threads (up to 8, never all cores) so that it takes about a second and the server stays responsive while it runs.
Licence
Available Tools
1 toolachromat_register_identityCreate and register an Achromat identityAInspect
Achromat needs a private key on this machine before it can answer anything, and none exists yet. This tool creates one: it generates an Ed25519 key pair, completes a short proof of work (about a second), registers the public key with Achromat MOM, and saves the private key to a file that only this user can read. ASK THE USER FIRST and wait for a yes, because it writes a private key file on their machine and creates an identity on the service. Explain that the key never leaves the machine, that only the public half is sent, and that the file cannot be recovered if lost. Then call this tool with user_confirmed set to true. Afterwards achromat_recall and achromat_calibrate become available.
| Name | Required | Description | Default |
|---|---|---|---|
| user_confirmed | Yes | Set to true ONLY after the user has said yes to creating an identity. If they have not been asked, ask first and do not call this tool. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only, non-idempotent, open-world, non-destructive, but the description adds far more: a local private-key file with user-only read permission, a ~1 second proof of work, an external registration, the fact that only the public half is transmitted, and that a lost file is unrecoverable. It also surfaces the consent requirement, which annotations cannot express.
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?
It is front-loaded with the problem state, then the action, then the consent instruction, which is the right order for a high-stakes call. Every sentence carries weight, though the confirmation requirement is stated in both the description and the schema description, a minor redundancy.
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?
With no output schema and only four annotations, the description fills the remaining gaps: prerequisites, side effects on disk and on the service, timing, security properties, irreversibility, and which tools become usable afterwards. An agent has everything needed to invoke this 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?
There is a single parameter and schema_coverage is 100%, so the schema already carries the full meaning of user_confirmed, including the 'only after the user said yes' gate. The description restates the same confirmation requirement rather than adding new syntax or format detail, so baseline 3 applies.
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 states a precise verb and outcome: generates an Ed25519 key pair, completes proof of work, registers the public key with Achromat MOM, and saves the private key locally. It also names the precondition (no key exists yet) and the postcondition (achromat_recall and achromat_calibrate become available), so an agent knows exactly what this tool produces.
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 gives an explicit, ordered protocol: ask the user, wait for a yes, explain the key-handling facts, then call with user_confirmed=true. It also flags the state transition that unlocks sibling tools afterwards. Nothing about when to invoke it is left to inference.
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.
1 tool update
v0.1.1- First observed
achromat_register_identity
TDQS
Scored across 1 tool
With only one tool exposed there is no overlap risk, so selection is trivially unambiguous. However, the description references achromat_recall and achromat_calibrate as if they were sibling tools, which an agent may search for and not find, adding mild confusion.
The single name achromat_register_identity follows a clear namespace_verb_noun snake_case convention that would obviously extend to the other referenced tools (achromat_recall, achromat_calibrate). No inconsistent styles are present.
One tool is far too thin for a service whose own description implies at least three operations (register, recall, calibrate). Registration alone leaves the server nearly unusable, even if the remaining tools are dynamically unlocked later.
The surface covers only identity bootstrap; there is no way to recall information or calibrate, which are presented as the core capabilities. An agent can register an identity but has no follow-up operations, creating an immediate dead end.
Related MCP Connectors
- gatewayOAuthai.sealgate
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides advisory AI-governance checks for MCP hosts and coding agents, enabling policy verdicts, PII masking, and audit traces before executing tool calls.337 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to execute tool calls with CCS runtime verification across six dimensions, ensuring fail-closed conformance before any action is executed.162 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables MCP clients to govern downstream tool servers by enforcing default-deny authority and attestation on every tool call, with live monitoring, approval, and mid-session revocation.3Apache 2.0
- AlicenseBqualityBmaintenanceEnforces consensus-hardened tool approval with HMAC-signed receipts, policy gates, and host-bound argument checks for MCP clients.1222 npmMIT