Claude Code MCP Explained: How to Connect Claude to Your Other Tools (2026)

MCP — the Model Context Protocol — is an open standard that connects Claude Code to your other tools and data. Instead of you copying an issue out of your tracker and pasting it into a chat, Claude reads it directly. You add a tool once with a single command, Claude gains a new set of abilities, and from then on you just ask in plain English. Anthropic calls the connected tools MCP servers.

What is MCP, in plain English?

Think of Claude Code as a very capable assistant who just started at your company. It's smart, it's fast, and it can read and edit the files on your computer — but it has no login to anything else. It can't see your Notion pages, your GitHub issues, your error logs, or your calendar. Every time you want it to use that information, you have to go fetch it and paste it in.

MCP is how you hand it the keys. It's an open standard — published by Anthropic, and used far beyond Claude — that defines one common way for AI assistants to talk to outside systems. A company builds an MCP server for their product once, and any AI tool that speaks MCP can use it. That's why the list of available connections grew so fast: nobody has to build a custom integration for every AI and every tool.

The practical result: you stop being the copy-paste layer between your AI and your software.

What can you actually do once MCP is connected?

This is the part that clicks for most people. Anthropic's own documentation gives examples like these — all of them things you ask for in one sentence, in one conversation:

• Build a feature straight from a ticket — "Add the feature described in JIRA issue ENG-4521 and open a pull request on GitHub."
• Check what's actually broken — "Look at Sentry and tell me which errors spiked after yesterday's release."
• Ask your own database questions — "Find the ten users who used this feature most last week."
• Pull designs into the work — "Update our email template based on the new Figma design that was posted in Slack."
• Verify in a real browser — "Open our staging site, click through the signup flow, and tell me where it breaks."

Notice what all of these have in common: the information lives somewhere Claude couldn't previously reach. MCP is the bridge, and every bridge you build removes a chunk of manual work from your day.

Is MCP the same thing as a Claude connector?

Mostly, yes — "connector" is the friendly name and MCP is the plumbing underneath. The connectors you see in the Anthropic Directory at claude.ai/directory run on exactly the same MCP infrastructure as the servers you add from a terminal. Any remote server listed in the Directory can be added to Claude Code with the same command.

It's also worth knowing that MCP isn't terminal-only. Every Claude Code surface can connect servers: the desktop app has a Connectors screen you click through, VS Code has its own setup, Claude Code on the web reads the configuration file from your repository, and connectors you add at claude.ai load automatically in the CLI when you sign in with the same account. Same standard, different front doors.

How do you connect your first MCP server?

Anthropic's recommended first server is the Claude Code documentation server. It's a good practice run because it needs no account, no API key, and no sign-in — so if something goes wrong, it's your setup, not a credential problem. Here's the whole flow.

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

claude mcp list

claude mcp remove claude-code-docs

How do you connect a tool that needs a login?

Most of the interesting ones — Sentry, Linear, Notion, GitHub — sit behind a login. The pattern barely changes: you add the URL, then sign in through your browser once.

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

Right after this, claude mcp list will show ! Needs authentication. That's expected. Start a Claude session, type /mcp, pick the server from the list, and choose Authenticate. Your browser opens, you approve the connection on the service's own sign-in page, and the status flips to connected. You never paste a password into Claude — the sign-in happens where it should, on their site.

What about tools that run on your own machine?

Not every MCP server lives on the internet. Some run as a small program on your computer — that's called a stdio server — and they're the right choice for anything that needs local access: your filesystem, a database, or a browser.

The Playwright server is the classic one to try. It hands Claude a real browser it can open, click, and read. It needs no account, and it runs through npx, so you'll need Node.js 18 or newer installed.

claude mcp add playwright -- npx -y @playwright/mcp@latest

Two things are different here. There's no --transport flag, because local servers use stdio by default. And that double dash -- matters: everything after it is the command Claude Code runs to start the server, passed through untouched. Leave it out and Claude Code tries to read the server's own options as its own, and the whole thing fails in a confusing way.

Where does the configuration actually live?

Claude Code saves your servers at one of three scopes, and picking the right one saves a lot of confusion later. The scope decides which projects the server shows up in, and whether your teammates get it too.

• Local — the default. The server works only in the project folder where you added it, and only for you. Stored in ~/.claude.json. Right for experiments and anything with personal credentials.
• Project — shared. Stored in a .mcp.json file in your project root, which you commit to version control so everyone who clones the repo gets the same tools. Add it with --scope project.
• User — personal but everywhere. Stored in ~/.claude.json and loaded in every project you open. Add it with --scope user. This is the one most people actually want for their everyday tools.

A server's scope is fixed when you add it, so "moving" one means removing it and adding it again with a different --scope flag. Not a big deal, but it catches people out.

If you'd rather write the configuration by hand — and for the project scope it's genuinely nicer, because the file doubles as documentation for your team — a .mcp.json looks like this:

{
  "mcpServers": {
    "claude-code-docs": {
      "type": "http",
      "url": "https://code.claude.com/docs/mcp"
    },
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

Claude Code reads that file when a session starts, so save it and restart. The first time it sees a project server it asks you to approve it — that prompt exists so a repository you cloned from a stranger can't quietly launch programs on your machine.

Which MCP servers should a beginner start with?

Don't shop for servers — shop for annoyances. The right first connection is whichever tool you currently paste out of most often. That said, here's a sensible order for most people:

• The Claude Code docs server — zero setup, zero risk, and it makes Claude accurate about its own features. A perfect test run.
• Your issue tracker (GitHub, Linear, Jira) — this is where "read the ticket and do the thing" comes from, and it's the single biggest time saver for most teams.
• Your notes or docs tool (Notion, Google Drive) — so Claude answers from what your company actually wrote down, not from the open internet.
• A browser server (Playwright) — so Claude can check its own work on a real page instead of assuring you it probably works.
• Your error monitoring (Sentry) — turns "something's broken" into a specific, already-diagnosed problem.

What do you do when a server won't connect?

Almost every MCP problem is one of five things. Run /mcp inside a session or claude mcp list from your shell, then match the symptom:

• "No MCP servers configured" — you're in the wrong folder. Local-scoped servers only load in the project where you added them. Re-add it there, or use --scope user so it follows you everywhere.
• "Failed to connect" on a hosted server — the URL is wrong or unreachable. A 404 or 405 from curl -I <url> is actually fine (many MCP endpoints only answer POST); no response at all means check the address.
• "Failed to connect" on a local server — run the command yourself in a terminal. If it starts and waits, the server is fine and your configuration is off. If it errors, the message names what's missing, usually Node.js.
• "Connection timed out" — the server was slow to start, common on a first npx download. Raise the limit: MCP_TIMEOUT=60000 claude.
• Edits to `.mcp.json` did nothing — that file is read once, at session start. Exit and restart. If you rejected the approval prompt earlier, reset it with claude mcp reset-project-choices.

One more that trips people up: if a server connects but shows no tools, it usually started without an API key it needed. Pass it with --env KEY=value when you add the server — the service's docs will list which variables it wants.

Is MCP worth learning if you're not a developer?

Yes — arguably more so. Developers already have a dozen ways to move data between systems. If you don't write code, MCP is the first time you can wire your tools together by typing one line and then asking in English. There's no integration platform to configure, no automation builder to learn, and no per-task pricing.

The honest catch is that MCP rewards restraint. Connect everything and you'll get a slower, more confused assistant with a lot of permissions. Connect the two tools you paste out of every day, and the difference in your week is immediate.