EvidentTrail MCP
Allows GitHub Copilot to call the et_log_action MCP tool to record its actions for EvidentTrail audit trails.
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., "@EvidentTrail MCPlog that I updated src/config.ts"
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.
EvidentTrail MCP
EvidentTrail compliance evidence collector for AI coding agents (Claude Code, GitHub Copilot, Cursor, Windsurf).
Runs two servers simultaneously:
HTTP server (default port 3100) — receives Claude Code PostToolUse hook events
MCP stdio server — exposes an
et_log_actiontool that Copilot, Cursor, and Windsurf can call directly
Both servers feed into a shared session buffer that flushes to the EvidentTrail ingestion API, where the entries become a tamper-evident (SHA-256 hash-chained) audit trail linked to your pull requests.
Before you start
You need:
Node.js 20 or newer and git
An EvidentTrail account with the GitHub App installed on the repository you want to govern
An API key (
et_live_...) — create one in the EvidentTrail app under Settings → API KeysThe repository ID (UUID) of that repository in EvidentTrail
Related MCP server: Agent Audit Trail MCP Server
Installation
The server is installed from source. There is no npm package yet.
git clone https://github.com/elvirus839/evidenttrail-mcp.git
cd evidenttrail-mcp
npm ci
npm run buildThis produces dist/index.js. Note the absolute path to it — the configuration below refers to it as <path-to>/evidenttrail-mcp/dist/index.js.
To update later:
git pull
npm ci
npm run buildDependency install scripts are disabled by the bundled .npmrc (ignore-scripts=true), so npm run build must be run explicitly.
Configuration
All configuration is via environment variables:
Variable | Required | Default | Description |
| ✅ | — | Base URL of the EvidentTrail API, e.g. |
| ✅ | — | Long-lived API key ( |
| ✅ | — | UUID of the repository being worked on |
|
| Display name for the agent | |
| — | Optional version string | |
| — | Optional model ID, e.g. | |
|
| HTTP hook server bind address. Warning: non-localhost values expose an unauthenticated | |
|
| HTTP hook server port |
Keep the API key out of version control. If you commit an MCP config file to a shared repository, reference the key from your shell environment rather than pasting it in.
Usage as an MCP server (Claude Code, Copilot CLI, Cursor, Windsurf)
Add this block to your agent's MCP configuration file:
{
"mcpServers": {
"evidenttrail": {
"command": "node",
"args": ["<path-to>/evidenttrail-mcp/dist/index.js"],
"env": {
"EVIDENTTRAIL_API_URL": "https://evidenttrail-api.fly.dev",
"EVIDENTTRAIL_API_KEY": "et_live_...",
"EVIDENTTRAIL_REPOSITORY_ID": "your-repo-uuid",
"EVIDENTTRAIL_AGENT_NAME": "claude-code"
}
}
}
}Agent | Config file | Suggested |
Claude Code |
|
|
GitHub Copilot CLI |
|
|
Cursor |
|
|
Windsurf |
|
|
The agent starts and stops the server itself. Agents then call the et_log_action tool to record what they do:
await agent.callTool('et_log_action', {
actionType: 'FileWrite',
actionDetail: 'Updated src/config.ts',
outputSummary: 'Configuration file updated successfully'
});To make logging consistent, tell the agent to do it in its instruction file (CLAUDE.md, AGENTS.md, .github/copilot-instructions.md, …), for example: "Call et_log_action after every file write, command execution, and external API call."
Usage with Claude Code hooks (automatic capture)
With the PostToolUse hook, every Claude Code tool call is captured automatically — the agent does not have to remember to log.
Start the server in a terminal and leave it running:
EVIDENTTRAIL_API_URL=https://evidenttrail-api.fly.dev \ EVIDENTTRAIL_API_KEY=et_live_... \ EVIDENTTRAIL_REPOSITORY_ID=your-repo-uuid \ node <path-to>/evidenttrail-mcp/dist/index.jsPowerShell:
$env:EVIDENTTRAIL_API_URL = "https://evidenttrail-api.fly.dev" $env:EVIDENTTRAIL_API_KEY = "et_live_..." $env:EVIDENTTRAIL_REPOSITORY_ID = "your-repo-uuid" node <path-to>\evidenttrail-mcp\dist\index.jsAdd the hook to
.claude/settings.json:{ "hooks": { "PostToolUse": [{ "matcher": ".*", "hooks": [{ "type": "http", "url": "http://localhost:3100/hook" }] }] } }Stop the server with
Ctrl+Cwhen the session is done so the final entries are sent.
Check that it works
curl http://localhost:3100/health{ "status": "ok", "sessionId": "..." }Within about a minute of the first tool call, the session appears under Agent Sessions in the EvidentTrail app.
Session lifecycle
On startup a UUID
sessionIdis generated for the process lifetime and aSessionStartentry is bufferedEach tool call increments a sequence counter and appends to the buffer
The buffer is flushed to the API when it reaches 20 entries, every 60 seconds, and when the Claude Code session ID changes. Each batch carries the hash of the previous one, so the backend keeps a single hash chain per session
A failed flush is retried once, then the entries are kept and retried on the next flush — logging never blocks the agent
On
SIGTERM/SIGINTaSessionEndentry is appended, the remaining buffer is flushed, and the process exits
If the process is killed without a signal (crash, kill -9), entries buffered since the last flush are lost and the session has no SessionEnd entry. If the API is unreachable for long enough that 999 entries accumulate, further entries are dropped.
ActionType mapping (HTTP hook)
Tool name | ActionType |
|
|
|
|
|
|
|
|
anything else |
|
Privacy
triggerDescription is always null — conversation transcript content is never sent to the API.
Input and output summaries are truncated to 500 characters.
Development
npm ci
npm test
npm run devLicense
Available Tools
1 toolet_log_actionA
Log an agent action as compliance evidence in EvidentTrail. Call this whenever you perform a significant action (file edit, API call, decision).
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | No | Optional model ID (e.g. claude-sonnet-4.6). Set on the first call; applies to all subsequent flushes in this session. | |
| actionType | Yes | ActionType name: FileWrite, FileRead, FileDelete, ToolInvocation, ApiCall, Decision, SessionStart, SessionEnd, Custom | |
| actionDetail | Yes | Short human-readable description of the action (e.g. tool or file name) | |
| inputSummary | No | Optional summary of inputs (max 500 chars) | |
| outputSummary | No | Optional summary of outputs (max 500 chars) |
TDQS
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 conveys the key behavioral trait that the entry becomes persistent compliance evidence, but discloses nothing about permissions, durability/flushing, failure behavior, or latency. The buffering hint ("subsequent flushes in this session") appears only in the schema, not the description.
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?
Two sentences, zero filler, with the purpose front-loaded and the invocation trigger immediately after. Every sentence earns its place.
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?
For a 5-parameter write tool with no output schema and no annotations, the description covers purpose and when to call it, and the schema fills in field-level detail. It omits session/flush semantics and the fact that modelId only needs to be set once, which are relevant operational facts.
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?
Schema description coverage is 100% with 5 parameters, so the schema already documents every field including enum-like actionType names and the 500-char limits. The description adds no syntax, format, or default information beyond what the schema provides, so the 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 specific verb ("Log") and resource ("an agent action as compliance evidence in EvidentTrail"), so an agent immediately knows this writes an audit record. With no sibling tools present, there is nothing to differentiate from, so the lack of alternative routing costs it the top mark rather than reflecting vagueness.
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?
"Call this whenever you perform a significant action" gives explicit trigger conditions and even parenthetical examples (file edit, API call, decision) that map onto the actionType values. It stops short of stating when-not to call it (e.g. trivial/read-only steps) or any batching guidance.
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
v1.0.0- First observed
et_log_action
TDQS
Scored across 1 tool
With a single tool there is no possibility of misselection; the tool's purpose (logging an agent action as compliance evidence) is unambiguous and clearly stated. No overlap risk exists in the current surface.
The name et_log_action follows a clear, predictable snake_case verb_noun pattern with a consistent server prefix. Though there is only one tool, the convention is well-defined and would scale cleanly.
A single tool is extremely thin for a compliance-evidence server, which typically implies writing, querying, and verifying records. One write-only operation cannot cover the apparent scope of the domain.
The surface only supports appending evidence; there is no way to retrieve, search, list, verify, or export logged actions. These gaps would leave an agent unable to confirm or audit what was recorded, a dead end for a compliance workflow.
Maintenance
Related MCP Connectors
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...
Runtime permission, approval, and audit layer for AI agent tool execution.
Etch is a signed audit chain for AI agent decisions, offline-verifiable against pinned public keys.
Related MCP Servers
- AlicenseAqualityAmaintenanceChange tracking for AI-era codebases. AI agents call it to log structured change events (entity + diff + reasoning) before the session ends, then query history with diff, blame, history, changeset, and search. Captures the intent that would otherwise evaporate.8205 PyPI24MIT
- AlicenseNot gradedqualityFmaintenanceProvides tamper-proof audit logging for AI agents using SHA-256 hash chains, integrity verification, and compliance reporting for the EU AI Act.1MIT
- AlicenseNot gradedqualityCmaintenanceProvides an immutable, tamper-evident audit trail for AI agents, enabling event logging with cryptographic chaining, search, verification, and statistics.3MIT
- AlicenseNot gradedqualityCmaintenanceProvides permission gates and tamper-evident audit logging for AI agent tool executions, with declarative policies, consent ladders, and hash-chained verification.MIT