Last updated July 29, 2026
MCP Access
MCP access lets an AI agent work your boards from the outside — reading the graph, reviewing insights, drafting intents and specs — through the same governed tools the portal uses. You mint a token, point a client at one endpoint, and the agent gets exactly the reach you granted: nothing more, and nothing that skips review.
This page is about agents reaching into your workspace. For the other direction — registering external servers whose tools chat can call — see MCP Servers.
Access tokens
Everything hangs off the token. Mint one under workspace settings → MCP access tokens (you'll need workspace admin), and it carries the whole identity:
The token value (ck_mcp_live_…) is shown once, at mint. After that the list shows only its label, scope, and last-used time — and a Revoke button that makes the very next call fail.
Connecting a client
The endpoint is https://platform.provenmap.com/api/mcp, authenticated with a bearer header. Two ways to wire it:
With the architect plugin — run /login: the browser opens, you pick the workspace, scope, and restriction, and we mint and store the token for you. No copy-paste, and the token never appears in the chat.
With any MCP client — mint the token in settings and add an HTTP server yourself:
claude mcp add --scope user --transport http provenmap \
https://platform.provenmap.com/api/mcp \
--header "Authorization: Bearer ck_mcp_live_..."Any client that speaks HTTP-transport MCP works the same way — the header is all it needs.
What a token can reach
A read token sees the reading surface: board structure and details, nodes and edges, layer navigation, archetypes, intents, specs, insights, aspects, and hub status — about 25 tools.
A read_write token adds the governed writes: creating app boards, editing an app board's diagram, creating intents and specs, promoting findings and requirements, and recording insight runs — plus write-session tools that let an agent batch related changes and discard them as one unit.
A board-restricted token can't create app boards. A new board attaches to the root board, which sits outside the restriction — so that one call is refused rather than quietly landing somewhere the token can't see.
Where writes land
On an app board — one governed by a repo — a write never becomes truth directly. It stages the change and creates a draft intent, the same passive review that captures board edits in the portal. Delete or reject the draft and everything it staged reverts. That's why handing an agent read_write is safe on the boards that matter: the review stays with your team, on the board, where it always was. See Intents for how drafts flow through release and delivery.
On a board with no governing repo there's nothing to review against, so writes apply straight to the canvas — the same as editing it yourself. They're still reversible: every MCP write runs inside a write session, and discarding the session undoes the whole batch, drafts included.
Start a new integration with a read token restricted to one board. Widen to read_write — or the whole workspace — once you've seen what the agent does with it.