Developers

MCP — AI clients

Let Claude Desktop, Cursor, or any MCP client build and edit workflows.

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 — 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 four 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? ›