What can you do with this server?

The DarkMatter MCP Server lets you create and manage tamper-evident, verifiable audit trails of AI agent decisions and actions using Context Passport records. * darkmatter_commit — Record an agent's input, output, and metadata (role, model, provider, agent identity, trace ID, event type, etc.), creating a hash-chained, tamper-evident Context Passport. * darkmatter_verify — Check the integrity of a session's hash chain, either in full or up to a specific passport ID, to detect tampering. * darkmatter_replay — Walk through all committed records for a session in chronological order, retrieving full payloads. * darkmatter_export — Produce a self-contained JSON bundle of an entire session's chain for third-party verification without external dependencies. * darkmatter_list_sessions — List all session IDs that have at least one Context Passport stored locally. Records are stored locally by default, with an option to forward them asynchronously to a DarkMatter receiving server. The server integrates with MCP-compatible clients (e.g., Claude Code, Cursor, ChatGPT Desktop) and supports auto-capture adapters for recording every tool call and turn boundary automatically.

Which integrations are available for this server?

Planned auto-capture integration for OpenAI Codex to record all agent decisions and actions as Context Passport records.

How do I use DarkMatter MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DarkMatter MCP Server Record approval for refund order #1247" 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.

DarkMatter MCP Server

Official

by darkmatter-hub

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

DarkMatter MCP Server

Universal MCP server that emits Context Passport records for AI agent decisions and actions. Drop into any MCP-compatible client (Claude Code, Cursor, Cline, Continue, ChatGPT Desktop, Zed, Goose, and others) to give your agent a commit / verify / replay / export toolset for verifiable, tamper-evident records.

Built by DarkMatter. Implements Context Passport v2.0, an open CC0 standard. Records emitted by this server use RFC 8785 (JCS) canonicalization and are byte-equivalent across the Python and TypeScript reference SDKs.

Install

In your MCP client's config (claude_desktop_config.json, Cursor's mcp.json, etc.):

{
  "mcpServers": {
    "darkmatter": {
      "command": "npx",
      "args": ["-y", "@darkmatterhub/mcp-server"]
    }
  }
}

Restart the client. Five tools become available to your agent:

darkmatter_commit — record an agent decision or action
darkmatter_verify — check that the chain has not been tampered with
darkmatter_replay — walk the full chain in order
darkmatter_export — produce a portable proof bundle
darkmatter_list_sessions — see what sessions exist locally

Related MCP server: anthropic_skill

Bundles explain themselves

darkmatter_export produces a bundle that a stranger can act on. Alongside the records it carries the format name, a link to the specification, whether the chain was intact at export time, and the exact command to verify it in Python or TypeScript, plus what a failure looks like.

That matters because the bundle is the artifact that leaves your machine. It goes to an auditor, a regulator or a counterparty who has never heard of this format, and the whole claim is that they can check it without trusting whoever sent it. A bundle that does not say how is asking to be trusted.

Local by default, published when you ask

With no configuration the server keeps every record on your own disk. The chain verifies offline through darkmatter_verify, so you can evaluate the whole idea without an account.

Set an API key to publish records and get a link somebody else can check:

Variable	Effect
`DARKMATTER_API_KEY`	Publishes each record to DarkMatter and returns a `verify_url`. Get one at darkmatterhub.ai.
`DARKMATTER_SHARE`	Set to `true` to make published records readable by anyone with the link. Off by default, because publishing is not something to do to your records without being asked.
`DARKMATTER_API_URL`	Override the API host. Defaults to `https://darkmatterhub.ai`.
`DARKMATTER_MCP_STORE_DIR`	Where local records are written.

commit reports which of the two happened, in the storage field. If publishing fails the record is still committed locally and the error is returned alongside it, so a network problem cannot cost you the record.

Changed in 0.3.0. Earlier versions returned a https://darkmatterhub.ai/r/{id} link for every commit while making no network calls at all, so the link always 404ed. A verification URL is now returned only when there is a published record behind it.

