withHuman MCP server
Let an AI agent set up approval pipelines, escalation paths, teams and webhook endpoints for you.
The withHuman MCP server lets a coding agent or assistant configure withHuman on your behalf. Connect Claude Code, Cursor, Codex or any other MCP client with one of your API keys, and ask it in plain language: "send every refund over $500 to the payments team and approve the rest." The agent reads your agents, members and teams, creates the escalation path, writes the pipeline, and can test a sample request before it goes live.
This is a different thing from the MCP Gateway. The gateway sits between an agent and the external tools it calls, and asks for approval. The MCP server is how an agent manages withHuman's own settings.
Loading diagram…
Diagram source
flowchart LR
you["You, in your agent's chat"] -->|"Set up refund approvals"| agent["Coding agent or assistant"]
agent -->|"Sign in and choose permissions, once"| consent["withHuman in your browser"]
consent --> agent
agent -->|MCP tools| server["withHuman MCP server"]
server --> pipelines["Approval pipelines"]
server --> paths["Escalation paths"]
server --> teams["Teams"]
server --> webhooks["Webhook endpoints"]Connecting
The server's address is your deployment's origin followed by /api/mcp/v1. On hosted withHuman it is https://app.withhuman.ai/api/mcp/v1. Both API keys pages in Settings show the address and a ready-made command for Claude Code. Add the server to your client as a streamable HTTP server:
claude mcp add --transport http withhuman https://app.withhuman.ai/api/mcp/v1Claude Code opens the sign-in the first time it uses a withHuman tool. To connect right away, or after the access has expired, run this inside Claude Code and choose withhuman, then Authenticate:
/mcp
codex mcp add withhuman --url https://app.withhuman.ai/api/mcp/v1Codex opens the sign-in as part of adding the server. If it does not, or the access has expired, run:
codex mcp login withhumanThe server is stored in ~/.codex/config.toml, so it is available in every project.
Add the server to ~/.cursor/mcp.json for every project, or to .cursor/mcp.json inside one project:
{
"mcpServers": {
"withhuman": {
"url": "https://app.withhuman.ai/api/mcp/v1"
}
}
}Cursor lists the server under MCP in its settings. Turn it on there, and Cursor opens the sign-in in your browser.
Any MCP client that supports the streamable HTTP transport and OAuth sign-in can connect. Add a server named withhuman with the address above and no command, in whatever form the client's settings use. Most clients accept the same JSON shape as Cursor. When the client first reaches withHuman it opens the sign-in in your browser.
There is no key to copy. The first time the agent talks to withHuman, it opens your browser at the consent page. You sign in if you are not already, see which agent is asking and which organization you are connecting it to, choose what it may do, and choose whether the access lasts 90 days or until you revoke it. Approving sends you back to the agent, which is connected from then on.
Approving creates a personal API key named after the agent, marked Connected agent in your key list. Revoking that key disconnects the agent; it will ask you to connect again the next time it needs withHuman. When the access expires, the agent asks you to connect again in the same way.
Without a browser
A headless integration that cannot open a browser can send an existing personal or organization API key as a bearer token instead. Put the key in the WITHHUMAN_API_KEY environment variable and add the server with the header:
claude mcp add --transport http withhuman https://app.withhuman.ai/api/mcp/v1 \
--header "Authorization: Bearer $WITHHUMAN_API_KEY"codex mcp add withhuman --url https://app.withhuman.ai/api/mcp/v1 \
--bearer-token-env-var WITHHUMAN_API_KEYCodex reads the variable each time it starts the server, so the key never lands in config.toml.
{
"mcpServers": {
"withhuman": {
"url": "https://app.withhuman.ai/api/mcp/v1",
"headers": {
"Authorization": "Bearer ${env:WITHHUMAN_API_KEY}"
}
}
}
}A browser session never opens the server, so a link in a page cannot act as you.
What the agent can do
The agent gets tools for the same things the pages in Settings do:
| Area | Tools |
|---|---|
| Agents | List agents, create an agent. |
| People | List members and teams, read a team, create a team, set a team's members. |
| Approval pipelines | Read the organization's or an agent's pipeline and its history, save a new revision, activate a revision, test a sample request. |
| Escalation paths | List and read paths and their history, create a path, save a revision, activate a revision, archive a path. |
| Webhook endpoints | List and read endpoints, create one or save a revision. |
| Reference | Read the exact format of pipeline blocks, conditions and escalation path documents. |
Saving a pipeline, escalation path or webhook endpoint creates a new revision and activates it in the same step, so the change applies to new requests right away. The agent can save a draft instead and leave activation to you. Earlier revisions stay available for rollback, exactly as in the app; see Immutability.
Connecting agent runtimes, minting credentials and deciding requests are not available through the MCP server. Creating and revoking API keys always needs a signed-in person.
Permissions
The agent can do exactly what you allow it on the consent page: everything you can do, or only the actions you tick. Either way it follows your permissions as they change, and it can never do more than you. For example, an agent allowed to edit pipelines but not activate them leaves drafts for you to activate in the app. Granting an action that can decide requests or is marked dangerous asks for a recent sign-in, like creating such a key by hand. Choosing specific actions is available in the hosted edition; elsewhere the agent gets everything you can do.
An organization key used as a bearer token can build pipelines, escalation paths and webhook endpoints, but cannot create teams or change their members.
Every change the agent makes is recorded in the Audit log under the key, so you can see what it did and roll it back.
Example: Refund approvals
We'll ask our coding agent to set up refund approvals for the support assistant. It lists our agents and finds support, lists our teams and finds Payments, and creates an escalation path that pages Payments and then our finance lead after 15 minutes. It then saves the organization pipeline with a block that denies refunds over $500, and the support assistant's pipeline with a block that approves refunds up to $20 and sends the rest to Payments review. Before we trust it, we ask it to test a $75 refund: the preview reports that the request would go to a person through the Payments review path.
Checking it works
Ask the agent to list your pipelines and escalation paths, or open Approval pipelines and Escalation paths in the app: the revisions it saved appear with the key's name as the author. If a tool call is refused, the agent sees the same reason the app would show, such as a path that is still in use or a permission the key does not hold.