Witness
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., "@Witnesscreate an append-only audit record with my agent's signature"
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.
Witness Evidence
Open Evidence Layer for Agentic Systems
Your agents can act. Witness preserves what was decided, which evidence was attached, and what the next agent may inherit.
AI agents can act. Witness makes their work accountable.
Agents are becoming a software workforce. Their accepted truth is still too often trapped in a chat log: a planner chooses a direction, a builder reports “done,” a validator arrives later, and the next model has to reconstruct why anyone trusted the result.
Witness Evidence is for agent-platform and AI-infrastructure engineers whose agents, models, and traces are growing faster than their ability to preserve accepted project state. It records identity-bound decisions, attached evidence, outcomes, lifecycle changes, and bounded project context through MCP.
Delegate execution without delegating truth.
Run the real local demo of the v0.1.0 core · See what runs today · Explore the capability roadmap · Inspect proof status
Related MCP server: Cruxible Core
Where Witness fits
MCP connects agents to tools.
A2A connects agents to agents.
Traces show what ran.
Durable runtimes keep workflows alive.
Witness preserves what was decided, which evidence was attached, which status transitions followed, and what the next agent may inherit.Witness does not replace agent runtimes, tracing, orchestration, Git, or observability. It sits above execution detail as a durable evidence boundary: the place where a team records the decision it acted on, the result it produced, an evidence reference, the identity that performed each status transition, and the context a later agent is allowed to recover.
The failure mode
Without a shared evidence layer, a multi-agent system becomes a pile of confident transcripts:
Planner: “Build the release.”
Builder: “Done.”
Validator: “Which bytes? Which requirements? Why this design?”
Next run: “I have no context from the previous chat.”
Owner: reconstructs everything by hand.The durable object should not be the conversation. It should be the witnessed project state.
Runs today
Version 0.1.0 executes a local, open-source evidence core:
10 MCP tools for projects, decisions, insights, outcomes, records, lifecycle, bounded context, and FTS5 search;
signed agent identity envelopes bound to the exact tool, request payload, tenant, profile, runtime generation, and nonce;
role-based default-deny access and idempotent mutations;
privacy redaction before persistence;
SQLite persistence with transactional append-only operations audit;
a real local flow with separate builder and validator identities;
reproducible Apache-2.0 release artifacts and a staged fresh-install doctor.
In the included demo, a distinct synthetic validator identity moves the outcome to verified. The transition records that actor and its reason. Version 0.1.0 does not enforce builder/validator separation, expose the outcome's based_on evidence reference through the public read projection, fetch the referenced artifact, or decide correctness automatically. This is not automatic evidence verification.
See the system move
sequenceDiagram
actor Owner
participant Planner
participant Builder
participant Validator
participant Witness
participant NextAgent as Next agent / model
Owner->>Planner: Ship a validated release
Planner->>Witness: Record decision + acceptance rule
Planner->>Builder: Build exact candidate
Builder->>Witness: Record outcome + evidence reference
Validator->>Witness: Read decision and outcome
Validator->>Witness: Accept or dispute the result
NextAgent->>Witness: Restore bounded project context
Witness-->>NextAgent: Decision + outcome + acceptance stateThe repository includes a real local MCP flow. It creates a temporary database, uses separate signed synthetic builder and validator identities, writes a decision and outcome, moves the outcome from recorded to verified, and restores project context.
[1/3] Decision recorded: require independent validation
[2/3] Outcome verified by a distinct validator identity
[3/3] Project context restored from the database
WITNESS_DEMO_PASS decisions=1 outcomes=1 outcome_status=verified distinct_validator=true context_restored=trueEvidence class: real local product flow. The demo executes the public MCP server and persistence layer with synthetic credentials. It is not a cloud screenshot, a simulated response, or proof of an external integration.
Run the real demo
git clone https://github.com/MaximilianoColoma/witness.git
cd witness
uv sync --locked
uv run python examples/coordinated_autonomy_demo.pyExpected final line:
WITNESS_DEMO_PASS decisions=1 outcomes=1 outcome_status=verified distinct_validator=true context_restored=trueWhat this enables
Accountable builders
A builder can produce work and a different identity can perform the later review transition, as the demo shows. Teams must enforce any required builder/validator separation in their own policy until Witness adds that invariant.
Model-independent continuity
Replace the model, restart the process, or resume next week. A later agent can retrieve bounded project objects instead of reverse-engineering an old transcript.
Evidence-aware gates
Decisions, outcomes, receipts, and status transitions become queryable inputs to CI, release governance, incident review, and human approval.
Memory with boundaries
Witness is not a transcript dump or a generic RAG store. It persists declared project objects, redacts supported PII before persistence, bounds reads, and denies undeclared authority.
Audit that ordinary product calls cannot casually rewrite
Public-core mutations and audit events commit together or not at all. Canonical triggers protect operations history from update and deletion through the normal application path.
Building next
Cross-model project continuity
The next developer capability is a portable continuity contract: Claude, Codex, GPT, local models, and specialist agents should be able to use the same bounded Witness project state and continue work without access to the original chat.
This is planned, not yet externally proven. The proof requires a different agent team to reconstruct the current decision, attached evidence, and acceptance state; reconstruction time and failure cases must be measured. See EVIDENCE.md.
No first-party adapters for Claude, Codex, OpenAI Agents SDK, LangGraph, or Temporal ship in v0.1.0. Today those systems can reach Witness only through custom MCP/client wiring built by the integrator. Documented reference adapters are roadmap work, not current functionality.
North star
Witness aims to become the open evidence and learning infrastructure through which an agent organization retains what it decided, proved, and learned across agents, models, runs, and systems.
That north star includes portable verification and verified learning return: accepted outcomes may inform later work without allowing unverified text to silently become policy. It is not automatic cross-model learning in v0.1.0.
Two-product architecture
Mission is a separate product. Spindle is the planned learning function inside Witness.
Mission coordinates agent work. Witness preserves evidence and is designed to compound verified learning.
flowchart LR
H["Human<br/>goal and direction"] --> M["Mission<br/>coordinates"]
M --> G["Specialist agents<br/>work"]
G --> E
subgraph W["Witness"]
E["Decision · Outcome · Evidence"] --> S["Spindle<br/>planned learning function"]
S --> L["Patterns · Rules · Guards"]
end
L -. "future governed return" .-> MThe Evidence Core runs today. The full Spindle learning loop is planned. Its future job inside Witness is to take outcomes in Witness's verified lifecycle status and, after additional eligibility and review gates, turn them into governed learning candidates, reusable patterns, rules, and guards for later Mission runs. The status records an acceptance transition; it does not by itself prove that Witness fetched or independently validated the underlying evidence. Version 0.1.0 does not generate those artifacts or feed them back automatically.
Dream functions
These are enabled patterns, not bundled orchestration today:
cross-model continuity without transcript access;
portable proof that an external validator can inspect without trusting the builder’s narration;
verified learning return through Spindle, the planned internal Witness learning function;
owner-readable autonomy with a durable decision chain;
incident memory that carries accepted root cause and prevention into later missions.
Every token should leave the system more valuable than before. That is the product direction, not a current efficiency or economic claim.
Mission and Witness are the two main products. Mission coordinates work; Witness owns the evidence boundary and the planned Spindle learning function. No automatic Witness-to-Mission learning return ships in v0.1.0.
Built now — and not yet
Runs in v0.1.0 | Building next / later |
10 MCP tools and local SQLite persistence | First-party Claude, Codex, OpenAI Agents SDK, LangGraph, and Temporal recipes |
Signed identity envelopes and request binding | Externally proven cross-model continuity |
Role-based default-deny access | Portable external artifact verification |
PII redaction and bounded reads | Multi-tenant hosted service |
Transactional append-only operations audit | Full Spindle learning loop inside Witness |
Real local demo of the release-core source; reproducible v0.1.0 assets | Automatic Mission bridge, SaaS, billing, or customer outcomes |
The service is not deployed by this repository. Publication and green CI do not prove production operation, scale, savings, or user impact.
Public MCP surface
Intent | Tools |
Establish a project |
|
Preserve reasoning |
|
Preserve results and receipts |
|
Govern lifecycle |
|
Restore context |
|
Inspect history |
|
Canonical contracts live under spec/. FTS5 is local text search, not semantic or vector search.
Install and verify
Requires Python 3.11+ and uv.
./install.sh --manifest --json
./install.sh --target "$HOME/.local/share/witness" --non-interactive --json
uv sync --locked
uv run python -m pytest -q -p no:cacheprovider tests repair-tests
uv buildThe staged installer scrubs inherited Python environment variables, performs a locked installation, writes bounded local configuration and storage, and runs a real MCP first-run doctor.
Naming and technical identity
Witness Evidence is the public-facing qualifier; technical identifiers remain unchanged. The repository MaximilianoColoma/witness, package witness-public, Python module witness_public, MCP tool names, contracts, and released v0.1.0 artifacts keep their existing technical identifiers. In short: the story is clearer; the wire stays put.
An unrelated established project also uses the name Witness. See TRADEMARKS.md for the anti-confusion notice.
Project center
Capability roadmap:
ROADMAP.mdEvidence and proof status:
EVIDENCE.mdGovernance and release authority:
GOVERNANCE.mdContributions and DCO:
CONTRIBUTING.mdSecurity reporting:
SECURITY.mdSupport boundaries:
SUPPORT.mdNaming and anti-confusion:
TRADEMARKS.md
License
Licensed under the Apache License 2.0. See NOTICE. Apache-2.0 permits use, modification, redistribution, and commercial use; it does not grant permission to imply official project status or trademark endorsement.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides covenant rule enforcement, hash-chained audit logs, and integrity verification for MCP-compatible agents. It enables users to define granular permission rules and maintain a tamper-evident audit trail of all actions.4211MIT

Cruxible Coreofficial
AlicenseNot gradedqualityAmaintenanceDeterministic decision engine with DAG-based receipts. Build entity graphs, query with MCP, get auditable proof.15Apache 2.0- AlicenseNot gradedqualityDmaintenanceMCP server for temporal state queries and cryptographic audit trails. Query historical entity state at any point in time, generate Merkle proofs of past state, and anchor contract snapshots for immutable provenance.MIT
- AlicenseNot gradedqualityCmaintenanceEvidence-first delivery audit MCP server that evaluates task requirements against delivery evidence and returns a reproducible pass/needs_review/fail decision with a deterministic receipt.MIT
Related MCP Connectors
Read-only Remote MCP for externally grounded AI agent trust receipts.
Tamper-evident audit log service for agent-to-agent transactions
The evidence layer for MCP: live operational grades plus Trust Receipts for every registry server.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MaximilianoColoma/witness'
If you have feedback or need assistance with the MCP directory API, please join our Discord server