What gets captured

Whatever the agent (or user) explicitly invokes via darkmatter_commit. Auto-capture of every tool call without explicit invocation is a separate component (see Auto-capture below).

Example agent flow:

User:    Approve the refund for order #1247 and record the decision.
Agent:   Calls refund_order(1247).
Agent:   Calls darkmatter_commit({
           input: "Approve refund for order #1247",
           output: "Approved. $84.00 refunded to original payment method.",
           role: "compliance",
           event_type: "commit"
         })
Result:  { ok: true, passport: {...}, storage: "local", verify_url: null,
           note: "Saved locally and verifiable offline..." }

The passport is signed (if a key is configured), hash-chained to the previous commit in the session, and stored locally at ~/.darkmatter/mcp/<session_id>/chain.jsonl.

Storage

Default: local-only. Passports never leave the machine.

~/.darkmatter/mcp/
├── default/
│   ├── chain.jsonl        # append-only stream of all commits
│   └── latest.json        # most recent passport (used as parent for the next)
└── <other-session-id>/
    └── ...

To forward each passport to a DarkMatter receiving server in addition to local storage, set:

export DARKMATTER_API_KEY="dm_sk_..."

The forwarding is best-effort and never blocks the agent's tool call. Local storage remains the source of truth.

Auto-capture

The MCP server captures only what the agent explicitly invokes. To auto-capture every tool call and turn boundary in a specific dev tool (without the agent having to remember to call darkmatter_commit), install one of the dev-tool-specific adapters:

darkmatter-hub/claude-code — auto-capture for Claude Code (Anthropic)
Cursor adapter — planned
OpenAI Codex adapter — planned
Aider adapter — community-built welcome

Each adapter hooks into its specific dev tool's event lifecycle and routes events through this MCP server's darkmatter_commit tool. One canonical endpoint, many capture surfaces.

Verification

Records are valid Context Passport v2.0 artifacts. Verify with any conformant implementation:

pip install context-passport context-passport-conformance
context-passport-conformance --level signed     # 9/9 vectors, no --vectors-dir needed

The conformance package ships its vectors inside the wheel, so this is a one-line check against the public reference suite.

Or use the offline reference verifier directly on the JSONL file:

import json
from context_passport import verify_chain

with open("~/.darkmatter/mcp/default/chain.jsonl") as f:
    chain = [json.loads(line) for line in f]

print(verify_chain(chain))  # True if intact, False if tampered

Why MCP

MCP (Model Context Protocol) is becoming the universal interop layer for AI tools. Writing this server once means it works in every MCP-compatible client without per-client integration code. See the Context Passport for MCP proposal for the broader architectural rationale.

License

Apache-2.0. See LICENSE.

The Context Passport schema this server implements is released separately under CC0 1.0 at github.com/contextpassport/spec.

github.com/contextpassport/spec — the open standard
github.com/contextpassport/python — Python reference SDK
github.com/contextpassport/typescript — TypeScript reference SDK
github.com/darkmatter-hub/claude-code — auto-capture for Claude Code
github.com/darkmatter-hub/darkmatter — DarkMatter receiving server

Available Tools

5 tools

darkmatter_commitA

Commit a Context Passport record of an agent decision or action. Returns a verifiable record id and verify_url. Use this when the agent makes a decision worth recording for later audit or verification.

ParametersJSON Schema

