SchemAgentic
MCP server
Everything else in these docs is AI working inside SchemAgentic. This is the other direction: an AI agent somewhere else — Claude Code in your terminal, Claude Desktop — reading and adding to your maps, as one tool among its own.
What it is
MCP — the Model Context Protocol — is how an AI client is given tools. Point one at this server and it can list your maps, read them, search them, create one and add nodes to one, in the middle of whatever else it is doing: "check my Roadmap map and add anything from this week's notes that is missing."
This reaches maps — the outline of nodes and their text. It does not reach agents, services, credentials or connections. An external agent cannot start an agent, call a service or spend anything.
Setting it up
You need a subscription and the app open.
- In the app, open MCP Server from the AI settings.
- Turn on Publish maps to MCP. Nothing is readable until you do — the server reads a mirror of the maps you have published, never your files.
- Choose which maps to publish. It is worth publishing only what you want an external agent to see.
- Generate an access token and copy it. It is shown once.
Connecting a client
Claude Code
claude mcp add --transport http schemagentic \
https://us-central1-schemagentic.cloudfunctions.net/mcp \
--header "Authorization: Bearer YOUR_TOKEN"Claude Desktop, and other MCP clients
Add a Streamable HTTP server with that same URL and an Authorization: Bearer YOUR_TOKEN
header. Clients that only speak stdio need an HTTP bridge.
Then ask for what you want
- "What is in my Product Roadmap map?"
- "Search my maps for anything about onboarding."
- "Make a map from this README's structure."
- "Add the open questions from this thread under 'Risks' in my Launch map."
The five tools
| Tool | Does | Takes |
|---|---|---|
list_maps read |
Every published map: id, title, node count, last updated. | — |
read_map read |
One map's full outline as indented text, one node per line. | map_id |
search_maps read |
Case-insensitive search across published maps, returning the matching lines. | query |
create_map write |
Queues a new map from an indented outline. First line is the central topic. | title, outline |
add_nodes write |
Queues nodes onto an existing map, optionally under a named node. | map_id, outline, parent_title (optional) |
Outlines are plain indented text — two spaces or a tab per level, one node per line.
How writes work
A write is a queued request, not a change. create_map and
add_nodes return "Queued" immediately. Nothing has happened to your documents yet.
The queued command is applied by your app, the next time it syncs — on start, on a
map-list refresh, or when you open that map. Until then the change does not exist, and
read_map will not show it.
This is deliberate. Your maps are files with a format the app owns; letting a server rewrite them behind the app's back is how documents get corrupted. Going through the app also means every change arrives through the normal editing path — so it lands in your undo history, and you can reverse it like anything else you did yourself.
Queued commands are capped. If you see "Too many pending commands", open the app to let them through.
What a token can reach
- Only published maps. Publishing is per map and off by default. An unpublished map is invisible to every tool here.
- Only your account. A token is bound to one account and reaches nothing else — no other user's maps, and nothing shared with you that you have not published yourself.
- Maps only. No agent, service, credential or connection is exposed. An external agent cannot make yours run, cannot call an API, and cannot spend money.
- Revocable. Delete a token in the MCP Server dialog and it stops working at once. Generate a new one and the old one dies with it.
- Treat it as a password. It is a bearer token: whoever holds it is you, as far as this server is concerned. Keep it out of shared configs and repositories.
The server needs an active subscription. If yours lapses it answers 403 and your maps stay exactly where they are.