Skip to main content
Champ exposes a Model Context Protocol (MCP) server, so AI agents — Claude, ChatGPT, Codex, Claude Code, Cursor, or any MCP-compatible client — can work in your Champ workspace directly. A connected agent can list and read your workflows, create and edit workflow drafts node by node, run and test them, and inspect run results. Publishing a draft always remains a human action in the dashboard. Open the Tokens page and copy the Connect URL shown for the workspace you are viewing. It is already configured for that workspace, so there is no access token to create. Your client opens a browser sign-in the first time; approve access and you’re connected. Access follows your workspace membership: it’s tied to your login, refreshes silently, and ends automatically when your account is deactivated. To connect another workspace, switch workspaces in Champ and copy that workspace’s Connect URL.
In Claude on the web or desktop:
  1. Open Settings → Connectors and choose Add custom connector.
  2. Paste the Connect URL and add it.
  3. Click Connect, sign in with your Champ account, and approve access.
On Claude Team/Enterprise plans, an admin may need to allow custom connectors first.

​
Other clients

Most MCP clients that support OAuth (Cursor, VS Code, Windsurf) work the same way: add the URL, then trigger the client’s connect/login action. Cline is not supported — its MCP implementation lags the current spec.

​
For CLI, CI & scripts: tokens

Headless environments can’t run a browser sign-in — use an MCP token instead:
  1. Go to Tokens in the dashboard (avatar menu → API/MCP Tokens).
  2. Click Create Token, choose the MCP scope, and click Create.
  3. Copy the token immediately — it’s shown once and cannot be retrieved again. MCP tokens look like mcp_xxxxxxxx….
Send it as an Authorization: Bearer header:
Tokens don’t expire; to revoke one, delete it from the Tokens page and any client using it loses access immediately. The MCP and API scopes are separate — an api_… token is rejected by the MCP endpoint and vice versa.

​
What a connected agent can do

Your client discovers the full tool list automatically (in Claude Code, run /mcp). The core groups: The server also exposes tools for browser profiles, hybrid-browser step building, document and template handling for Fill nodes, and organization artifacts and memory — the tool descriptions your client fetches are the authoritative reference.

​
How editing works

MCP editing follows the same draft → publish model as the dashboard:
  1. Edits apply to drafts only. To change a published workflow, the agent first calls create_workflow_draft, which opens (or reuses) that workflow’s draft revision. Brand-new workflows created with create_workflow start as drafts.
  2. The graph is edited incrementally — one node or edge at a time — so the agent can read back and verify each change.
  3. Test before publishing. test_workflow_node runs a single node in isolation without saving anything; workflow_runs can execute the full draft as a test run; node_test_cases saves repeatable test cases with assertions.
  4. Publishing is human-only. No MCP tool can publish a draft. The agent can pre-fill the commit message (suggested_commit_message on update_workflow), but a person reviews and publishes from the dashboard.

​
Security notes

  • Both sign-in and tokens grant the full tool set, scoped to your workspace — there are no per-tool permissions.
  • Sign-in access is tied to the person: it follows workspace membership and ends when the account is deactivated. Actions are attributed to the signed-in user.
  • Tokens are the opposite trade: they never expire, are visible to and deletable by anyone in your organization on the Tokens page, and attribute actions to the user who created them. Treat a token like a password and store it in a secrets manager.