@humanaccepted/mcp
Provides tamper-evident receipt logging for tool calls made by OpenAI agents (e.g., GPT models) when used via MCP, supporting EU AI Act compliance.
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., "@@humanaccepted/mcpshow me my session info"
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.
humanaccepted-mcp
MCP server that emits signed, EU AI Act Article 12-compliant receipts on every AI tool call.
Drop-in Model Context Protocol server. Every tools/call your agent makes — through Claude Desktop, Cursor, or any MCP-compatible host — is wrapped and emitted as a signed tool_call receipt into the HumanAccepted registry, chained to the previous receipt in the session, and verifiable offline against the public Python / TypeScript reference verifiers.
A single line of MCP config, no code changes, no host rewrites.
What it does
Sits in front of your agent's tool layer as a passthrough MCP server.
Wraps every
tools/callin abefore → afterpair of signed receipts:Start receipt (
kind: "tool_call",duration_ms: 0) — captures intent + inputs.End receipt — captures output + duration +
ok | error | timeout | deniedresult.
Chains both via
chain.prevso an auditor can replay the full session in order.Generates a stable
run_idper MCP session for end-to-end traceability.
All receipts are signed with the tenant's Ed25519 key inside the HumanAccepted Worker. The MCP server itself holds no private key material — it authenticates with Bearer sk_... and the Worker does the signing.
Related MCP server: agent-audit-trail
Quick start
# 1. Get an API key (one-time, returns a tenant + sk_…)
curl -X POST https://humanaccepted.ola-turmo.workers.dev/v1/bootstrap
# 2. Run the MCP server (npx pulls it from npm; no local install needed)
HUMANACCEPTED_API_KEY=sk_... \
npx -y @humanaccepted/mcpTo use it in Claude Desktop or Cursor, add this to your MCP config:
{
"mcpServers": {
"humanaccepted": {
"command": "npx",
"args": ["-y", "@humanaccepted/mcp"],
"env": {
"HUMANACCEPTED_API_KEY": "sk_...",
"HUMANACCEPTED_AGENT_ID": "my_agent",
"HUMANACCEPTED_AGENT_TYPE": "claude-sonnet-4.6"
}
}
}
}The server connects on stdio, prints [humanaccepted-mcp] Connected to … to stderr, and from that point every tool call your agent makes is recorded.
Configuration
Env var | Required | Default | Purpose |
| yes | — | Tenant |
| no |
| Override for staging / local Worker |
| no |
| Stable id across the session (good for dashboards) |
| no |
| e.g. |
What it exposes
This MCP server exposes one meta-tool:
humanaccepted_session_info— returns the current session'srun_id, last receipt id, base URL, agent id, and tenant key fingerprint. Useful for debugging and for letting downstream code correlate receipts to a session.
All other tools/call requests are passed through but wrapped: the upstream tool still runs as normal, and a tool_call receipt pair is emitted to HumanAccepted for each invocation.
Receipt shape
Receipts follow HumanAccepted spec v1.1 (kind: "tool_call" was added in v1.1). A minimal example of the before half:
{
"kind": "tool_call",
"version": 2,
"tenant": "ten_3K9F2X",
"id": "rcp_4PZ8QJ2M1X9Y7K0ABCDEF1234",
"issued_at": "2026-06-28T09:53:11.421Z",
"agent": {
"id": "my_agent",
"type": "claude-sonnet-4.6",
"run_id": "run_01HF3R8K2Q5P9X7Z4M6V0YJWBN"
},
"tool": {
"name": "get_weather",
"version": "1.0.0",
"input": { "city": "Oslo" },
"output": null,
"duration_ms": 0,
"result": "ok"
},
"chain": { "prev": null, "run_id": "run_01HF3R8K2Q5P9X7Z4M6V0YJWBN" },
"canonical": "ha:v1:tool_call:ten_3K9F2X:rcp_4PZ…:{…sorted-utf8-json…}",
"signature": {
"alg": "ed25519",
"key_id": "k_8N4Q",
"value": "7c3f…(ed25519 sig over canonical)"
}
}The after half repeats the same envelope with duration_ms > 0, the actual output, and chain.prev = rcp_4PZ… (the start receipt's id).
Verify offline:
# Python
python3 -m verifier.python.verify --receipt rcp_4PZ... --pubkey <tenant-ed25519-pub>
# TypeScript
npx @humanaccepted/verify --receipt rcp_4PZ... --pubkey <tenant-ed25519-pub>EU AI Act Article 12
Article 12 of the EU AI Act requires providers of high-risk AI systems to keep automatic, tamper-evident logs of every interaction over the system lifecycle. The deadline is 2 August 2026 — 35 days from today (2026-06-28).
HumanAccepted is the open primitive for Article 12. The MCP server here is the drop-in layer: any MCP-compatible agent — Claude Desktop, Cursor, Claude Code, your custom host — gets Article 12 logging with one block of MCP config and zero changes to the agent code.
After running your agent for any length of time, fetch the full session's receipts:
curl https://humanaccepted.ola-turmo.workers.dev/v1/article12-export \
-H "Authorization: Bearer $HUMANACCEPTED_API_KEY" \
| jq '.counts, (.receipts | length)'Or replay one session:
curl https://humanaccepted.ola-turmo.workers.dev/v1/runs/$RUN_ID \
-H "Authorization: Bearer $HUMANACCEPTED_API_KEY" \
| jq '.chain_valid, .count'Local development
The repo ships TypeScript source in src/ (entry: src/server.ts) and a built dist/ for npx.
git clone https://github.com/Ola-Turmo/humanaccepted-mcp
cd humanaccepted-mcp
# Workaround for openclaw-user npm issues on shared VPS:
npm install --prefix /tmp/mcp-dev --cache /tmp/mcp-dev/.npm-cache
NODE_PATH=/tmp/mcp-dev/node_modules node --import tsx src/server.tsOr build:
npm run build && npm startTests:
HUMANACCEPTED_API_KEY=sk_... \
HUMANACCEPTED_BASE_URL=http://127.0.0.1:8789 \
npm testRepo layout
Path | Purpose |
| MCP server implementation — wraps |
| Thin entrypoint ( |
| Built JS for |
| Boot + |
|
|
| ES2022, strict, outDir |
Related projects
Project | What it is |
Open spec v1.1 — receipt shapes, canonical form, verifiers in 5 languages | |
Host product — Worker + Pages app (PR #6 ships v0.3 with these receipt kinds) | |
Live Worker |
|
Live host product |
|
Landing page (this repo) |
|
License
Apache-2.0
Available Tools
1 toolhumanaccepted_session_infoA
Returns information about the current HumanAccepted session — run_id, receipt count, and the tenant's public key (for offline verification).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 of behavioral disclosure. The verb 'Returns' implies a read-only operation, but the description does not explicitly state side effects, safety, or prerequisites. For a simple info tool this is acceptable, but it leaves some transparency gaps.
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?
The description is a single, well-structured sentence that front-loads the main point and efficiently lists the returned items. Every word earns its place, with no 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?
Given the tool's low complexity and lack of an output schema, the description provides a good summary of the returned fields. It could be more explicit about the output format, but the three named items give the agent sufficient context for most use cases.
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?
The input schema has zero parameters, so there is nothing to explain. The baseline score for zero parameters is 4, and the description does not need to add parameter information.
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 clearly states 'Returns information about the current HumanAccepted session' with a specific verb and resource, and enumerates the exact contents (run_id, receipt count, tenant's public key). This leaves no ambiguity about what the tool does.
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?
There are no sibling tools or explicit guidance on when to use this tool. The purpose implies usage when session details are needed, but the description lacks any exclusions or alternative references, making the usage context only implied rather than explicitly stated.
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. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
humanaccepted_session_info
TDQS
There is only one tool, so there is no possibility of confusion or overlap. The tool's purpose is clearly defined and distinct by virtue of being the sole tool.
With a single tool, there is no pattern to violate. The name 'humanaccepted_session_info' is descriptive and follows a clear noun-based convention, which is internally consistent.
A single tool is on the thin side, but for a narrowly scoped server focused solely on session info, it is acceptable. The tool earns its place, though there is only one.
The tool fully covers the stated purpose of returning session information. Minor gaps could include related operations like verifying receipts, but within the narrow domain of 'session info' it is complete.
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 Connectors
AI governance MCP server for EU AI Act compliance and jurisdiction verification
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMCP server for AI compliance auditing. Scores agent outputs for hallucination liability under the EU AI Act, issues verifiable compliance stamps, and tracks audit history by agent.MIT
- AlicenseNot gradedqualityCmaintenanceMCP server providing immutable audit logging, policy enforcement, and compliance reporting for AI agent workflows, enabling regulatory compliance and chain integrity verification.MIT
- FlicenseNot gradedqualityDmaintenanceA paid, hosted MCP server that acts as a witness layer for AI agent tool calls, providing receipt creation, approval evidence, argument redaction, result summaries, and audit exports.-
- AlicenseNot gradedqualityCmaintenanceAn MCP server that provides append-only, tamper-evident local receipts for AI agent actions, capturing command executions, outputs, and handoff evidence.MIT
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/Ola-Turmo/humanaccepted-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server