---
title: "MCP Explained: Connecting Your Agent to Everything"
description: "Understand the Model Context Protocol, connect MCP servers to your agent, and judge when MCP beats a plain CLI tool"
type: "lesson"
locale: "en"
course: "Claude Code Mastery - Becoming a Power User"
number: "2.4"
canonical: "https://agenticschool.dev/courses/claude-code-mastery/mcp-explained-connecting-your-agent-to-everything"
datePublished: "2026-06-12"
dateModified: "2026-06-12"
---

# MCP Explained: Connecting Your Agent to Everything

- Course: Claude Code Mastery - Becoming a Power User
- Lesson: 2.4
- Duration: 23 min
- Level: einsteiger
- Status: published
- Canonical URL: https://agenticschool.dev/courses/claude-code-mastery/mcp-explained-connecting-your-agent-to-everything
- Locale: en

> Understand the Model Context Protocol, connect MCP servers to your agent, and judge when MCP beats a plain CLI tool

## Summary

MCP, the Model Context Protocol, is the standard way to give an agent new capabilities: a connection to a database, a design tool, a browser, a search service. This lesson explains MCP in plain terms, shows a real .mcp.json that connects a server, and gives you the judgement to know when an MCP server is the right move and when a simple CLI command in your rules file is better.

## What you learn

- What MCP is and the problem it solves: one standard plug for agent capabilities
- How to add an MCP server with a real .mcp.json and what it unlocks
- The key judgement call: when MCP beats a plain CLI tool, and when it does not

## Summary

MCP is a universal connector for agents. Instead of every tool inventing its own bespoke integration, an MCP server exposes its capabilities in one standard way that any compatible agent can use. Connect one and your agent can suddenly query a database, read a design file, drive a browser or search your docs - using those actions like any other tool. The protocol is why agent capabilities have exploded: build a server once and every MCP-aware agent can use it.

## What you will learn

You will learn what MCP is and why a shared protocol matters, the difference between a server and a client, how to add a server to Claude Code with a real .mcp.json config, and the most important and most overlooked judgement in this whole area: when an MCP server is genuinely the right tool versus when a plain command-line tool described in your CLAUDE.md does the job with less overhead.

## Prerequisites

A working agent setup and the context lessons from Course 1, because every connected server consumes context - its tool definitions sit in the window - and the performance cliff still applies. The CLAUDE.md and hooks lessons help too, since the CLI-versus-MCP decision often comes down to a rule or a script you already know how to write.

## The problem

Your agent is brilliant inside your files and blind everywhere else. It cannot see your production database, your design files, the live state of a web page, or the contents of an external service. So you become a human clipboard: you copy data out of a tool, paste it into the agent, copy the agent's output back. That manual relay is slow, error-prone, and caps how much real work you can delegate. Before MCP, the only way to fix it was a custom integration per tool, which almost nobody built.

## The problem MCP solves

MCP defines one standard plug. A server speaks MCP to expose a capability - a database, a file store, a browser, an API. A client (your agent harness) speaks MCP to use any server. Because the protocol is shared, the integration is written once per tool and works across every agent that supports MCP, the same way USB meant you stopped needing a different cable for every device. That single decision is why support spread so fast and why there is now an MCP server for almost everything you would want to connect.

- Server: exposes a capability over MCP (a database, a design tool, a browser, a search index).
- Client: your agent harness, which can use any MCP server you connect.
- Standard plug: one integration per tool works across every MCP-aware agent, instead of N bespoke integrations.
- A server can offer tools (actions the agent takes) and resources (data the agent reads).

## Adding a server

In Claude Code you register MCP servers in a .mcp.json file at your project root (committed, so the team shares the same connections) or in your user config for personal ones. Each entry names a server and how to launch it. Here is a real .mcp.json connecting two common servers: a filesystem server scoped to a folder, and a Playwright server that lets the agent drive a real browser. Connect it once and those actions become available to the agent like any other tool.

```json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./data"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}
```
.mcp.json - connecting a filesystem server and a browser server

