🧱 Without MCP, the agent hits a wall
New here? So far, in Path 0 and Path 1, your agent already knew how to read and write files, run commands in the terminal, and organize a project folder. That’s a lot—but there’s a hard limit: it can only see what’s inside the computer it runs on. Asking it to "look at that site" or "read my Google spreadsheet" without extra help is like asking someone locked in a room with no windows to describe the street outside.
💡 Main Concept
- •Local files and folders: yes, always.
- •A website, an API, a cloud spreadsheet, a database: no, unless there’s a bridge.
New here? One API (abbreviation for application programming interface) is the “entry point” that a website or service leaves open for programs to communicate with it — without an API, the only way to get data from a site is to open a browser and copy it manually. And a “protocol” is simply an agreed set of rules: how to ask, what to provide, and in what order. Every protocol exists so two unfamiliar endpoints can understand each other without having to negotiate from scratch every time — it’s the same idea as an electrical outlet or a shared language.
Caption: without an installed bridge, everything outside the project folder—websites, spreadsheets, databases—is invisible to the agent, even if the information exists and is just one click away in your browser.
🔌 MCP is a standardized outlet
New here? MCP means Model Context Protocol — in plain English, an "agreement" for how an AI agent communicates with an external service. Think of a standardized electrical outlet: any device with the same plug format fits the same outlet, without an adapter. Before MCP, each external tool required a different "wire" (code) to connect. With MCP, everything speaks the same format — the agent plugs in and immediately understands what that service offers.
Caption: on the left, an agent without MCP can only see the files in the local folder. On the right, with MCP enabled, it connects to a “standardized outlet” and reaches external services—without you writing a line of connection code.
Let’s reinforce what the MCP no is: it’s not artificial intelligence, a website, or an app. It’s just an agreed-upon format for messages—similar to an email (subject, recipient, body)—that both the agent and the MCP server know how to create and read. Before this standard existed, every company that wanted to connect its tool to an AI agent invented its own format, and every integration became a separate programming project. MCP eliminated that reinvention: one published standard that any service can adopt.
🔍 Inside
What “travels” in an MCP call is a structured text package (technically JSON, but you never need to read it) describing three things: which tool the agent wants to use, with which parameters, and—in the response—what the service returned. This package passes between Claude Code and the MCP server that’s running; if the server needs to communicate with the internet (fetch a page, query a spreadsheet in the cloud), then it leaves your computer—and that’s why authentication (the next topic) matters.
🗣️ MCP server: who speaks the other side's protocol
New here? One MCP server is a small program that sits between your agent and the actual service (Firecrawl, Google Drive, a database, etc.). It "translates" the agent's request into the format that service expects, then translates the response back. You don't write this translator — it comes ready to use; you just connect it (module 2.3) and authenticate with your own key.
💡 Practical Tip
Think of three roles: you (makes the request in Portuguese), the agent (decides which tool to use) and the MCP server (speaks the language of the external service). You never talk directly to the service — the MCP server acts as the bridge.
New here? "Authenticate" means proving to a service that you are
who you say you are — usually with a API key, a long string
of letters and numbers that works like a password just for you, generated on the service’s website. The MCP server stores that
key in a file called .env inside your project (you’ll create this
file in module 2.3)—never in the conversation with the agent, because anything that passes through the chat could end up
saved somewhere. The example below is just the format: never use a real key in a public place.
.env
# arquivo .env na raiz do projeto
NOME_DO_SERVICO_API_KEY=SUA_CHAVE_AQUIHow to verify: ask the agent to "list the available MCP tools." If it responds with the service's list, the key was read correctly; if you get an authentication error, check the next section.
⚠️ Common errors
- •Invalid or expired key: the server returns an authentication error. Make sure you copied the entire key, with no extra spaces, and that it’s still active in the service dashboard.
- •Key in the wrong place: if you paste the key directly into the conversation instead of the
.env, it appears in the chat history. Always use .env, always keep it local. - •Usage limit exceeded: many services charge per call or have a monthly free quota. If the agent stops responding from that server, check the usage dashboard before suspecting a bug.
🧭 The agent reads the menu and chooses on its own
When an MCP server is connected, it exposes a list of available "tools" — like a restaurant menu. The agent reads that menu (the technical process is called tool discovery) and, based on what you asked, chooses on its own which one to call and with which parameters. You don’t need to know the exact function name or memorize any syntax — just describe what you want in English.
✓ You do
- ✓Describe the goal in Portuguese: “get the prices from this page”
- ✓Confirm when the agent asks permission to use a sensitive tool
✗ You don't need to
- ✗Memorizing function names or technical parameters
- ✗Write code to connect to the service’s API
In practice, your request becomes a short sequence of automatic steps. See the timeline for "get the prices from this page" with a scraping server connected:
💡 Practical Tip
If the result is empty or incomplete, don’t assume the agent “doesn’t know how to do it.” Ask it to show you what the tool returned—often the site blocked access or changed its layout, and that shows up in the raw response before you even need to rephrase your request.
🖥️ Local × remote: where the MCP server runs
New here? An MCP server can run in two ways: local (a small program installed on your computer that Claude Code starts when it opens) or remote (an internet address that already runs on some server; you just point to it). For the course, you’ll mainly use local servers installed with a single command — easier to understand and audit.
🔍 Inside
A local server runs as a regular process on your computer — you may even see it in the list of running programs. A remote server is hosted by a third party; communication goes over the internet, requiring more care with what you authorize.
✓ Good habit
- ✓Prefer a local server for sensitive data—it stays on your computer and is easier to audit.
- ✓Read what an MCP tool is asking permission for before authorizing it.
✗ Avoid
- ✗Connect an unknown remote server without checking who maintains it.
- ✗Grant access to email or a database "automatically," without reading the request.
An important note, which applies from now on and comes up again in module 2.5 (scraping): when an MCP server fetches information from a third-party website, it is subject to terms of use that site and the request limits it imposes. Some sites block automated access by default—in that case, the server returns an error or a blank page, and the solution isn’t to “try harder”; it’s to check whether that site allows this type of access. And if the data includes other people’s personal information, handle it with the same care you’d give your own information: collect only what’s necessary, and keep only what’s necessary.
🗺️ The map of Module 2
Now that you understand the “why” behind MCP, the next modules build on it: the anatomy of a server (2.2), how to install and authenticate securely (2.3), how to keep the agent smart about which tool to use without bloating CLAUDE.md (2.4), a real build that scrapes a website (2.5), and, finally, running multiple MCP agents in parallel (2.6).
Caption: track 2 is a ladder — each module depends on the previous one. You’re in 2.1 (the “why”); 2.2 through 2.6 build the “how,” ending with several MCP agents working at the same time.