MCP (Model Context Protocol): o padrão para ferramentas e contexto
O 'USB-C' que conecta modelos a ferramentas e dados de forma padronizada e reaproveitável.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Cada aplicação de IA reinventava a roda: integração com banco de dados aqui, chamada de API ali, tudo acoplado ao modelo de um jeito diferente. O MCP (Model Context Protocol) resolve isso com um contrato único, um protocolo aberto que padroniza como modelos descobrem e chamam ferramentas, recursos e prompts, independente de quem os implementou.
O problema que o MCP resolve
Antes do MCP, cada equipe que queria conectar um LLM a uma ferramenta externa escrevia sua própria camada de integração. Queria buscar dados no S3? Código customizado. Queria consultar um banco de dados? Mais código customizado. Queria reusar essa integração em outro agente, em outro projeto, com outro modelo? Reescrevia tudo.
O resultado era um zoológico de adaptadores incompatíveis. Trocar de modelo significava reescrever integrações. Adicionar uma ferramenta nova significava mexer no núcleo do agente. Compartilhar uma ferramenta entre times era quase impossível sem duplicação.
Esse problema não é novo, é o mesmo problema que o USB resolveu no hardware. Antes do USB, cada periférico tinha seu conector proprietário. Depois do USB (e hoje do USB-C), qualquer periférico fala a mesma língua e qualquer dispositivo consegue usá-lo. O MCP faz o mesmo para ferramentas de IA: define uma interface única que qualquer cliente (agente, app, IDE) pode usar para descobrir e chamar qualquer ferramenta exposta por qualquer servidor MCP.
Arquitetura MCP: cliente ↔ servidor
Um cliente MCP (agente, IDE, app) descobre ferramentas, recursos e prompts expostos por servidores MCP independentes. O modelo decide o que chamar; o protocolo padroniza como a chamada acontece.
- Agente / App · MCP Client
- LLM · Raciocínio + decisão
- MCP Protocol · JSON-RPC 2.0
- MCP Server · Banco de dados
- MCP Server · API externa
- MCP Server · Arquivos / S3
- Bedrock AgentCore · Gateway MCP
Cliente MCP, servidor MCP, e o que cada um faz
O protocolo divide o mundo em dois papéis bem definidos.
Servidor MCP é quem expõe capacidades. Ele declara ferramentas (tools), recursos (resources, dados que o modelo pode ler, como arquivos ou registros de banco) e prompts reutilizáveis (prompts). Um servidor MCP é basicamente um processo que responde a chamadas JSON-RPC 2.0 em um transporte (stdio, HTTP+SSE ou WebSocket). Qualquer time pode escrever um servidor MCP para sua API interna e disponibilizá-lo para todos os agentes da empresa.
Cliente MCP é quem consome essas capacidades. O agente (ou IDE, ou app) chama tools/list para descobrir o que está disponível, e tools/call para executar. O cliente não precisa saber nada sobre a implementação interna do servidor, só precisa entender o contrato MCP.
O LLM em si não fala MCP diretamente. Ele usa tool calling (aula 07) para decidir qual ferramenta invocar e com quais argumentos. O agente, atuando como cliente MCP, traduz essa decisão em uma chamada MCP real. Essa separação é importante: tool calling é o mecanismo pelo qual o modelo decide agir; MCP é o protocolo pelo qual a ação é executada de forma padronizada. São camadas complementares, não concorrentes.
Tool Calling vs MCP, não é a mesma coisa
| Aspecto | Tool Calling (Aula 07) | MCP |
|---|---|---|
| O que é | Capacidade do LLM de decidir chamar uma função | Protocolo de transporte e descoberta de ferramentas |
| Quem age | O modelo (raciocínio) | O agente/cliente (execução) |
| Onde vive | Dentro do ciclo de inferência | Na camada de integração / infraestrutura |
| Padronização | Varia por provedor (OpenAI, Anthropic, Bedrock…) | Protocolo aberto único (Anthropic, adotado pela indústria) |
| Reuso entre projetos | Não, cada app define seus próprios schemas | Sim, servidor MCP é reutilizável por qualquer cliente |
Na prática, o MCP muda onde você coloca o esforço de integração. Sem MCP, cada agente novo que precisa acessar seu sistema de CRM exige que alguém escreva e mantenha um wrapper específico. Com MCP, você escreve o servidor MCP do CRM uma vez e qualquer agente da empresa, independente do modelo, do framework ou do time, pode descobrir e usar essas ferramentas automaticamente. O investimento se paga na segunda integração. Minha recomendação: trate servidores MCP como microserviços de capacidade. Versione-os, documente os schemas das ferramentas com cuidado e aplique autenticação no transporte, não assuma que por ser interno está seguro.
MCP, quem é quem
Toque num conceito e depois na definição.
Por que isso importa para arquitetura: reuso, desacoplamento e ecossistema
O ganho arquitetural do MCP vai além de economizar linhas de código. Ele introduz desacoplamento real entre o modelo e as ferramentas. Você pode trocar o LLM de Claude para Titan sem tocar nos servidores MCP. Pode atualizar a implementação de uma ferramenta sem redeployar o agente. Pode auditar todas as chamadas de ferramenta em um único ponto de entrada.
O ecossistema já é relevante: IDEs como Cursor e VS Code Copilot são clientes MCP. Ferramentas como GitHub, Slack e Postgres já têm servidores MCP públicos. Isso significa que um servidor MCP que você escreve hoje para seu agente pode amanhã ser usado diretamente por um desenvolvedor no IDE, sem nenhuma mudança.
Na AWS, o Bedrock AgentCore Gateway (que veremos na aula 17) expõe ferramentas via MCP, funcionando como um servidor MCP gerenciado. Você registra suas ferramentas uma vez e qualquer cliente MCP, seja um agente Bedrock, seja um agente externo, pode descobri-las e chamá-las com autenticação e observabilidade já incluídas.
O padrão também define recursos (resources): dados que o servidor expõe para o modelo ler diretamente no contexto, sem precisar de uma chamada de ferramenta. Pense em um arquivo de configuração, um registro de cliente ou um schema de banco, o servidor MCP os expõe como recursos, e o cliente os injeta no contexto do modelo quando necessário. Isso complementa o RAG (aula 06): RAG busca dinamicamente; recursos MCP são referências estruturadas que o agente sabe que existem.
O que fixar sobre MCP
resources) permitem que o servidor exponha dados estruturados diretamente no contexto do modelo, complementando o RAG.Dúvidas frequentes sobre MCP
MCP substitui o tool calling nativo do modelo?
Não. Tool calling é o mecanismo interno do LLM para decidir agir. MCP é o protocolo externo que padroniza como o agente executa essa ação. Você precisa dos dois: o modelo decide, o MCP entrega.
Preciso de MCP para construir um agente funcional?
Não para um protótipo. Mas sem MCP, cada nova integração é acoplada ao agente. MCP começa a valer quando você tem mais de uma ferramenta, mais de um agente, ou mais de um time. É uma decisão de escala, não de funcionalidade.
MCP é seguro por padrão?
O protocolo define os mecanismos (OAuth 2.0 para HTTP, por exemplo), mas a implementação de segurança é sua responsabilidade. Um servidor MCP sem autenticação exposto internamente ainda é um risco, qualquer agente comprometido pode chamá-lo. Aplique autenticação, autorização por ferramenta e logging de todas as chamadas.
Qual a diferença entre MCP e uma API REST comum?
Uma API REST você projeta livremente. O MCP define um contrato específico para descoberta de ferramentas (tools/list), execução (tools/call), leitura de recursos e uso de prompts, um contrato que qualquer cliente MCP já sabe falar. É a diferença entre um cabo proprietário e um USB-C.