Skip to main content
Glama
Ola-Turmo

@humanaccepted/mcp

by Ola-Turmo

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

  1. Sits in front of your agent's tool layer as a passthrough MCP server.

  2. Wraps every tools/call in a before → after pair of signed receipts:

    • Start receipt (kind: "tool_call", duration_ms: 0) — captures intent + inputs.

    • End receipt — captures output + duration + ok | error | timeout | denied result.

  3. Chains both via chain.prev so an auditor can replay the full session in order.

  4. Generates a stable run_id per 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/mcp

To 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

HUMANACCEPTED_API_KEY

yes

Tenant sk_… from POST /v1/bootstrap

HUMANACCEPTED_BASE_URL

no

https://humanaccepted.ola-turmo.workers.dev

Override for staging / local Worker

HUMANACCEPTED_AGENT_ID

no

mcp_agent

Stable id across the session (good for dashboards)

HUMANACCEPTED_AGENT_TYPE

no

mcp

e.g. claude-sonnet-4.6, openai:gpt-5.5, cursor-2.0


What it exposes

This MCP server exposes one meta-tool:

  • humanaccepted_session_info — returns the current session's run_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.ts

Or build:

npm run build && npm start

Tests:

HUMANACCEPTED_API_KEY=sk_... \
  HUMANACCEPTED_BASE_URL=http://127.0.0.1:8789 \
  npm test

Repo layout

Path

Purpose

src/server.ts

MCP server implementation — wraps tools/call, emits receipts

src/cli.ts

Thin entrypoint (#!/usr/bin/env node)

dist/

Built JS for npx + bin: humanaccepted-mcp

test/server.test.mjs

Boot + tools/list smoke test

package.json

@humanaccepted/mcp v0.1.0, Apache-2.0

tsconfig.json

ES2022, strict, outDir dist/


Project

What it is

Ola-Turmo/humanaccepted-spec

Open spec v1.1 — receipt shapes, canonical form, verifiers in 5 languages

Ola-Turmo/humanaccepted

Host product — Worker + Pages app (PR #6 ships v0.3 with these receipt kinds)

Live Worker

https://humanaccepted.ola-turmo.workers.dev/ — the registry this server writes to

Live host product

https://humanaccepted-new.pages.dev/ — dashboard + docs UI

Landing page (this repo)

site/index.html — single-file CF Pages marketing page


License

Apache-2.0

Available Tools

1 tool
humanaccepted_session_infoA

Returns information about the current HumanAccepted session — run_id, receipt count, and the tenant's public key (for offline verification).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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. 1 tool updatev0.1.0
    • First observedhumanaccepted_session_info

TDQS

A4.1/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityStale
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    MCP 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
  • A
    license
    Not graded
    quality
    C
    maintenance
    MCP server providing immutable audit logging, policy enforcement, and compliance reporting for AI agent workflows, enabling regulatory compliance and chain integrity verification.
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A 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.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    An 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

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