Claude Code knows your repository very well. It knows nothing about the rest of the project: the ticket you are working on, the spec that explains the endpoint, the request you test it with, the server it ships to. So you paste. Ticket text into the chat. A token into the chat. Once, a database password into the chat. That last one is usually the moment people start looking for a better way.
This post is about that better way: giving a coding agent live project context over MCP, the Model Context Protocol that Claude Code, Codex, Cursor and Claude Desktop all speak, while drawing a hard line around secrets. We make Apiboo, a desktop app with a built-in MCP server, and the examples use it; the design questions apply to any MCP server you connect.
Why CLAUDE.md is not enough
A CLAUDE.md or AGENTS.md file is the right place for rules: how to run the tests, which branch to use, what never to touch. It is the wrong place for state. Which task is in progress, what is blocked, which release date moved, what the spec says since Tuesday: all of that changes daily, and a file in the repository is out of date the day after you write it. Context has to be read live, from wherever the team keeps it.
The usual next step is one MCP server per tool: one for the ticket tracker, one for the wiki, one for the API client. Each one sees one silo and acts with whatever its API key can do, which is often everything that key’s owner can do. Three servers, three keys, no shared picture, and no single place to say what the agent may and may not touch.
Live project context over one local server
Apiboo’s MCP server runs on your own computer, at 127.0.0.1:8762, and cannot be reached from another machine. With it, an agent can read your document tree and pages (newest first), your boards with each task’s status and priority and its comments, your calendar for a date range, and your collections: folders, requests, environments, and which folder a request’s auth comes from. The Graph permission shows how it all connects, and graph_project returns a whole project with everything one link around it, so the agent sees which documents, tasks and requests belong together before it touches anything.
With write permissions, it can create and change documents, add and move tasks and comment on them, create appointments, and build or import requests. Agent notes give it memory: a folder in your documents it reads when a session starts and appends to at the end, with its own permission switch. Everything it writes shows up in Apiboo right away, in the same places as your own work.
The secrets boundary
The interesting design decision is not what the agent gets but what it can never get. In Apiboo, the server has no tools for:
- The Vault and everything in it, saved passwords and API keys.
- The values of environment and workspace variables: they come back as "hidden".
- Request authentication, header values beyond harmless ones like Content-Type, body values, and any part of a response.
- Database, FTP and SSH credentials, your account tokens, and captured mail.
- Pictures in documents and tasks: the agent sees "Image: name" and never the key that opens them.
Permissions per area, and a card for every command
Every area has a read switch and a write switch, all off to begin with; a client does not even see the tools you have not allowed. Deleting anything, and running commands on servers, needs a separate destructive switch that Allow all never turns on. When an agent changes text a person may have typed, it has to send the revision it read; if you changed it meanwhile, the write is refused and the agent reads again, so your edit is never silently overwritten. Rate limits cap it at 240 reads, 60 writes and 10 destructive calls a minute.
Servers are the one deliberate exception you make yourself. Tick an SSH connection under Terminal, and the agent can propose a command on it by name. Every single command and file write waits for you to press Approve in Apiboo, in a card that shows the real host and the full command; the agent only ever sees the server’s name, and its password and key stay inside Apiboo.
Setup for Claude Code
In Settings → MCP server, generate a token (it is shown once; Apiboo keeps only a hash) and switch the server on. Then, once, in a terminal: claude mcp add --scope user --transport http apiboo http://127.0.0.1:8762/mcp --header "Authorization: Bearer <your token>". Start a new Claude Code session, turn on at least one read switch, and the tools appear. If the session says Connected with 0 tools, it is almost always a permission that is off or a session started before you changed one.
Agents started from an Apiboo terminal pane need none of this: with Attach Apiboo MCP on in the terminal profile, Claude Code and Codex get a temporary token with exactly your current permissions, which ends with the pane.
Claude Desktop, Cursor, Codex and the rest
- Claude Desktop (and Claude on the web and mobile) reaches MCP servers from Anthropic’s cloud and cannot open 127.0.0.1 directly, so Apiboo installs a small signed helper on your computer; copy the configuration snippet into claude_desktop_config.json and restart Claude Desktop.
- Cursor, Zed and any other client that connects over HTTP need two settings: the URL http://127.0.0.1:8762/mcp and the header Authorization: Bearer <your token>, in the client’s own MCP settings.
- Codex connects by itself from an Apiboo terminal pane, or over HTTP like the clients above. Cursor’s CLI reads servers only from its own mcp.json, so it needs the HTTP entry rather than attach.
- Regenerating the token locks out every client that still has the old one; signing out of Apiboo clears the token and the permissions and stops the server.
What changes in practice
- You stop pasting context. The agent reads the card, the spec and the request itself.
- You stop pasting secrets. A request the agent writes has to use a variable and ask you to fill it in.
- The board is finally up to date, because the agent updates the card when it is done.
- The agent still makes mistakes. It just makes them with the right context, and in places you can see and change back.
Related reading
The full reference is at apiboo.com/docs/security-ai/mcp-server, with the agent’s view at apiboo.com/docs/security-ai/mcp-agents. If your docs and tasks should also be readable as files, see apiboo.com/blog/api-collections-in-git.
Try it with your own work
Open Settings → MCP server, generate a token, turn on Documents read and Boards read, and run the claude mcp add line above. In a new Claude Code session, ask it what is in progress on your board.
Download Apiboo for Windows, macOS or Linux at apiboo.com/download. It is free to start, with no card and no account: every tool runs on your own machine, and you only sign in when you want sync or a team.