Claude Code MCP Server Setup: Configure, Connect and Scale

Your agent can do more than write code.

Search the web. Control a browser. Pull maps. Draft in a specific voice.

That means MCP servers. Getting them running is straightforward. Keeping them running smoothly when you scale to multiple agents is where the real decisions start.

Quick answer (30 seconds)

Point your agent to an official MCP server URL and let it handle configuration. Check that your tools are connected and responding. Organize tools by project rather than dumping everything into global scope. When you run several agents at once, check whether each session is launching its own local servers. That's the setup that keeps your machine responsive and your context clean.

Connect your first useful MCP server

The fastest path to any working MCP server is agent-assisted setup. Find the official repository or documentation for the server you want. Paste that URL into Claude Code and ask your agent to configure it for you.

The agent knows how to write the JSON, where to place it, and whether the server needs local execution or can run hosted. Local servers run as processes on your machine and may need API keys or OAuth sign-in. Hosted servers often handle authentication through your browser. Claude Code's documentation covers the MCP quickstart with exact commands and file locations.

Check your setup before adding agents

Next we need to confirm our new MCP tool works.

Run claude mcp list to see connected servers and their status. Within a session, /mcp shows the same information and lets you manage connections.

Then try performing a call to your new MCP tool by asking your AI to use it. If you configured a search server, ask your agent to look something up.

Now confirm your agent can reach the server, authenticate if needed, and receive structured output. This baseline check saves you from debugging three broken agents instead of one.

Give each project the tools it needs

Claude Code's MCP scope hierarchy works like this:

Local configuration in ~/.claude.json under project-specific entries
Then project-level .mcp.json in your project root
Then other user-level entries in ~/.claude.json

When names conflict, local wins over project, which wins over user. Unrelated entries at other scopes remain available.

A project file alone is not an allowlist. Agents inherit tools from all scopes unless you deliberately isolate them.

To achieve clean separation, remove or relocate unwanted global entries, or use claude --strict-mcp-config --mcp-config .mcp.json for a deliberately isolated setup. That limits this launch to the supplied MCP configuration, subject to managed policy.

Two deliberately isolated configurations:

A research project might use Brave or Exa for search, Google Maps for location data, and Playwright for browser validation: three servers defined in its .mcp.json, with global entries removed or strict config enforced.

A content writing project might use OpenRouter to access multiple writing models, plus search for competitive research: two servers, similarly isolated.

Each agent loads only what its project requires. Without this isolation, unrelated global entries can remain available even when the project does not need them.

An adult researcher and writer work on separate floating grassy workspaces, with tools suited to each project.

Two illustrative project toolsets: research and writing. Deliberate configuration isolation keeps unrelated global tools out; a project file alone does not do that.

Understand what happens when you're using several agents at once

Each independent Claude Code client spawns its own local MCP processes.

If two clients each launch ten local servers, that's twenty processes. If each instead launches only its needed set of three or two, that's five. The difference in resource consumption is substantial.

Called tools also return data that feeds into your context window. MCP tools like browser automation can be verbose. Accessibility snapshots and page structures add up quickly.

Claude's MCP tool search can defer tool definitions, reducing upfront schema loading in large collections.

Share MCP servers across agents with Mana

Why share MCP infrastructure?

To drastically cut back on processor and RAM usage on your machine. Running a lot of agents at once? Duplicate local servers can eat through your resources and lock up your machine.

Configure your supported MCP servers once behind Mana. It spins up a single instance of each server. Every agent you launch connects through Mana instead of spawning its own local backend. Five servers stay five servers, not twenty or fifty.

Output optimization is a separate step. Mana filters what actually reaches your agent's context so relevant data comes through and extraneous text gets stripped. Your project-level configurations still apply for focus and permissions, even with a shared backend.

Three independent clients each use a separate local tool backend on the left; three clients connect through Mana to a shared supported backend on the right.

Separate clients can launch duplicate local server processes. Mana shares supported backends across clients. This illustrates connections, not measured resource savings; output optimization is a separate step.

FAQ

Can I use the same MCP server in multiple projects with different settings?

Yes. Project-level .mcp.json takes precedence over a user-level entry with the same server name. You can point the same server name to different endpoints or with different parameters per project.

Do I need to restart Claude Code after adding an MCP server?

Typically yes. The agent-assisted configuration completes the file changes, but a session restart loads the new tools into your current context.

What if my agent cannot connect to a configured server?

Check claude mcp list for status. Verify the server process is running for local servers, or that authentication is current for hosted ones. The MCP quickstart covers setup and connection checks.

Does tool search eliminate the need to configure servers?

Tool search helps Claude find and use relevant tools without loading every schema upfront. It scales with large server collections but does not replace configuration: you still define which servers are available at each scope.

Why use Mana instead of managing project configurations myself?

Mana handles the complex work of multiplexing your MCPs and saving your computer a ton of overhead. You get set-it-and-forget-it simplicity rather than tedious per-project configuration. Plus, Mana optimizes your requests, saving you 50-70% of your AI bill.