No capítulo anterior, rodamos um agente mínimo que conecta ferramentas ao cérebro (LLM) e gira o próprio laço. Com aquela experiência, você deve ter percebido — a capacidade real de um agente é definida quase inteiramente por "a que ferramentas ele está conectado". Neste capítulo, saímos do desgaste de criar essas ferramentas do zero toda vez e aprendemos a nos conectar de forma padronizada a ferramentas e dados externos por meio do MCP (Model Context Protocol), um padrão comum. O MCP nasceu no Claude e hoje vem se tornando o padrão de conexão adotado por toda a indústria.
A meta é "conectar-se com segurança por um padrão comum, sem criar ferramentas do zero"
Por que a conexão de ferramentas é o cerne do agente
O LLM em si, por mais inteligente que seja, só sabe "gerar palavras". Saber o estoque atual ou escrever uma linha em um arquivo é impossível se não houver um meio de tocar o mundo externo. Se o agente consegue girar o laço de "investigar, executar, verificar" é justamente porque tem ferramentas que agem no exterior.
Ou seja, o teto da capacidade do agente é definido pela qualidade e quantidade das ferramentas conectadas. Com o mesmo LLM, um agente que só tem uma calculadora e um agente conectado a banco de dados, busca, arquivos e APIs internas conseguem coisas completamente diferentes. Não é raro que conectar boas ferramentas com precisão eleve a capacidade percebida muito mais do que trocar o cérebro por um mais sofisticado.
💡 Mais do que "ser inteligente", vale "ter as ferramentas certas". Até uma pessoa brilhante nada faz com a caixa de ferramentas vazia. Boa parte do tempo de desenvolvimento de agentes é gasta, na verdade, no desenho de "que ferramentas dar, e como dar com segurança". Este capítulo é o núcleo disso.
Os limites da definição de ferramenta "na mão"
No capítulo anterior, definimos as ferramentas com as próprias mãos. Escrever a função, entregar nome, argumentos e descrição ao LLM, executar quando vem a chamada e devolver o resultado — esse fluxo em si está certo e continua sendo o básico. O problema está em refazer isso toda vez, para cada ferramenta, em cada projeto.
Pense, por exemplo, numa "ferramenta para buscar em um banco de dados". Escrever a conexão, montar a query, formatar o resultado, tratar erros, lidar com credenciais em segurança… Esse conjunto todo é implementado por conta própria no seu projeto, na equipe ao lado e em outra linguagem, cada um de um jeito. A realidade da definição "na mão" é que a mesma ferramenta é reinventada infinitas vezes por desenvolvedores no mundo todo.
Uma ferramenta escrita para um projeto fica presa àquele framework e àquela linguagem, e é difícil levar para outro.
Conectar M tipos de ferramenta a N plataformas de agente exige, em tese, N×M variações de código de conexão.
Cada vez que muda a especificação do alvo, é preciso corrigir uma a uma as ferramentas caseiras espalhadas por todo lado.
Isso lembra muito a época em que cada periférico exigia um cabo próprio. Encaixe exclusivo para impressora, encaixe exclusivo para mouse — quanto mais equipamentos, mais explodiam os tipos de conexão. Se houver "um encaixe comum", todo esse incômodo desaparece de uma vez. É aí que entra o MCP.
O que é o MCP — o padrão comum de conexão de ferramentas
O MCP (Model Context Protocol) é um padrão aberto para conectar a IA a ferramentas e dados externos de forma padronizada. A Anthropic o publicou para o Claude no fim de 2024 e, desde então, diversas ferramentas e serviços de IA passaram a suportá-lo. Em 2026, é amplamente adotado além de qualquer fornecedor e cresce como padrão da indústria sob uma governança neutra. O ponto crucial é que ele não é o produto de uma única empresa, mas uma especificação comum que qualquer um pode implementar.
A ideia do MCP, em uma frase, é "o USB da conexão de ferramentas de IA". Assim como, com a chegada do USB, periféricos de qualquer fabricante passaram a funcionar no mesmo encaixe, uma ferramenta compatível com MCP "plugou, usou" em qualquer agente compatível com MCP. Ao seguir o mesmo acordo, quem cria e quem usa dobram o inferno combinatório N×M em "N + M".
O agente que você cria, ou apps como o Claude, ficam deste lado. É quem pergunta ao servidor e chama as ferramentas necessárias: "quais ferramentas estão conectadas agora?".
É quem reúne e expõe funções como "ferramentas": manipulação de arquivos, busca em BD, integração com SaaS. Um único servidor pode ter várias ferramentas.
Os dois conversam por um protocolo definido. Ao se conectar, o cliente primeiro recebe do servidor "a lista de ferramentas disponíveis" e "a descrição e os argumentos de cada uma". O LLM olha essa lista, escolhe a ferramenta que combina com o objetivo e a chama; o servidor a executa e devolve o resultado — que essa ida e volta se realize sem implementação individual por ferramenta é o cerne do MCP.
Cliente → Servidor : "me diga quais ferramentas há" Servidor → Cliente : "search_docs / read_file / query_db, três; as descrições são estas" LLM decide : "vou chamar query_db com o argumento {sql:\"...\"}" Cliente → Servidor : "execute query_db" Servidor → Cliente : "o resultado são estes registros"
Há basicamente 2 formas de publicação. O tipo local, que roda como processo na sua máquina, e o tipo remoto, ao qual você se conecta pela rede. O local serve para os seus arquivos e o BD de desenvolvimento; o remoto, para integrações com SaaS compartilhadas em equipe. Em ambos, o acordo de "receber a lista de ferramentas e chamá-las" é o mesmo, e o modo de lidar do lado do cliente quase não muda.
📖 Primeiro, o panorama. Ler antes o artigo "O que é o MCP", que organiza de forma acessível a origem, os termos e o estado de suporte, faz o conteúdo deste capítulo entrar com naturalidade. Como os detalhes da especificação e as versões evoluem rápido, confira sempre a versão mais recente na documentação oficial antes de implementar.
Usar e criar servidores MCP
A parte mais saborosa do MCP é que você pode usar diretamente servidores já publicados por aí. As ferramentas de uso comum geralmente já estão prontas, feitas por alguém como servidor MCP. Ao conectá-las ao seu agente caseiro, a capacidade aumenta de uma vez, sem reinventar a roda.
Leitura e escrita em uma pasta indicada. A base para fazer o agente ler documentos e escrever os resultados.
Executar SQL e consultar o schema. Diante de "compile isto", ele responde consultando os dados reais.
Busca na web ou na base de conhecimento interna. Vira a "mão que investiga" para trazer informações atuais e evidências.
Gestão de tarefas, chat, armazenamento. Transforma ferramentas de trabalho já existentes em mãos e pés do agente.
O procedimento de conexão em si é simples. Basta iniciar (ou indicar a URL) o servidor que você quer usar e registrar, na configuração do cliente, a localização do servidor e as credenciais. Depois, o agente recebe a lista de ferramentas ao conectar e as chama conforme a necessidade. Você não precisa escrever "o miolo da ferramenta de busca em BD". O seu trabalho passa a ser combinar as ferramentas oferecidas de acordo com o objetivo.
⚠️ "Conectar tudo porque é conveniente" é proibido. A cada servidor a mais, aumentam as descrições entregues ao LLM na medida do número de ferramentas, a decisão se dispersa e cresce a margem para erro. O básico é escolher e conectar só as ferramentas que aquele agente realmente precisa para o seu objetivo. Ferramentas em excesso, na verdade, reduzem a precisão.
Você também pode criar o seu servidor
Ferramentas sem servidor pronto — uma API interna própria, uma lógica de negócio específica — basta escrever você mesmo um servidor MCP. É aqui que está a beleza do MCP: uma vez publicado como servidor, ele pode ser usado da mesma forma por qualquer agente compatível. Uma ferramenta feita para um projeto pode ser reaproveitada, sem reescrita, no próximo projeto e em outro agente da equipe.
O miolo de criar um servidor é "definir como ferramenta a função que você quer oferecer, declarar nome, argumentos e descrição e, quando chamado, executar o processamento e devolver o resultado". A ideia é a mesma da definição "na mão" do capítulo anterior, mas com uma diferença decisiva: o destino de saída não é "um agente específico", e sim "o encaixe comum do MCP". O esforço de criar é uma vez só; o reaproveitamento, quantas vezes quiser.
🛠 Para ir a fundo na implementação. O código concreto para montar agentes e conexão de ferramentas com o Claude está em Introdução ao Claude Agent SDK, bem prático. O SDK já traz o mecanismo para lidar com servidores MCP, e tanto conectar servidores prontos quanto criar os seus pode ser feito seguindo os passos da documentação oficial.
Que ferramentas dar, e como
Quando você passa a "conseguir conectar" ferramentas, a pergunta seguinte é "o quê, e como, dar". Este é o ponto-chave do desenho que decide a qualidade e a segurança do agente, e também a base dos próximos capítulos. Fixemos 3 princípios.
Dê apenas as ferramentas e o alcance necessários àquela tarefa. "Se ler basta, não dê permissão de escrita." Em BD, uma conta limitada só de leitura; em arquivos, só a pasta-alvo — esse é o básico.
O LLM decide usar ou não uma ferramenta apoiado só na descrição. Escreva de forma concreta "o que a ferramenta faz, quando usá-la, o sentido dos argumentos e em que situação não usá-la". Descrição vaga gera uso indevido.
Escrever, apagar, cobrar, executar comandos — operações irreversíveis não ficam no mesmo nível das de leitura. Junte sempre confirmação antes de executar, restrição do alvo e registro.
O ③ é especialmente importante. As ferramentas de "investigar" (busca, consulta, leitura) dificilmente causam grande dano se chamadas por engano. Já as de "alterar" (escrever, apagar, enviar, executar) geram, a cada erro, consequências irreversíveis. A regra de ouro é separar conscientemente leitura de escrita e reforçar as segundas com guardas em camadas.
| Tipo | Exemplo | Risco | Como dar |
|---|---|---|---|
| Leitura | Busca, consulta, leitura de arquivo | Baixo (cuidado com o trato da informação) | Com relativa liberdade. Restrinja o alcance |
| Escrita | Atualizar arquivo, gravar em BD, enviar | Alto (difícil de desfazer) | Confirmação, restrição e registro obrigatórios |
| Execução | Rodar comando, chamada externa, cobrança | Máximo (porta de entrada para descontrole e abuso) | Por princípio, guarda + aprovação humana |
🔒 Isto será tratado a fundo no Capítulo 6. O controle de ferramentas perigosas, as defesas contra prompt injection e o desenho do fluxo de aprovação são temas incontornáveis para levar um agente à produção. Como serão reunidos no Capítulo 6 "Guardrails e segurança", leve daqui apenas a sensação de que "há graus diferentes de perigo entre as ferramentas". Não conectar levianamente servidores MCP não confiáveis também é um hábito importante.
Ferramentas avançadas, como o controle de navegador
Entre as ferramentas, uma que ganhou destaque recente é o controle de navegador. Ver a tela, seguir links, preencher formulários, apertar botões — se o agente puder fazer o que um humano faz no navegador, muitos serviços web sem API própria viram "mãos e pés". Já surgiram implementações que oferecem controle de navegador como servidor MCP, e a barreira de conexão baixou.
Ainda assim, essa é uma das ferramentas mais poderosas e de maior risco. O perigo de acatar como ordem uma instrução escrita na tela (indução, informação falsa), cliques ou envios não intencionais, exposição de credenciais — todos os cuidados com "execução" da seção anterior se aplicam por inteiro. O sensato é começar por usos mais próximos da leitura, como navegar e obter informação, e cercar com guardas cuidadosas as operações que envolvem escrita.
🌐 Até onde dá para delegar? A capacidade real e os limites dos agentes de controle de navegador são verificados de forma concreta em Até onde a IA consegue automatizar tarefas no navegador. Guardar a medida "não é universal, mas, com o uso bem delimitado, é prático" evita que a escolha de ferramentas oscile.
Não só o navegador: quanto mais avançada a ferramenta, mais crescem, na mesma proporção, "o que dá para fazer" e "o que pode acontecer". Quanto mais forte a ferramenta que você entrega, mais cuidado com os 3 princípios — privilégio, descrição e guardas — é a mensagem que repetimos ao longo deste capítulo.
- A capacidade do agente é definida pela qualidade e quantidade das ferramentas conectadas. Muitas vezes, o desenho das ferramentas rende mais que o cérebro.
- Definir ferramentas "na mão" é difícil de reaproveitar e vira o inferno combinatório N×M. Passa a fazer falta um encaixe comum.
- O MCP é um padrão aberto que conecta a IA a ferramentas externas de forma padronizada. É o "USB da IA", em que cliente (quem usa) e servidor (quem fornece) conversam pelo mesmo acordo.
- Servidores MCP prontos (arquivos/BD/busca/SaaS) você pluga e usa, e ferramentas próprias você transforma em servidor caseiro e reaproveita.
- Os princípios de como dar são ① privilégio mínimo, ② qualidade da descrição, ③ ferramentas perigosas à parte. Quanto mais forte a ferramenta (como o controle de navegador), mais cuidado.
Com o jeito de reunir ferramentas claro, o próximo estágio é "multiplicar os agentes". Avançamos para o desenho em que o trabalho que um agente não dá conta é dividido e coordenado entre vários. No próximo Capítulo 4 "Desenho multiagente", vamos aprender a divisão de papéis e a cooperação entre agentes (A2A).