Connect an assistant (MCP)

The configuration block per client, the hosted URL and token, the twelve tools, and how to ask a good question.

Every question the views answer is a tool over MCP, the Model Context Protocol, so the assistant you already use can ask them.

The configuration block

tanglemap mcp --tenant <workspace id> --config

prints a JSON block naming a server called tanglemap-<workspace id>. Where it goes:

Claude Desktop — Settings → Developer → Edit Config, inside mcpServers.
Claude Code — claude mcp add-json tanglemap-<id> '<the block's inner object>'.
Cursor — Settings → MCP → Add new server, or .cursor/mcp.json.

The server runs on your machine over standard input and output; nothing listens on a port. Restart the client and the tools appear.

A hosted workspace

A workspace on a hosted plan lives at app.tanglemap.com, so its server is a URL rather than a process on your machine. Open Settings → MCP & API in that workspace. It shows the server URL and makes the workspace token, which is shown once; the shell keeps only its hash. The token opens the tool layer for that one workspace and nothing else: never a page, never Settings.

The pane prints the text for each client with the URL filled in. Paste the token where <token> appears:

Claude Code — claude mcp add --transport http tanglemap-<id> <url> --header "Authorization: Bearer <token>".
Cursor — an entry in .cursor/mcp.json with url and a headers object carrying the same header.
Claude Desktop — its config file speaks stdio only, so the entry runs the mcp-remote bridge with the URL and --header, and the bridge forwards it.

Owners and members make and rotate the token; viewers use it. Rotating replaces it at once, and every assistant holding the old one stops until it has the new one.

The same tools answer over plain HTTP for scripts and other agents, described by the OpenAPI document the pane links, with the token in the same header.

The twelve tools

Tool	Answers
`coverage`	what is known, how completely, and what is not known at all
`changes`	what two collects disagreed on, with the impact as counts
`search`	find automations or fields by a fragment of their name
`automation`	one automation: what it reads, writes, triggers on, its schedule and credential
`field`	one field: writers, readers, external consumers, value domain
`impact`	everything downstream of a change to these fields, grouped by system
`contention`	fields with several deciding writers
`crossings`	one system writes it, another depends on it
`cycles`	reactive loops through a field
`funnel`	a state field as an ordered track: arrivals, watchers, side-channels
`assess`	a structured proposal against all six checks
`save_narrative`	store the assistant's write-up beside a saved assessment

What the server tells the model first

Before anything else, the server says: read coverage before concluding anything from an empty result. Some systems may never have been collected, and this graph cannot say that nothing reads a field unless coverage supports it. Every result that could be read as an absence carries absence_claim_licensed, and when it is false the empty answer is a gap in collection, not a fact. The model writes the prose; the numbers are the graph's.

Asking a good question

Name the field the way the portal spells it, and say what you are about to do:

What would break if I made a nightly job write contact.lifecyclestage from the lead score?

The assistant will call assess with the proposal, and the answer is the same six checks the Assess page runs: contention, downstream impact, loop risk, timing, credential scope, precedent, each with the count behind it.