Disclosure: we build Carbon Forge at 100monkeys.ai, so read this as a maker's account. This guide was drafted by one of our AI agents from the public docs at carbonforge.dev/docs and reviewed by the company. The Carbon Forge steps quote the docs; the Claude Code command is from Claude Code's own claude mcp add --help. Where the docs leave a question open, the last section says so.
Carbon Forge keeps code, files and prose in one record on the server, and people and agents read and write it through the same tools. This guide attaches Claude Code to that record over MCP.
Why connect them
A coding agent forgets between sessions unless its notes live somewhere it can read again. Carbon Forge is that somewhere, shared with the people on the project. The docs call MCP "a primary product surface, co-equal with the human editor, against the same atoms, pages, links, and embeddings" (A shared cortex for LLMs). An agent's page is a page a person can open, correct and link to.
Step 1. Try the read-only endpoint with no token
Before you sign up, attach to public content. From Reading a public cortex without an account: "Add the instance's MCP endpoint to your client with no Authorization header. For this instance that is https://carbonforge.dev/api/mcp over Streamable HTTP. With Claude Code:"
claude mcp add --transport http cortex-public https://carbonforge.dev/api/mcp
You get twenty-two read-only tools, rate-limited per IP address. Ask Claude Code to read the page home in the workspace docs; with no token there is no current workspace, so every call names workspace. Remove this entry with claude mcp remove cortex-public before adding the authenticated one, so the agent is not reading two surfaces.
Step 2. Sign in and pick the workspace
Sign in at carbonforge.dev/login with an email link or the 100monkeys button; there are no passwords. Public workspaces are free, and every account includes one free private workspace (pricing). Decide which workspace the agent will use as its memory. A private one keeps the notes to members.
Step 3. Mint a token with the narrowest scope that fits
From MCP tokens: open settings and pick API tokens; choose the workspace and a role cap (viewer, editor or admin); pick a tool-scope; name the token after the agent; copy the secret, which "is shown once, then only the prefix."
For shared memory, Basic LLM memory lets the agent "read and write pages, atoms and tags, and run search, with basic graph reads", which the docs call "the minimum for an LLM that uses Carbon Forge as its memory." For an agent that only recalls, Read-only memory writes nothing. For code work, SCM agent adds lanes, trees and landing (MCP token scopes). A tool outside the scope "answers exactly as a tool that does not exist."
Step 4. Add the server to Claude Code with the token
The docs say to point the client at the endpoint "with the token in the Authorization header". Claude Code sets headers with --header:
claude mcp add --transport http carbon-forge https://carbonforge.dev/api/mcp \
--header "Authorization: Bearer ‹your token›"
If you put the token in an environment variable and write $CARBON_FORGE_TOKEN instead, your shell expands it before Claude Code sees it, so the secret is still stored in Claude Code's configuration. Treat that configuration as a secret either way, and keep the server in the default local scope or user scope rather than a file you commit.
Step 5. Let the agent ground itself
Start a session and ask Claude Code to call cortex.ground. The docs make it the first call: it "Returns the per-instance README, the calling identity, what the bearer can do, what is reachable, and helper-service health" (cortex.ground). The raw call is:
{ "jsonrpc": "2.0", "id": 1,
"method": "tools/call",
"params": { "name": "cortex.ground" } }
The server also delivers the same payload on the initialize handshake and on the first tool call of a session, so an agent that skips this step is still oriented. Read the capabilities block to confirm the token can write.
Step 6. Write memory, then cite it
Ask the agent to record what it learned as a page, for example a decision and its reason, and to read that page at the start of the next session. Two properties make this memory rather than a cache. Every save writes a revision and nothing rewrites one, so you can read what the agent wrote last week. And "every entity-returning tool decorates the result with a clickable permalink so an LLM can hand a working URL back to its human" (How MCP works): ask the agent to cite the permalink of every page it relied on, and check them.
For code, the same record holds it. An agent opens a lane instead of cloning, and a landing is one changeset, written in one transaction or not at all (Working in lanes).
Step 7. Watch the audit log and revoke when done
"Every tool call lands in the audit log under the token identity." When the agent no longer needs access, or the token leaks, revoke it from settings; "in-flight calls fail on the next request" (MCP tokens).
What the docs leave unanswered
- The endpoint for an instance on its own host. The anonymous-access page names
https://carbonforge.dev/api/mcp"for this instance"; it does not say which URL to use for an instance at its own subdomain or a vanity domain. - Two paths. The same page uses
/api/mcp; the curl example on How MCP works posts to/mcp. We use/api/mcp. - Token lifetime. The docs describe revoking a token but do not state whether a token expires on its own.
- Client-specific configuration. The docs give no Claude Code command; the one above is Claude Code's documented syntax for a header.
Related guides
- Connect Cursor, Codex and any MCP client to one Carbon Forge workspace
- A traceability checklist for AI agents in production (100monkeys.ai)
- Install AEGIS on a fresh Ubuntu VPS and run your first approved task (100monkeys.ai)
Give Claude Code a record it can cite.
Originally published at https://carbonforge.dev/guides/claude-code-mcp . Carbon Forge: https://carbonforge.dev/?utm_source=devto&utm_medium=article&utm_campaign=push-2026-10-28
Top comments (0)