MCP server for HumanChain — AI agents pause for human expert guidance via the consult() tool.
Project description
humanchain-mcp
MCP server for HumanChain. Your AI agent pauses on a hard call and asks a real human expert, then continues with the answer. Exposes the async
consult_start/consult_statuspair (recommended) and a blockingconsultfast-path.
Wires HumanChain into any MCP-aware agent (Claude Desktop, Claude Code,
Cursor, Codex, Continue, …). When your agent hits a question that needs human
judgment, it fires a consult; a vetted human answers; the agent continues with
a grounded answer. If no human is available in time, an LLM fallback answers
in their place (unless you set require_human=true) — and the result always
tells you which of the two answered.
Full API reference: the /machine page on your configured HumanChain backend.
1. Install (pipx)
pipx install humanchain-mcp
pipx installs the server in its own isolated environment and puts a
humanchain-mcp command on your PATH — that command is what your agent runs.
Requires Python 3.10+.
- No pipx yet?
python -m pip install --user pipx && python -m pipx ensurepath, then open a new terminal. On Windows:py -m pip install --user pipxthenpy -m pipx ensurepath, then reopen the terminal. - Prefer plain pip?
pip install humanchain-mcpalso works — you'd then wire the server aspython -m humanchain_mcpinstead of thehumanchain-mcpcommand shown below.
Verify the command is on your PATH:
humanchain-mcp --version
2. Get your key
Mint an API key on the /developer page of your HumanChain backend. You see
it once. It is the only secret you need — and it goes in your agent's MCP
config (next step), not on a command line and not in your code.
3. Wire it into your agent
Add HumanChain to your agent's MCP config. The shared/team key goes in the
env block of this config — that is the one place it lives:
{
"mcpServers": {
"humanchain": {
"command": "humanchain-mcp",
"env": {
"HUMANCHAIN_API_KEY": "hc_your_key_here"
}
}
}
}
Restart the agent. Three tools appear: consult_start and
consult_status (the pair you'll use) and consult (a blocking
fast-path).
Where that config lives, by host:
| Host | Where the mcpServers block goes |
|---|---|
| Claude Desktop | claude_desktop_config.json — Settings → Developer → Edit Config |
| Claude Code | .mcp.json in your project, or claude mcp add humanchain humanchain-mcp |
| Cursor | .cursor/mcp.json in your project (or global MCP settings) |
| Codex / other MCP hosts | the host's mcpServers block; command + env exactly as above |
No MCP support in your host? Call the HTTP API directly (see /machine):
POST /api/agent/consult/start, then poll
GET /api/agent/consult/{id}/status, with header Authorization: Bearer hc_....
4. Your first consult — use the async pair
A human answer usually takes longer than an agent runtime's ~30-second tool-call limit, so the recommended pattern is start-then-poll:
consult_start(question="...")→ returns aconsult_job_idimmediately.consult_status(consult_job_id="...")→ poll every ~10s untilstatusisANSWERED(orTIMED_OUT/FAILED).
The result leads with a plain banner so you can tell at a glance whether a human or the LLM answered, and what they said:
=== HUMAN ANSWER (provenance: human) ===
A HUMAN expert answered this consult.
answered by: ... | confidence: 0.8 | latency: 41.0s
ANSWER:
<the human's answer>
--- structured result (machine-readable) ---
{ ...full JSON... }
…or, when no human was available in time:
=== LLM FALLBACK -- NOT a human (provenance: llm_fallback) ===
No human answered in time, so this answer was generated by an LLM, NOT a
human expert.
reason: no human available | confidence: 0.65
...
Common pitfall: don't re-start every turn (dropped thread)
Call consult_start once and keep the consult_job_id. Poll
consult_status with that same id until it is terminal. Calling
consult_start again on each turn opens a brand-new consult and loses the
thread — the most common integration mistake in chat-style stacks.
Blocking consult (fast-path only)
consult(question="...") waits inline and returns the answer in a single
call. Use it only for a sub-30-second smoke test. For any real consult —
and always when require_human=true — use the async pair above, or the
blocking call will trip your runtime's tool-call timeout and look broken.
Consult inputs
consult_start, consult_status, and consult share one input shape:
consult_start(
question: str, # 10–4000 chars
domain_tags: list[str] | None = None,
target_responses: int = 1, # 1 cheap/fast … 5 for consensus
approval_method: Literal[
"fastest", "consensus", "best_of_n", "all_must_agree"
] = "fastest",
wait_seconds: int = 60, # backend's wait budget for a human
bypass_on_timeout: bool = True, # fall back to LLM on timeout
require_human: bool = False, # never fall back to LLM
context_brief: str | None = None, # context shown to the human
chain_id: str | None = None, # scope routing to a private chain
) -> { "consult_job_id": ... }
See the API reference on your backend's /machine page for the full response
shape and error types.
Environment variables
| Variable | Default | Description |
|---|---|---|
HUMANCHAIN_API_KEY |
(required) | Your account API key. |
HUMANCHAIN_BACKEND |
https://humanchain-hub-demo.fly.dev |
Hub backend URL. Override for self-hosted. |
HUMANCHAIN_MODE |
live |
Set to sandbox to return synthetic responses without network calls. |
HUMANCHAIN_TIMEOUT_MS |
5000 |
HTTP timeout for Hub calls. (Distinct from consult.wait_seconds.) |
HUMANCHAIN_LOG_LEVEL |
INFO |
Server log level. |
Sandbox mode
Set HUMANCHAIN_MODE=sandbox and the server returns structurally-valid
synthetic ConsultResponse objects without hitting the network. Use this in
CI, agent unit tests, and during integration development — no credits burned,
no humans woken. (Sandbox answers are synthetic, not a real human.)
Self-hosted backend
If you're running a self-hosted Hub, set HUMANCHAIN_BACKEND to your
deployment URL. The MCP server speaks the same /api/agent/consult contract
regardless of where the Hub is hosted.
Development
git clone https://github.com/M-C-Sigma/humanchain-the-hub
cd humanchain-the-hub/humanchain-mcp
pip install -e ".[dev]"
pytest
License
MIT.
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file humanchain_mcp-0.21.0.tar.gz.
File metadata
- Download URL: humanchain_mcp-0.21.0.tar.gz
- Upload date:
- Size: 28.4 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.13.0
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
ae12471e58d32f0edf61d3acc2873ed029764af0e828b294716d138cc8c60456
|
|
| MD5 |
aa1f649155ce1723e68da8548831c099
|
|
| BLAKE2b-256 |
367c83c949a09c80ebed0c53e697a9a03816b573bb2603ebc198ee604c409ca8
|
File details
Details for the file humanchain_mcp-0.21.0-py3-none-any.whl.
File metadata
- Download URL: humanchain_mcp-0.21.0-py3-none-any.whl
- Upload date:
- Size: 28.0 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/6.2.0 CPython/3.13.0
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
3c2192f4f2e3c4a6e0bc940f4ec7141005d90d63a6040bc9a0a287d9a7bc56b4
|
|
| MD5 |
0840eb4071acbab14f753971d1067702
|
|
| BLAKE2b-256 |
23180bd3135b426ce28fb3f696ea4f59c333bbc931ac1d56c549425264b2e794
|