Developers

MCP for AI clients

Connect Claude Desktop, Cursor, Zed or Claude Code with an mmx_ token and about 30 tools to list, build, verify and run workflows. Activation stays human.

MadMax exposes the same tool surface the in-canvas assistant uses over the Model Context Protocol, so external AI clients can list your workflows, add steps, wire edges, verify, and activate, all from outside the browser.

MCP access is part of Pro. The in-canvas builder is free; the external door is what's gated.

Connect a client

Mint a token in Settings → developer (the same mmx_ token the REST API uses; pinned to one workspace).
Copy the ready-made config for your client from that tab. The generic shape works for Cursor, Zed, Claude Desktop, and Claude Code:

{
  "mcpServers": {
    "madmax": {
      "url": "https://<your-instance>/mcp",
      "headers": { "Authorization": "Bearer mmx_..." }
    }
  }
}

Or one line for Claude Code:

claude mcp add madmax https://<your-instance>/mcp \
  --transport sse --header "Authorization: Bearer mmx_..."

(For clients that only speak stdio, the tab also shows an npx mcp-remote bridge command.)

Every tool call runs as you, in the token's workspace, under your permissions. A read-scope token doesn't even see the mutating tools in tools/list; the build scope unlocks them.

What clients can do

The tool surface (~30 tools) covers discovery (list workflows, step templates, searchable integration operations), graph editing (stage a whole graph, add / update / remove / connect steps), verification (validate, run steps against pins), running, and debugging (recent runs with per-step input and output).

One deliberate exception: activation is human-only. The activate/deactivate tools are listed but refuse to execute. An AI client can build and verify a workflow end-to-end, and then the live switch is yours. External clients also never see credential material: they can bind a connection to a step, not read one.

Discovering the REST API from MCP

A connected client doesn't have to be told about the REST side. The initialize handshake's instructions say the same token opens /api/v1, and these resources make the details one resources/read away:

Resource	What it holds
`madmax://docs/rest-api`	The REST API guide as markdown: auth, framing, the full endpoint table.
`madmax://api/openapi`	The complete OpenAPI 3 spec (same bytes as `/api/docs/openapi.json`).
`madmax://docs/mcp-vs-rest`	The which-surface-for-what rule of thumb.
`madmax://docs/mcp`	This page.
`workflows://map`	The workspace's call graph as the index's graph view: systems (entry → sub-workflows, columns per call depth, drawn edges, folder + strays) and the standalone rest.
`workflow://{id}/calls`	Who calls this workflow and what it calls. Check before deactivating, deleting, or changing a sub-workflow's inputs.

For agents that don't read MCP resources, or aren't on MCP at all, Settings → developer has a copyable, secret-free brief that says the same things in plain text. Paste it into a system prompt or a project instructions file.

One token, two doors

The REST API and MCP share the token system: mint once, use either. Requests from both surfaces land in the same per-token activity log in Settings → developer.

‹ REST API MCP or REST? ›