Atlas
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ATLAS_MCP_DATA_DIR | No | Directory holding issuer.json, audit.jsonl and its signed head audit.head. Nothing leaves the machine. | ~/.atlas-mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Atlas is a pre-action authorization gate. Before any consequential action, call atlas_authorize with the action, its effects and your delegation chain; proceed only on permit. Afterwards call atlas_commit_effect with what actually happened.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| atlas_authorizeA | Ask for authorization BEFORE doing anything consequential (deleting data, deploying, spending, sending). Atlas checks the action and its effects against the signed delegation chain and returns permit, deny or escalate with a receipt_id. Do not perform the action unless the decision is permit (or escalate that a human later approved). |
| atlas_commit_effectA | After acting on a permitted receipt, report what was actually done. Atlas records it in the signed audit log and flags any effect the receipt did not cover. One commit per receipt. |
| atlas_receipt_statusA | Check a receipt: ready, pending_approval (escalated, waiting for a human), rejected, denied, committed, expired, or revoked (a grant behind it was revoked). Approval can only be given by a human through the atlas-mcp CLI, never through this server. |
| atlas_verify_auditA | Verify the audit log's SHA3-256 hash chain and ML-DSA-65 signatures. Reports the first broken entry, if any. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool maps to a distinct stage of the authorization lifecycle: request a decision, report an effect, query a receipt, and verify the audit log. There is no plausible way to confuse atlas_authorize with atlas_commit_effect or atlas_receipt_status given their descriptions.
All four tools use a uniform atlas_ prefix with a clear verb_noun pattern (authorize, commit_effect, receipt_status, verify_audit). Naming is predictable and self-describing.
Four tools exactly cover the permit-check-commit-verify loop without redundancy. Nothing feels padded or missing at the surface level.
The core consequential-action flow (authorize, commit, status, audit verification) is fully covered, including escalation and revocation states. Minor gaps exist for discovery operations like listing receipts or checking pending approvals in bulk, which agents would have to work around with known receipt_ids.