Servers that need credentials (a database, a hosted API) take them through environment variables rather than hard-coded keys, so the same .env discipline from Course 1 applies: secrets stay out of committed config. After adding a server, your agent can list and call its tools directly. Check each server's own docs for its exact launch command and required environment variables.

## MCP versus a plain CLI tool

This is the judgement that separates people who understand agents from people who collect integrations. An MCP server is not automatically better than a command-line tool. Claude Code can already run any CLI you have installed, and a one-line instruction in your CLAUDE.md - "use the gh CLI for GitHub, the stripe CLI for Stripe" - is often simpler, lighter and more transparent than a dedicated MCP server. CLI tools shine when a mature command-line interface already exists, when you want to see exactly what command ran, and when you want zero extra context overhead. MCP earns its place when there is no good CLI, when you need structured data and resources rather than text output, or when the interaction is genuinely interactive, like driving a browser or querying a live database through a typed interface. Reach for the CLI first; reach for MCP when the CLI genuinely cannot do the job well.

- Prefer a CLI when: a good command-line tool already exists, you want full transparency, and you want minimal context cost.
- Prefer MCP when: there is no decent CLI, you need structured tools and resources, or the task is interactive (browser, live DB).
- Every connected server adds tool definitions to your context window, so each one has a real, ongoing cost.
- Connect deliberately. Three servers you use beat fifteen that bloat your context and surface area.

## Typical mistakes

The common errors: connecting every MCP server you can find and drowning your context window in tool definitions you never use; reaching for an MCP server when a CLI tool you already have would do the job more simply; hard-coding credentials into .mcp.json instead of using environment variables; and forgetting that an MCP server is third-party code with access to your stuff, so you should vet what you connect just as you would vet a dependency. Connect few, connect deliberately, connect things you trust.

## Business ROI

MCP is what turns a code agent into a general-purpose operator for your business. Connect the right servers and the agent stops needing you as a clipboard: it can read your database, check a live page, pull from a service, and act on real data end to end. That is the difference between an agent that drafts code and an agent that runs a workflow. The discipline of connecting deliberately - and choosing a CLI when a CLI is enough - keeps that power cheap and your context sharp, so you get the reach without paying the cliff tax.

## Checklist

You are ready to move on when each of these is true. The next lesson scales from one well-equipped agent to several.

- You can explain MCP as a standard plug, and name the server and client roles.
- You have added at least one MCP server to a real project via .mcp.json.
- You can state a clear case where a CLI tool beats an MCP server, and vice versa.
- You understand that each connected server costs context and surface area.

## Resources

Bookmark the official Model Context Protocol site and the Claude Code MCP documentation for the current configuration format and the registry of available servers. The filesystem, Playwright and database servers are good first connections. Pair MCP with a rule in your CLAUDE.md that tells the agent which CLI to prefer for which job, so it only reaches for a server when the CLI genuinely cannot help.

## Your task

Connect one MCP server to a real project through .mcp.json - the filesystem or Playwright server is an easy start. Then deliberately do the opposite: pick a task you might have reached for a server for, and instead add a one-line rule to your CLAUDE.md telling the agent to use an existing CLI tool. Notice which felt lighter. That instinct is the real skill here.

## Next lesson

A single well-equipped agent is powerful, but it can only hold so much in context. The next lesson scales to several agents: sub-agents, agent teams, the context-cliff motivation behind them, and how to keep a team from quietly multiplying your costs.

## Transcript

This lesson is a written, text-first guide. MCP, the Model Context Protocol, is the standard way to give an agent new capabilities: a connection to a database, a design tool, a browser, a search service. This lesson explains MCP in plain terms, shows a real .mcp.json that connects a server, and gives you the judgement to know when an MCP server is the right move and when a simple CLI command in your rules file is better. You will understand the model context protocol, connect mcp servers to your agent, and judge when mcp beats a plain cli tool. Work through the sections in order, try the task at the end in a real project, and move on once it works for you. There is no video required - everything you need is in the written steps above.