Name	Required	Description
`session_id`	No	Optional. Groups passports into a chain. Defaults to 'default'.
`input`	No	What the agent received (string or object).
`output`	No	What the agent produced (string or object).
`memory`	No	Optional. Persistent state / tool results.
`variables`	No	Optional. Named values for downstream agents.
`agent_id`	No	Optional. Identifier for the calling agent.
`agent_name`	No	Optional. Human-readable agent name.
`role`	No	Optional. Semantic role (researcher, writer, reviewer, etc).
`provider`	No	Optional. LLM provider (anthropic, openai, mistral, etc).
`model`	No	Optional. Model name.
`event_type`	No	Optional. One of: commit, fork, checkpoint, spawn, retry, timeout, error, override, consent, escalate, redact, audit. Defaults to 'commit'.
`trace_id`	No	Optional. Groups commits into a pipeline run.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully cover behavioral traits. It states the tool commits a record and returns an ID and URL, implying a write operation, but does not disclose idempotency, side effects, or if the record is append-only. Adding such details would improve transparency.

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 two sentences, front-loaded with the action and return values. No unnecessary words; every sentence adds value.

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 (12 parameters, no output schema, no annotations), the description is minimal. It explains the purpose and when to use, but does not define what a 'Context Passport' is or provide high-level guidance on parameter usage. The schema descriptions are thorough, but the description could be more 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 input schema has 100% description coverage for 12 parameters. The description adds no additional meaning beyond the schema descriptions, so it meets the baseline of 3 for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Commit' and resource 'Context Passport record', and specifies the return values (id and verify_url). This distinguishes it from sibling tools like darkmatter_export and darkmatter_verify.

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 explicitly says 'Use this when the agent makes a decision worth recording for later audit or verification', providing clear context for usage. It does not mention when not to use or alternatives, but the sibling tool names imply the distinctions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

darkmatter_exportA

Export a portable JSON bundle of the entire chain for a session. The bundle is self-contained and can be verified by any third party without contacting DarkMatter.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Optional. Defaults to 'default'.

TDQS

A3.6/5.0

Behavior2/5

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 mentions the output is self-contained and verifiable, but does not disclose side effects (e.g., is it read-only?), permissions, rate limits, or size constraints. Significant gaps remain.

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 two sentences, front-loaded with the core action, and contains no redundant information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description is fairly complete. It covers what is exported and the property of verifiability. A small gap: it could clarify what 'chain' means, but overall adequate.

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% and the description adds no meaning beyond the schema. The single parameter 'session_id' is adequately described in the schema as optional with default, so the description does not need to elaborate further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Export' and the resource 'portable JSON bundle of the entire chain for a session'. It uniquely identifies the tool's function and distinguishes it from siblings like darkmatter_commit, darkmatter_replay, and darkmatter_verify.

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 description implies usage for exporting a session chain but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or comparisons are provided, so the agent must infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

darkmatter_list_sessionsA

List all session ids that have at least one committed Context Passport in local storage.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It implies a read operation but does not mention side effects, authentication requirements, or performance characteristics.

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?

Single sentence with no wasted words. Front-loaded with action and resource.

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 simple tool with 0 parameters and no annotations or output schema, the description covers the core functionality. However, it omits the return format (e.g., array of IDs) and assumes domain knowledge of 'committed Context Passport'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so baseline 4 applies. The description explains what the tool does, which is sufficient given the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List'), the resource ('session ids'), and a condition ('with at least one committed Context Passport'), effectively distinguishing it from sibling tools like commit, export, replay, and verify.

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?

No explicit guidance on when to use or not use this tool versus alternatives, but the simple listing purpose is implied. No sibling listing tools exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

darkmatter_replayA

Walk the Context Passport chain for a session and return the full payload at each step in chronological order.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Optional. Defaults to 'default'.
`id`	No	Optional. Replay up to this passport id only.

TDQS

A3.5/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 full burden. It only states the action and output format, lacking details on side effects (likely read-only), authentication needs, rate limits, error handling, or behavior with missing sessions. Minimal behavioral disclosure.

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?

Single sentence, no fluff, front-loaded with the core action. Every word is necessary.

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?

No output schema, so description should clarify the 'full payload' format and whether pagination exists. Lacks information on edge cases (empty chain, invalid session). Adequate for simple tool but leaves gaps in return structure and error behavior.

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 input schema already describes both parameters (session_id with default, id as optional limit), covering 100%. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool replays the Context Passport chain for a session, returning full payloads in chronological order. It uses a specific verb ('Walk') and distinguishes itself from sibling tools (commit, export, list_sessions, verify) by focusing on replaying historical steps.

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 description implies the tool is for inspecting session history, but it provides no explicit guidance on when to use it versus alternatives (e.g., darkmatter_export for current state) nor when not to use it. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

