MCP - model context protocol
MCP (Model Context Protocol) padroniza como um cliente LLM descobre, lista e chama capacidades expostas por servidores: tools (ações), resources (dados) e prompts (templates). Uma interface única para integrar com qualquer fonte.
O que é
MCP () é um protocolo aberto que padroniza a conversa entre um cliente LLM (o host, geralmente um IDE ou app de chat) e servidores externos que expõem capacidades. Em vez de cada provedor de ferramenta inventar sua própria API, todo servidor MCP fala o mesmo JSON-RPC e todo cliente MCP descobre tudo igual.
Pense em USB-C para agentes. A peça física mudou uma vez; o ecossistema ganhou. A mesma ideia aqui: o protocolo muda uma vez, e um servidor escrito para o Claude Desktop funciona no Cursor, no Continue e em qualquer host que reenvie a mensagem.
as observações deste tópico valem o pino P da especificação: revisão 2025-06-18 da Model Context Protocol. Releases posteriores podem introduzir capacidades novas (sampling, elicitation, roots) e mudar contratos existentes; confira a versão da spec que o SDK declara antes de adotar.
Host, client e server: a topologia
Três papéis coexistem na especificação. Confundi-los é o erro mais comum ao ler documentação.
host: o aplicativo onde o usuário está (IDE, chat, agente). Ele hospeda os clientes e coordena permissões. Em geral um host roda muitos clientes.
client: vive dentro do host, fala com um único servidor via JSON-RPC. É o objeto que serializa as chamadas e negocia capabilities.
server: o processo que expõe tools, resources e prompts. Pode rodar localmente via stdin/stdout, ou remotamente via HTTP com SSE. É onde vive a lógica de integração.
O transporte típico local é stdio: o host spawna o server como subprocesso e fala JSON-RPC linha a linha. Em ambientes distribuídos, o transporte é Streamable HTTP, com POST para mensagens e GET com text/event-stream para notificações.
Host (Claude Desktop, Cursor, VS Code, app própria)
|
| 1:N
|
+-- Client MCP (stdio) <--> Server MCP local (ex: filesystem)
+-- Client MCP (stdio) <--> Server MCP local (ex: postgres)
+-- Client MCP (HTTP+SSE)<--> Server MCP remoto (ex: API SaaS)
Transporte sempre é JSON-RPC 2.0. Estado de sessão é por connection.Tools, resources e prompts
O server expõe três tipos de capacidade, cada um com um papel claro no ciclo do agente:
tools: ações que o modelo pode invocar. Análogas a function calls: nome, schema JSON, side effects. O LLM escolhe quando chamar baseado na descrição.
resources: dados que o host pode ler. Passivos, identificados por nome ou URI (ex: file:///docs/spec.pdf, db://customers/42). O host decide quando incluir no contexto; o modelo só vê o conteúdo que o host escolheu.
prompts: templates de prompt que o usuário invoca explicitamente (ex: '/summarize este arquivo'). Não são descobertos pelo modelo — ficam como slash commands no host.
{
"name": "docs-server",
"version": "0.2.1",
"capabilities": {
"tools": { "listChanged": true },
"resources": { "subscribe": true, "listChanged": true }
},
"tools": [
{
"name": "search_docs",
"description": "Busca trechos relevantes na base de documentação.",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" },
"top_k": { "type": "integer", "default": 5 }
},
"required": ["query"]
}
}
],
"resources": [
{
"uri": "file:///docs/architecture.md",
"name": "arquitetura",
"mimeType": "text/markdown"
}
]
}Como o cliente descobre capacidades
Quando o host sobe um client MCP, a primeira mensagem é initialize, com a versão do protocolo e as capabilities do cliente. O server responde com suas próprias capabilities. Daí em diante, o host chama tools/list, resources/list e prompts/list para montar o catálogo disponível.
Cada capacidade pode declarar listChanged: true, indicando que o server vai emitir notifications/resources/list_changed ou notifications/tools/list_changed quando algo mudar. O host re-lista e atualiza o catálogo sem precisar reiniciar.
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
const transport = new StdioClientTransport({
command: 'npx', args: ['-y', '@modelcontextprotocol/server-filesystem', '/docs'],
});
const client = new Client({ name: 'host', version: '1.0.0' }, { capabilities: {} });
await client.connect(transport);
const { tools } = await client.listTools(); // -> catálogo para o LLM
const { resources } = await client.listResources(); // -> dados disponíveis
const result = await client.callTool({
name: 'search_docs',
arguments: { query: 'como funciona checkpoint', top_k: 3 },
});Pontos fortes
- interoperabilidade: um server MCP serve vários hosts sem reescrita; trocar de IDE não é reescrever integração
- descoberta dinâmica: tools e resources aparecem em tempo de conexão, sem reiniciar o host
- separação clara de papéis: tools são ações, resources são dados, prompts são templates — sem ambiguidade
- transporte flexível: stdio para local, HTTP+SSE para distribuído; o contrato sobre o token é o mesmo
Limitações
- tools ainda são ação do modelo: o server pode chamar APIs perigosas — autorização e sandboxing ficam por conta do host
- spec evolui rápido: 2025-06-18 é o pino deste tópico; sampling/elicitation/roots são áreas em expansão
- debug remoto é mais difícil: HTTP+SSE esconde o ciclo de vida; logs e handlers são equivalentes em importância
- trust on first connect: o host precisa confiar no server; assinatura de pacotes e allowlist ainda são responsabilidade de deployment
conexões no mapa
- Tool callingfala o protocoloMCP - model context protocol
atualizado em 14/10/2026 · fontes para aprofundar · reportar erro
em outros domínios
- Protegendo o próprio agentvibecodingtodo servidor MCP conectado amplia o que o agente pode fazer
- Secrets Scanningappsectokens de servidores MCP vazam do mesmo jeito
Estude antes
teste o que entendeu
Carregando perguntas…