🔌 O protocolo em linguagem humana

Novo aqui? Até aqui, na Trilha 0 e na Trilha 1, seu agente já sabia ler e escrever arquivos, rodar comandos no terminal e organizar uma pasta de projeto. Isso é muito — mas tem um limite rígido: ele só enxerga o que está dentro do computador onde roda. Pedir pra ele "olhar o site tal" ou "ler minha planilha do Google" sem ajuda extra é pedir pra alguém trancado numa sala sem janela descrever a rua lá fora.

Novo aqui? Uma API (sigla de interface de programação de aplicações) é a "porta de entrada" que um site ou serviço deixa aberta pra programas conversarem com ele — sem API, o único jeito de tirar dado de um site é abrir o navegador e copiar na mão. E "protocolo" é simplesmente um combinado de regras: como pedir, o que informar, em que ordem. Todo protocolo existe pra duas pontas desconhecidas conseguirem se entender sem precisar negociar do zero toda vez — é o mesmo princípio de uma tomada elétrica ou de um idioma comum.

Legenda: sem uma ponte instalada, tudo que está fora da pasta do projeto — sites, planilhas, bancos de dados — é invisível para o agente, mesmo que a informação exista e esteja a um clique de distância no seu navegador.

Novo aqui? MCP significa Model Context Protocol — em bom português, um "combinado" de como um agente de IA conversa com um serviço de fora. Pense numa tomada elétrica padronizada: qualquer aparelho que segue o mesmo formato de plugue encaixa na mesma tomada, sem adaptador. Antes do MCP, cada ferramenta externa exigia um "fio" (código) diferente pra conectar. Com o MCP, todo mundo fala o mesmo formato — o agente pluga e já entende o que aquele serviço oferece.

Legenda: à esquerda, um agente sem MCP só enxerga os arquivos da pasta local. À direita, com MCP ligado, ele conecta numa "tomada padronizada" e alcança serviços de fora — sem você escrever uma linha de código de conexão.

Vale reforçar o que o MCP não é: não é uma inteligência artificial, não é um site, não é um app. É só um combinado de mensagens — parecido com o formato de um e-mail (assunto, destinatário, corpo) — que tanto o agente quanto o servidor MCP sabem montar e ler. Antes desse padrão existir, cada empresa que queria conectar sua ferramenta a um agente de IA inventava seu próprio formato, e cada integração virava um projeto de programação à parte. O MCP tirou essa reinvenção da roda: um padrão, publicado, que qualquer serviço pode adotar.

Novo aqui? Um servidor MCP é um programinha que fica entre o seu agente e o serviço de verdade (Firecrawl, Google Drive, um banco de dados etc.). Ele "traduz" o pedido do agente pro formato que aquele serviço espera, e traduz a resposta de volta. Você não escreve esse tradutor — ele já vem pronto, você só liga (módulo 2.3) e autentica com sua própria chave.

Novo aqui? "Autenticar" quer dizer provar pra um serviço que você é quem diz ser — normalmente com uma chave de API, uma sequência longa de letras e números que funciona como uma senha só sua, gerada no site do serviço. O servidor MCP guarda essa chave num arquivo chamado .env dentro do seu projeto (você vai criar esse arquivo no módulo 2.3) — nunca dentro da conversa com o agente, porque tudo que passa pelo chat pode acabar salvo em algum lugar. O exemplo abaixo é só o formato: nunca use uma chave de verdade num lugar público.

# arquivo .env na raiz do projeto
NOME_DO_SERVICO_API_KEY=SUA_CHAVE_AQUI

Como verificar: peça pro agente "liste as ferramentas MCP disponíveis". Se ele responder com a lista do serviço, a chave foi lida corretamente; se der erro de autenticação, revise o próximo bloco.

Quando um servidor MCP está ligado, ele expõe uma lista de "ferramentas" disponíveis — como um cardápio de restaurante. O agente lê esse cardápio (o processo técnico chama-se descoberta de ferramentas) e, com base no que você pediu, escolhe sozinho qual delas chamar e com quais parâmetros. Você não precisa saber o nome exato da função nem decorar sintaxe nenhuma — só descrever o que quer em português.

Na prática, um pedido seu vira uma sequência curta de passos automáticos. Veja a linha do tempo de "traga os preços dessa página" com um servidor de scraping ligado:

Novo aqui? Um servidor MCP pode rodar de duas formas: local (um programinha instalado no seu computador, que o Claude Code liga quando abre) ou remoto (um endereço na internet que já roda em algum servidor, você só aponta pra ele). Para o curso, você vai usar principalmente servidores locais instalados via um único comando — mais simples de entender e de auditar.

Uma nota importante, que vale desde já e volta com força no módulo 2.5 (scraping): quando um servidor MCP busca informação num site de terceiros, ele está sujeito aos termos de uso daquele site e aos limites de requisições que ele impõe. Alguns sites bloqueiam acesso automatizado por padrão — nesse caso o servidor retorna erro ou uma página vazia, e a solução não é "insistir mais forte", é checar se aquele site permite esse tipo de acesso. E se os dados envolverem informação pessoal de terceiros, trate com o mesmo cuidado que trataria informação sua: colete só o necessário, guarde só o necessário.

Agora que você entende o "porquê" do MCP, os próximos módulos constroem em cima disso: a anatomia de um servidor (2.2), como instalar e autenticar com segurança (2.3), como manter o agente esperto sobre qual ferramenta usar sem inchar o CLAUDE.md (2.4), um build de verdade fazendo scraping de um site (2.5) e, por fim, rodar vários agentes MCP em paralelo (2.6).

Legenda: a trilha 2 é uma escada — cada módulo depende do anterior. Você está no 2.1 (o "porquê"); 2.2 a 2.6 constroem o "como", terminando em vários agentes MCP trabalhando ao mesmo tempo.