darkmatter_verifyA

Verify the integrity of the Context Passport chain for a session. Returns true if the hash chain is intact and no records have been tampered with.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Optional. Defaults to 'default'.
`id`	No	Optional. Verify up to this passport id only.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Returns boolean indicating integrity; no annotations provided. Lacks disclosure on side effects, permissions, or error conditions.

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?

Two sentences, no unnecessary words, front-loaded with verb and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple verification tool with no output schema, description explains return value and purpose adequately; parameters fully described in schema.

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% with parameter descriptions; description adds no extra meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Verify the integrity of the Context Passport chain for a session', specifying the action and resource. It distinguishes from sibling tools like darkmatter_commit or darkmatter_export.

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?

Implies usage for checking integrity, but no explicit when-to-use or when-not-to-use guidance relative to sibling tools like darkmatter_replay.

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.

5 tool updatesv0.1.0May 19, 2026
- First observeddarkmatter_commit
- First observeddarkmatter_export
- First observeddarkmatter_list_sessions
- First observeddarkmatter_replay
- First observeddarkmatter_verify

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-05-19 01:25 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: committing a record, exporting a chain, listing sessions, replaying a chain, and verifying integrity. There is no functional overlap.

Naming Consistency5/5

All tools follow a uniform verb_noun pattern with the 'darkmatter_' prefix, e.g., darkmatter_commit, darkmatter_list_sessions. The naming is predictable and consistent.

Tool Count5/5

5 tools is well-scoped for a server focused on Context Passport management. Each tool serves a clear purpose without bloat or deficiency.

Completeness4/5

The set covers the core operations: create (commit), read (list_sessions, replay), verify, and export. Missing a direct 'get single record' tool, but the workflow is supported via replay and verify URLs from commits.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

connect B
ai.odei
Governed personal world model and memory for your AI agent. Pair once, connect over MCP.
Knowledge & Memory Autonomous Agents
72
AccordTrace A
io.github.Kosta1985
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Security AI & Machine Learning
91
Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

@citizenofthecloud/mcp-serverofficial
Security Autonomous Agents
citizenofthecloud
A
license
Not graded
quality
D
maintenance
MCP server for Citizen of the Cloud — agent identity verification, trust scoring, and registry access for any AI runtime that speaks the Model Context Protocol.
Updated 4 months ago (2026-05-15 21:21 UTC)
7 npm
MIT
anthropic_skill
Shell Access Code Execution
williamchek
F
license
Not graded
quality
D
maintenance
A robust, lightweight Model Context Protocol (MCP) server designed to empower your AI Agents with context-awareness, safe execution sandboxes, and dedicated thought logs.
Updated 5 months ago (2026-04-11 03:50 UTC)
-
AgentLens
Observability Monitoring AI & Machine Learning
agentkitai
A
license
A
quality
C
maintenance
AI-agent observability server whose distinguishing feature is a SHA-256 hash-chained, tamper-evident audit log with chain verification and signed export. Works with Claude Desktop, Cursor, and any MCP client.
Updated 7 days ago (2026-09-13 17:13 UTC)
22
2 npm
23
MIT
sagrada-mcp
AI & Machine Learning Knowledge & Memory Autonomous Agents
Cruxia-Labs
A
license
Not graded
quality
B
maintenance
MCP server for tracking and verifying AI reasoning state, with signed action receipts, repo-history records, and preflight gating for tool calls.
Updated a month ago (2026-08-20 01:25 UTC)
Apache 2.0

DarkMatter MCP Server

Install

Bundles explain themselves

Local by default, published when you ask

What gets captured

Storage

Auto-capture

Verification

Why MCP

License

Related repositories

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@citizenofthecloud/mcp-serverofficial