Claude Project-Level MCP: Configure Scope and Access
Project-level MCP in Claude Code scopes an MCP server to one project folder rather than every session. Here is how it differs from account connectors, how to configure it, and why it keeps unrelated projects clean.
Updated 5 min read
Project-level MCP configuration in Claude Code attaches an MCP server to one project folder rather than every session you open. The server is listed in the project's configuration file, loads automatically when you work in that directory, and stays invisible to other projects on your machine.
That separation matters when you work on several unrelated projects. A task board connection, a code-search index, or a documentation tool that belongs to one project has no reason to appear in a different one. Tools like fenbs use this to supply the right work context—Rules, Where we left off, current tasks—to exactly the sessions that need it.
Account scope versus project scope
Claude Code lets you register MCP servers at two main levels. An account-level (or user-level) server loads in every Claude Code session on your machine, regardless of which folder you are in. A project-level server loads only when Claude Code opens that specific project directory.
Account scope makes sense for tools you use everywhere: a browser controller, a general-purpose search index, or a calendar. Project scope makes sense for tools tied to one body of work: the project's task board, its database client, or a search index built from that project's code. Keeping those separate reduces the number of tools an assistant sees in any one session, which keeps responses focused.
There is also a local scope for user-specific configuration that should not be shared with teammates. Project-level configuration that is checked into the repository is visible to everyone on the team, which is usually the right default for project tools.
What you can configure at the project level
A project-level MCP configuration lists the servers the project needs: their command, any arguments, and the environment variables required to reach them. When you check that file into the repository, every teammate who opens the project gets the same set of tools without separate setup.
The exact file format and available fields are covered in the Claude project MCP JSON guide, a dedicated page on the configuration file syntax. The important concept here is scope: a server in the project configuration is unavailable elsewhere, and a server you add at account level does not appear in the project configuration.
Environment variables in the project configuration can reference secrets from your shell without embedding them in the file. Keep credentials outside the repository; the configuration file is the instruction, not the secret itself.
Permissions and what each server can see
An MCP server at project level operates within the same permission model as any other connection. Claude Code asks you to approve each server before it runs for the first time, and you can review, pause or remove that approval at any time. The server only receives what you pass to it; it cannot reach other projects or your account settings.
Separating servers by project is also a useful security habit. A server that has write access to a production system belongs only in the project that needs it. Listing it at account level would make it available in every Claude Code session, including quick experiments where you would not want that access active.
Supply project context without copying it into a config file
fenbs connects at project scope and gives Claude the work record it needs at session start: Rules first, then Where we left off, In progress and any context notes. You maintain the record in fenbs; the config file is one line. Connect Claude Code from Integrations and ask Claude to read the project context before it starts.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Keeping the project configuration minimal
A project configuration file that works well is a short one. List only the servers the project genuinely needs. A long list of rarely used servers creates noise in every session and makes it harder to reason about what the assistant has access to.
If a server feels useful for multiple projects, register it at account level. If it is clearly tied to one project, put it in the project configuration. When you are unsure, start at project level. Moving a server to account scope later is straightforward; removing one that turned out to be a security concern is more careful work.
Reviewing the project configuration at the same time you review the project's dependencies keeps it current. Remove servers you no longer use and update environment variable references when credentials rotate.
How to do this with fenbs
- Create a free account and add your project to the fenbs board. Give it a short description and list the first tasks.
- Write the standing rules in Decisions and rules—instructions every assistant should follow in this project, with the person who decided them.
- Open Integrations and follow the Claude Code setup guide. The guide walks you through adding fenbs as an MCP server at project scope.
- Add the configuration to the project folder and check it into the repository so teammates get the same connection.
- At the start of each session, ask Claude to call the context tool. It returns Rules, Where we left off and what is In progress. Before stopping, ask Claude to save progress so the next session starts from an accurate record.
A project-level connection means the fenbs context is available only when you are working on that project. For guidance on how Claude Projects (the web app feature) handle context and memory, see Claude project memory.
When project-level MCP is not the right fit
Project-level MCP is designed for Claude Code. If you are using Claude.ai in the browser, connections work through account-level integrations in Settings rather than a file in a repository. See how to connect Claude to your project board with MCP for a broader overview of how that connection works.
If the project is exploratory and short-lived, an account-level connection may be simpler than committing a configuration file. Project-level configuration pays off when the project is ongoing, when multiple people share it, or when the tools it needs should not appear in other work.