# MCP — connecting outside tools

Course: Claude Code from Zero — https://zero2vibecode.com/learn/claude-code
Canonical URL: https://zero2vibecode.com/learn/claude-code/3-3-mcp-servers

MCP is the standard way to give an agent access to something that is not a file in your project — a database, an issue tracker, a documentation site. Powerful, and worth being deliberate about.

Your agent can read your project. It cannot, on its own, read your issue tracker, query your database, or fetch a library's current documentation.

MCP — Model Context Protocol — is the standard that closes that gap. A tool speaks MCP; the agent speaks MCP; they connect.

## Connecting one

Two shapes, depending on where the tool lives.

**A local tool**, started as a command on your machine:

```
claude mcp add files -- npx @modelcontextprotocol/server-filesystem .
```

Everything after `--` is the command that starts the server.

**A remote tool**, reachable over the network:

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

Then check your work:

```
claude mcp list
```

Do all three in the terminal below. Notice the first `list` — nothing is connected until you connect it.

## Where a connection lives

Connections have a scope, and picking the right one saves confusion later:

- **Just you, just this project** — your own experiment, nobody else sees it.
- **The project, shared** — recorded in an `.mcp.json` file in the repository, so your whole team gets the same connectors.
- **You, everywhere** — available in all your projects.

Inside a session, `/mcp` shows what is connected and handles sign-in for remote servers that need it.

## What this is genuinely good for

- **Current documentation.** A docs connector is the sharpest available answer to invented API calls: the agent reads what the library actually has today instead of what it half-remembers.
- **Issue trackers and project tools.** "Read ticket 412 and implement it" stops being a copy-paste exercise.
- **Databases.** Real schemas beat guessed ones.

**Add one, deliberately.** 
Do not connect eight servers on your first afternoon. Every connector adds tools the agent has to choose between, and more choices means more chances to pick wrong. Add the one that solves a problem you actually have.

## The honest risk

Text that arrives from a connected system enters your session. If that text contains something that reads like an instruction — a comment in a ticket, a line in a fetched page — it is now sitting in the agent's context alongside your real instructions.

This is called prompt injection, and it is not theoretical. The mitigations are ordinary and effective:

- Connect tools you trust, from sources you can identify.
- Give a connector the narrowest access that does the job — read-only where read-only is enough.
- Keep reviewing what the agent does. An injected instruction still has to produce a visible action.

**Connectors widen the blast radius.** 
A file-editing agent can damage your project. An agent connected to your production database can damage considerably more. Scope the credentials you hand a connector as if they will eventually be misused, because that is the only assumption that ages well.

## When you do not need it

Most of your first month does not need MCP at all. The project folder plus a good CLAUDE.md covers an enormous amount of real work. Reach for a connector when you notice yourself pasting the same external information into sessions over and over — that is the signal.

<Faq>
  <FaqItem q="How do I disconnect one?" a="`claude mcp remove <name>`. Connections are explicit in both directions, and removing one is instant." />
  
</Faq>
