Claude Code MCP

Claude Code MCP sounds like an enterprise integration thing. It is not. Claude Code MCP is the pipe between Claude Code and the tools your repo actually depends on. I use it when Claude needs context or actions outside the files on disk: GitHub PRs, Sentry issues, a read-only database, Notion specs, Figma files, internal APIs.

The mistake is adding every server you can find. That makes Claude busier, your prompts less predictable, and your security story worse. Start with one painful handoff. Make that work. Then add the next one.

For the baseline Claude Code workflow, start with my Claude Code tutorial. For the rules that make MCP useful instead of noisy, read the context engineering guide next.

What MCP does in Claude Code

MCP means Model Context Protocol. In plain English: an MCP server gives Claude Code a controlled way to talk to something outside your repo. That something can expose tools, data, prompts, or all of the above.

Without MCP, Claude can read your files and run local commands after you approve them. With MCP, Claude can also ask GitHub for PR comments, query Sentry for recent errors, pull ticket details, or inspect a database through a server you define.

That last phrase matters: "a server you define." MCP is not magic access. It is a bridge with rules. Bad bridge, bad outcome.

The command you actually need

The shape of the command is simple. For a remote HTTP server, this is the pattern I use now:

claude mcp add --transport http <name> <url>

A real example from the docs is Notion:

claude mcp add --transport http notion https://mcp.notion.com/mcp

For a server that needs a bearer token, pass a header:

claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer YOUR_TOKEN"

For local servers, use stdio. This is where people usually mess up the syntax. The double dash is not decoration. It separates Claude Code options from the command that starts your server.

claude mcp add --transport stdio myserver -- npx -y my-mcp-server

Here is the failure mode I see a lot: someone puts server flags before the double dash, Claude Code tries to parse them, and then the setup fails in a way that looks like the server is broken. It is not broken. The command is.

My default setup: local first, project only when shared

MCP has scopes. I care about this more than I care about clever server ideas.

• Local scope: private to you for the current project. This is my default for anything with credentials.
• Project scope: shared through a project .mcp.json file. Use this for team-safe servers, not personal tokens.
• User scope: available across your projects. Good for boring personal utilities, bad for anything repo-specific.

Most MCP setup should start local. After it proves useful, promote it to project scope with reviewed config and clear instructions. Do not commit someone else's token into .mcp.json. This sounds obvious until someone is trying to ship on Friday afternoon.

# Local scope, private to you in this project
claude mcp add --transport http stripe https://mcp.stripe.com

# Project scope, shared via .mcp.json
claude mcp add --transport http stripe --scope project https://mcp.stripe.com

# User scope, available across your projects
claude mcp add --transport http docs --scope user https://mcp.example.com

A worked example: GitHub PR review

GitHub is the first MCP server I would add for most engineering teams. Not because it is fancy. Because code review is where Claude Code already shines, and PR comments are usually where the missing context lives.

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

Then start Claude Code and check the connection:

claude
/mcp

Now ask for a constrained task. Bad prompt:

Review my PR.

Better prompt:

Review PR #456. Focus on correctness bugs, missing tests, and places where the implementation contradicts the issue description. Do not make edits yet. Give me file paths and line references first.

That prompt works because it tells Claude where to look, what kind of review to perform, and when to stop. MCP gives Claude access. You still have to give it judgment criteria.

Use read-only access first

My rule: read-only first, write access later, and only after the workflow earns it.

A database MCP server is a good example. I am comfortable giving Claude a read-only analytics connection in a dev or reporting environment. I am not comfortable handing it production write access because someone wants to save five minutes. If Claude needs to draft SQL, it can draft SQL. A human can decide where that SQL runs.

claude mcp add --transport stdio analytics-db -- npx -y @bytebase/dbhub \
  --dsn "postgresql://readonly:[email protected]:5432/app"

Then ask:

Use the analytics-db MCP server to inspect the schema for orders and customers. Do not run mutations. Find the tables needed to answer: which signup sources have the highest refund rate?

Notice the negative instruction: do not run mutations. I do not trust vague safety. I state the boundary in the prompt and I enforce it in the credentials.

How to manage MCP servers

These are the commands I actually use:

# List configured servers
claude mcp list

# Inspect one server
claude mcp get github

# Remove a server
claude mcp remove github

# Manage status and OAuth inside Claude Code
/mcp

If a remote server needs OAuth, add the server, run /mcp inside Claude Code, and finish the browser flow. I prefer OAuth for team tools when the server supports it because it maps back to the user's own permissions. A connector that inherits user permissions is easier to explain to security than a shared token with mystery powers.

When MCP is the wrong answer

Do not use MCP for data Claude can already read from the repo. Do not use it to hide a weak prompt. Do not use it because a vendor has a shiny connector page.

Use MCP when the handoff is real:

• Claude needs PR comments, issue text, or CI state from GitHub.
• Claude needs production error context from Sentry or a similar tool.
• Claude needs read-only database context to answer product or debugging questions.
• Claude needs docs from a system that is not in your repo.

My annoyance with MCP is that it can make bad workflows look sophisticated. A weak team can add five servers and still give Claude a lazy prompt. The result is not an agent. It is a confused intern with more tabs open.

The security checklist I use before adding a server

• Can this start read-only?
• Can I scope the token to one repo, one workspace, or one database?
• Does the server fetch external content that could inject instructions?
• Can I explain what data leaves my machine?
• Can I remove it with one command if it misbehaves?

The prompt injection risk is not theoretical. A server that fetches external content can return text that tells Claude to ignore your instructions. Claude may resist. You should still design as if hostile content gets into context sometimes.

My opinionated default

For most developers, the first three MCP connections should be GitHub, your error tracker, and one read-only knowledge source. That is enough to remove the most annoying copy-paste loops without handing Claude the keys to the building.

After that, stop and watch your sessions. If Claude keeps asking for the same external fact, add a server. If it does not, leave the system alone. Claude Code is already powerful. MCP should make it better aimed, not bigger for its own sake.

For teams that want this wired into daily engineering habits, I run hands-on AI training in San Diego focused on real workflows, not demo theater.