Guide · MCP
Connect the Ooperon automation MCP to any LLM
Ooperon runs a spec-compliant MCP server for building CRM automations. Point your favorite AI coding tool at one URL and it can author complete, validated automations for you — as drafts you review on the canvas.
By the Ooperon team · Updated September 2026 · 6 min read
Which of the two servers you want
Ooperon runs two Model Context Protocol servers, and they do different jobs. This guide covers the one that builds automations. If what you actually want is a model that works your CRM — looking people up, fixing records, moving deals, booking meetings, answering conversations — that is the other one.
| Endpoint | What it is for |
|---|---|
/api/mcp | This guide. Authoring automations, always as drafts you review on the canvas. |
/api/mcp-crm | Operating the CRM: people, deals, tasks, calendars, conversations. Covered in its own guide. |
They are split because what makes a model pick the wrong tool or invent an id is the size and similarity of the tool list it is shown — two coherent lists of twenty beat one list of forty near-duplicates. Authentication is shared, so a single key or token works on both and you can connect either, or both.
What you're connecting to
The Ooperon authoring MCP is the same engine as the in-app “Build with AI” agent, exposed over the Model Context Protocol. Instead of emitting brittle tool-call JSON, it hands the model a typed TypeScript SDK generated from your connected tools, type-checks the code, runs it in a sandbox, and validates it against your real workspace — your tags, pipelines, calendars, and connections. If the model invents an ID or mistypes a field, it's rejected before anything is saved.
Two things are worth knowing up front. First, everything it creates is a draft — the MCP never activates an automation; the canvas is the human gate. Second, it's tenant-scoped: a connection can only ever read or write the workspace you authorized, never another's.
One endpoint, two ways to authenticate
Every client connects to the same streamable-HTTP endpoint:
https://ooperon.com/api/mcpOAuth (recommended). Clients that support MCP OAuth — like Claude Code and Claude.ai — just open a browser, you log in and pick a workspace, and you're done. No key to copy or rotate.
API key. For everything else, create a key in Admin → API Keys with the automations:read and automations:write scopes, and pass it as a bearer token:
Authorization: Bearer oop_live_xxxxxxxxSome clients speak only stdio, not remote HTTP. For those, the mcp-remote bridge (from npm) forwards a local stdio server to the remote URL — shown per client below.
Client setup
Claude Code (CLI)
One command; it runs the OAuth login and workspace picker:
claude mcp add --transport http ooperon https://ooperon.com/api/mcpPrefer an API key instead of OAuth? Pass it as a header:
claude mcp add --transport http ooperon https://ooperon.com/api/mcp \
--header "Authorization: Bearer oop_live_xxxxxxxx"Claude.ai (web)
On a plan with connectors (Pro/Max/Team/Enterprise), open Settings → Connectors → Add custom connector, paste the URL https://ooperon.com/api/mcp, and complete the OAuth login. The tools then appear in any chat.
Claude Desktop
Add it to claude_desktop_config.json via the stdio bridge:
{
"mcpServers": {
"ooperon": {
"command": "npx",
"args": ["mcp-remote", "https://ooperon.com/api/mcp",
"--header", "Authorization: Bearer oop_live_xxxxxxxx"]
}
}
}Cursor
Create .cursor/mcp.json in your project (or the global one in ~/.cursor/):
{
"mcpServers": {
"ooperon": {
"url": "https://ooperon.com/api/mcp",
"headers": { "Authorization": "Bearer oop_live_xxxxxxxx" }
}
}
}GitHub Copilot (VS Code)
Add .vscode/mcp.json. VS Code prompts for the key and keeps it out of the committed file:
{
"inputs": [
{ "id": "ooperon-key", "type": "promptString", "description": "Ooperon API key", "password": true }
],
"servers": {
"ooperon": {
"type": "http",
"url": "https://ooperon.com/api/mcp",
"headers": { "Authorization": "Bearer ${input:ooperon-key}" }
}
}
}OpenAI Codex (CLI)
Codex speaks stdio MCP, so bridge with mcp-remote in ~/.codex/config.toml:
[mcp_servers.ooperon]
command = "npx"
args = ["mcp-remote", "https://ooperon.com/api/mcp", "--header", "Authorization: Bearer oop_live_xxxxxxxx"]Cowork
Remote connectors are configured against your Claude account rather than inside each app, so the connector you add for Claude.ai above is the same one Cowork uses — there is no separate Cowork setup. Add it once at Customize → Connectors, or, on Team and Enterprise, have an owner add it under Organization settings → Connectors → Add → Custom → Web.
openClaw
Recent openClaw builds reach remote streamable-HTTP servers directly, with no bridge. From the CLI:
openclaw mcp add ooperon \
--url https://ooperon.com/api/mcp \
--transport streamable-httpOr under mcp.servers in ~/.openclaw/openclaw.json:
{
"mcp": {
"servers": {
"ooperon": {
"url": "https://ooperon.com/api/mcp",
"transport": "streamable-http",
"enabled": true,
"headers": { "Authorization": "Bearer oop_live_xxxxxxxx" }
}
}
}
}openClaw recommends keeping credentials out of config literals and putting the bearer token in its secret storage instead. There is also a Settings → MCP screen in the Control UI.
Hermes
Add an entry under mcp_servers in ~/.hermes/config.yaml. Remote servers take url and headers, and streamable HTTP is the default transport:
mcp_servers:
ooperon:
url: "https://ooperon.com/api/mcp"
headers:
Authorization: "Bearer oop_live_xxxxxxxx"Restart Hermes or run /reload-mcp in an active session, and the authoring tools appear alongside the built-in ones.
Anything else
Two rules cover the rest. If the client accepts a remote HTTP server, give it the URL https://ooperon.com/api/mcp and an Authorization: Bearer header. If it only launches local stdio processes, use the same mcp-remote bridge shown for Claude Desktop and Codex:
npx mcp-remote https://ooperon.com/api/mcp --header "Authorization: Bearer oop_live_xxxxxxxx"That command is the universal fallback: any MCP client that can launch a stdio process can reach the server through it.
What to do once it's connected
Ask in plain language — “text new leads, wait a day, then have an agent qualify them and book a consult.” Under the hood the model runs the authoring loop: search_nodes to find the right steps, get_types for the scoped SDK, validate_code until it's clean, then create_from_code to save a draft. You get a canvas link back.
If your workspace has more than one business, tell it which one (or it will ask) — tools take an optional businessId from list_businesses. And remember: what comes back is always a draft. Review it, tweak it on the canvas, and turn it on when you're happy.
Build an automation from one sentence
Connect your editor, describe the flow, review the draft, ship it. Your CRM keeps itself current while the automation does the follow-up.
