MCP: Protocolo e Primitivos · Parte 1
O problema de integração que o MCP resolve, a arquitetura host/client/server e os três primitivos (tools, resources, prompts), com exemplos reais em GitHub, Playwright, ClickUp e Context7.
O problema que o MCP resolve
Onde o tempo vai embora
Quando um time tenta ligar um agente a ferramentas externas sem MCP, o trabalho não fica no prompt. Fica na integração. Cada serviço pede autenticação, paginação, tratamento de erro, rate limit, schema e manutenção contínua.
Se você conecta o agente ao GitHub de um jeito direto, precisa modelar endpoints de issue, pull request, repositório e comentário. Depois faz tudo de novo para Slack, Jira, Notion, banco e cloud.
O ganho real do protocolo
MCP desloca esse custo para um servidor padronizado. O host não precisa aprender a API de cada serviço. Ele aprende a falar MCP. O servidor já expõe as capacidades no formato esperado.
É essa troca que derruba o custo de integração.
A arquitetura em três peças
Host
É a aplicação onde você conversa com o modelo. Claude Desktop, Cursor, VS Code e ChatGPT entram aqui. O host orquestra a experiência e concentra as conexões disponíveis.
Client
É a camada que mantém uma conexão 1:1 com um servidor MCP. Ele cuida do transporte, das mensagens e da negociação entre host e server.
Server
É o conector especializado. Ele expõe ferramentas, contexto e prompts em um formato que qualquer host compatível consegue entender.
O efeito prático
O host vira um hub de conectores. Em vez de criar uma integração fechada para cada app, você conecta servidores MCP reutilizáveis.
Exemplo prático: dentro do Claude Code (host), você pluga os servers GitHub, Playwright, ClickUp e Context7 ao mesmo tempo — cada um client-server, sem reescrever nada.
Os três primitivos do MCP
Tools: quando o modelo precisa agir
Tool é controlada pelo modelo: o Claude decide quando chamar. É uma ação com schema claro. O modelo descobre o catálogo e chama a função quando precisa fazer algo: abrir issue, consultar banco, acionar browser, rodar deploy.
O ponto forte está no schema. O modelo não precisa conhecer sua API interna. Ele só precisa conhecer o contrato da tool.
Exemplo: o server do GitHub expõe tools como create_issue e create_pull_request. Você pede "abre uma issue pra esse bug" e o modelo decide chamar a tool certa. O server do Playwright expõe navigate, click, screenshot — o modelo aciona quando você pede pra testar um fluxo no navegador.
Resources: controlado pela aplicação
Resource é controlado pela aplicação. É o código do app que decide quando buscar e como usar os dados — pra popular um autocomplete na UI ou injetar contexto no prompt, sem tool call. Na interface do Claude, a integração com o Google Drive é um resource: o app escolhe os documentos e injeta o conteúdo.
Mesma lógica no server do ClickUp: a aplicação decide buscar suas tasks e injeta a lista no contexto, sem o modelo pedir. O server do Context7 funciona parecido — injeta a documentação da biblioteca que você está usando direto no contexto, sem tool call.
Prompts: quando o usuário quer um fluxo pronto
Prompt é template curado. O autor do servidor prepara uma instrução, testa, ajusta e deixa pronta para o usuário disparar com um comando.
Prompts não substituem tools nem resources. Eles organizam o jeito de usá-los.
Prompt é controlado pelo usuário: ele dispara via UI ou /comando. Na interface do Claude, os botões de workflow abaixo do chat são prompts.
Como pensar a divisão certa
Uma regra simples ajuda:
| Primitivo | Pergunta |
|---|---|
| Tool | O modelo precisa executar algo? |
| Resource | A aplicação precisa trazer dados (UI ou contexto)? |
| Prompt | O usuário quer um fluxo curado e repetível? |
Quando essa fronteira está clara, o servidor fica mais previsível para quem implementa e mais legível para quem usa.
MCP × tool use
Não são a mesma coisa. Tool use é o mecanismo pelo qual o modelo chama ferramentas. MCP é quem fornece essas ferramentas prontas, num formato padrão. São complementares: o MCP entrega o catálogo, o tool use é o modelo acionando cada item.
Fecho da Parte 1
Se a Parte 1 explica a base, a Parte 2 mostra por que o MCP escala:
- os transportes que ligam host e server
- o ecossistema aberto
- os casos de produção
- a queda de custo de N×M para N+M
Se alguém te perguntou "o que é MCP de verdade?", esta é a resposta curta:
É um protocolo padrão para ligar modelos a ferramentas externas sem reescrever a integração do zero a cada vez.
@developer.israel · MCP · Parte 1 de 2