MCP

You are debugging a production issue. The bug report lives in Linear, the failing deploy lives in GitHub Actions, the customer data lives in your database, and the docs for the library you are tracking down live on a third-party site. None of that is in your codebase — and until now, none of it has been reachable from a Claude Code session. MCP is the bridge.

What MCP actually is

Model Context Protocol (MCP) is an open standard that lets Claude Code connect to external tools and data sources. When you ask a question, Claude automatically understands when to use those tools to answer it better. A lot of the context you need to work with lives outside your codebase — in databases, productivity apps, public repositories, API docs — and MCP is how you bring that context into the session.

Under the hood, MCP extends the "tools" concept you saw in lesson 2. Tools are what give an agent the ability to take action beyond text-in/text-out. MCP standardises the protocol so that any service that implements it can plug into Claude Code — and any client that speaks MCP can plug into that service.

What you can do with it

A couple of concrete examples:

• Linear MCP server — pulls the details of your team's issues directly into a Claude Code session, so you can ask about sprint work without context-switching to a browser.
• Context7 docs server — feeds Claude up-to-date documentation for a dependency, which matters a lot when a library you are using has changed since the model's training cutoff.

The pattern generalises. Any external system with a meaningful API can become an MCP server, and once it is wired in, Claude can decide on its own when to query it.

Adding an MCP server

Add servers with the claude mcp add command. There are two types you will encounter:

HTTP servers are for remote services hosted by a provider. They connect over the network — Linear, Slack, and similar SaaS integrations are usually HTTP.

Stdio servers are for local processes that run on your machine. They communicate over stdin/stdout. A local database server or a tool that needs filesystem access is usually Stdio.

Once servers are configured, manage them from inside a session with:

/mcp

That shows you everything connected, its status, and lets you enable or disable servers without leaving Claude Code.

Scoping: local, user, project

MCP servers can be scoped in three ways — and the model is deliberately parallel to the CLAUDE.md hierarchy you already know.

Local. Available only in the current project, just for you. Good for experimenting or for one-off tools.

User. Available across all your projects. Put personal tools here — the things you want everywhere you go.

Project. Defined in a .mcp.json file checked into version control. Anyone who clones the repo gets the exact same servers, automatically. This is where team-wide integrations live.

If this mapping sounds familiar: personal preferences go to user scope, team conventions go to project scope. The same rule you use for CLAUDE.md and skills.

The context cost problem

Here is the part you need to internalise — because it connects directly back to the context management lesson.

MCP servers add their tool definitions to your context window even when you are not actively using them. A server with twenty tools is twenty tool definitions sitting in context on every prompt — regardless of whether you ever call any of them this session. If you have a lot of servers configured, that pressure adds up fast.

Four ways to keep it under control:

1. Run /mcp and disable what you are not using. The cheapest fix. Disable, don't uninstall.
2. Prefer CLI equivalents where they exist. If a tool has a CLI — gh for GitHub, aws for AWS — the CLI is more context-efficient because it does not add persistent tool definitions. Claude can shell out to the CLI without loading anything up front.
3. Consider a skill instead. Skills load only the name and description into context; the body loads on demand. For specialised domain knowledge, a skill is often cheaper than an MCP server.
4. Let auto tool search kick in. If your MCP tool definitions exceed 10% of your context window, Claude Code automatically switches to tool search mode — discovering the right tools on demand rather than loading them all upfront. This is a safety net, not a strategy: it may not work as reliably as explicit tool listing, so treat it as a signal that you should prune your server list.

Where this sits in the course

MCP is the fourth extension mechanism. CLAUDE.md gave Claude persistent project knowledge. Subagents gave it isolated parallel contexts. Skills gave it on-demand specialised instructions. MCP gives it reach — into systems that live outside your filesystem entirely. And the scoping model is one you already know: local, user, project — the same shape as CLAUDE.md and skills.

Want to go deeper? Check out the dedicated Introduction to Model Context Protocol course.