OpenClaw MCP
A bridge from Claude.ai to your own OpenClaw assistant: chat delegates tasks over OAuth 2.1 and HTTPS
- 188 ★ on the repository
- Last commit
Broad access
Why this level
- The bridge passes messages to an assistant with its rights, and it can run commands and other agents
- The gateway token and OAuth client secret give control of your assistant
Install
- Works in
Manual install
npx openclaw-mcpLocal run for Claude Desktop; the gateway URL and token go in env variables.
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- The bridge passes messages to an assistant with its rights, and it can run commands and other agents
- The gateway token and OAuth client secret give control of your assistant
This is third-party code. Review the repository files before installing.
What it does
The server connects Claude.ai or Claude Desktop to your OpenClaw assistant running on your own machine. Claude sends a message through the `openclaw_chat` tool and OpenClaw does the work, for instance launching Claude Code to fix a bug. Long jobs use async tools: `openclaw_chat_async` queues a message and returns a task id at once, while `openclaw_task_status`, `openclaw_task_list` and `openclaw_task_cancel` follow progress. The bridge runs in Docker or through `npx`. For Claude.ai it accepts OAuth 2.1 sign-in and sits behind your own HTTPS reverse proxy. Several OpenClaw instances (prod, staging, dev) register in one `OPENCLAW_INSTANCES` variable, each with its own address and token.
Who it is for. Owners of a self-hosted OpenClaw assistant who want to drive it from the Claude.ai web chat and not only from messengers.
Good fit when
- A Claude.ai chat hands a task to the home assistant, which launches Claude Code and fixes a bug
- A long job is queued with `openclaw_chat_async` and its status is checked later
- A team has prod and staging OpenClaw instances and a request must go to one of them
- The OpenClaw gateway health is checked from the conversation with `openclaw_status`
Not a fit when
- OpenClaw is not installed: the bridge does nothing without it
- You need direct Claude access to files and shell without a second assistant: stock filesystem servers fit better
- There is no domain or HTTPS for Claude.ai: a remote connection needs a reverse proxy
Example request
Through OpenClaw start Claude Code in the api repository, find why the tests fail and report what needs fixingMCP
- Transport
- stdio, http
- Authentication
- OAuth
Environment variables
OPENCLAW_URLrequired- OpenClaw gateway URL.
OPENCLAW_GATEWAY_TOKENrequired, secret- OpenClaw gateway token.
MCP_CLIENT_SECRETsecret- OAuth client secret for HTTP mode.
Limitations
For Claude.ai the connector URL must end with `/mcp` or you get a 404 after sign-in. Behind a reverse proxy set `MCP_ISSUER_URL` and `TRUST_PROXY=1`, and restrict `MCP_REDIRECT_URIS` to Claude callbacks. The bridge passes messages to your assistant along with its rights, so create a dedicated OpenClaw agent via `OPENCLAW_AGENT_ID` and do not expose your main one with shell access. The `--transport sse` mode is deprecated and `--transport http` replaces it.
How to disable. Remove the connector in Claude.ai or the client, stop the container (`docker compose down`) and rotate the OpenClaw gateway token.
FAQ
How do I connect OpenClaw to Claude.ai?
Run the bridge in Docker behind an HTTPS proxy and add your own Claude.ai connector at `https://your-domain/mcp` with `MCP_CLIENT_ID=openclaw` and your `MCP_CLIENT_SECRET`. The URL must end with `/mcp`.
Can I run it without Docker?
Yes. For Claude Desktop `npx openclaw-mcp` and a block in `claude_desktop_config.json` are enough, and for Claude.ai without Docker run `npx openclaw-mcp --transport http --port 3000` with the OAuth variables.
Which tools does the bridge have?
Synchronous `openclaw_chat`, `openclaw_status` and `openclaw_instances`, plus async `openclaw_chat_async`, `openclaw_task_status`, `openclaw_task_list` and `openclaw_task_cancel`.
How do I connect several OpenClaw instances?
Pass a JSON list in `OPENCLAW_INSTANCES` with a name and URL per instance. Each has its own address, auth and timeout.
Is it safe to expose the bridge?
The bridge listens on `127.0.0.1` only and expects a TLS reverse proxy. OAuth 2.1, CORS checks and a redirect allowlist guard the entry, but the rights come from the OpenClaw assistant itself, so give it a dedicated agent.
Discussion
No questions or reviews yet.
Related
MCP serversA compact OpenClaw alternative: a personal assistant on Claude Agent SDK with agents in isolated containers and messengers added via skills
MCP server of the self-hosted EmperorClaw panel: Claude Code and Codex read company knowledge, tasks and customers in scope
Open-source personal AI assistant on your own machine: answers in Telegram, Slack, Discord and WhatsApp, extended with skills and plugins
A CLI that connects local agents to a shared cloud store of sessions, memory, skills and MCP connectors.
One runtime for Claude Code, Codex, OpenCode and more: a run counts as done only when checks the agent did not write pass
A CLI that turns any MCP server, OpenAPI spec or GraphQL endpoint into commands at runtime, with no codegen
README in short
The README explains why the bridge exists and gives three ways to run it: Docker, local for Claude Desktop and remote for Claude.ai without Docker. Then come a diagram, the sync and async tool lists and multi-instance setup.