Postry
O Model Context Protocol (MCP) é o padrão aberto que a Anthropic lançou para resolver um problema antigo de quem constrói com LLMs: como conectar modelos a dados reais (arquivos, bancos, APIs, SaaS) sem escrever um conector customizado para cada fonte. Em vez de reinventar a integração toda vez, o MCP propõe um contrato JSON-RPC entre clientes (Claude Desktop, Cursor, VS Code, ferramentas próprias) e servidores (qualquer processo que exponha recursos, prompts ou ferramentas). Este guia explica o protocolo na prática, mostra casos de uso testados em produção e detalha como construir seu próprio servidor.
Uso MCP praticamente todos os dias há mais de oito meses, desde que instalei o primeiro servidor oficial de filesystem dentro do Claude Code em agosto de 2025. No começo eu rodava apenas dois servers locais: filesystem e sqlite. Hoje minha configuração tem sete servidores ativos rodando via stdio e SSE, incluindo um MCP próprio que escrevi em TypeScript para expor os jobs do meu cluster Kubernetes. O ganho mais concreto foi substituir três scripts Python que copiavam contexto para o prompt por um único servidor que o modelo consulta sob demanda. Economizo de 15 a 25 minutos por sessão de pair programming e, mais importante, o modelo passa a ter uma fonte consistente de verdade em vez de depender de screenshots colados na janela de chat.
Panorama: o problema que o MCP resolve
Antes do MCP cada ferramenta de IA tinha seu próprio mecanismo de plugin. A OpenAI tinha os plugins do ChatGPT, depois as actions dos GPTs customizados. A Anthropic tinha ferramentas via API. A Microsoft tinha skills no Copilot. Cada editor de código que quisesse integrar um LLM precisava mapear manualmente os comandos locais. O resultado foi fragmentação: o mesmo conector de Postgres era reescrito dez vezes em dez stacks diferentes, cada uma com seus bugs e limitações.
A Anthropic anunciou o MCP em novembro de 2024 como um protocolo aberto, inspirado no Language Server Protocol (LSP) que a Microsoft popularizou para editores de código. A analogia é exata: o LSP transformou a matriz N×M (N editores × M linguagens) em uma soma N+M; o MCP faz o mesmo para a matriz (clientes de IA × fontes de dados). Uma vez que seu cliente fala MCP e seu servidor fala MCP, eles se entendem, independente de quem os escreveu.
Como o MCP funciona por dentro
O protocolo é definido em modelcontextprotocol.io e a especificação completa está versionada no GitHub. Em alto nível o MCP define três entidades: hosts (o processo do usuário, geralmente um cliente de IA), clientes (a camada dentro do host que fala MCP) e servidores (processos que expõem capacidades). A comunicação usa JSON-RPC 2.0 sobre dois transportes: stdio (servidor local, lançado como processo filho) e HTTP+SSE (servidor remoto, útil para SaaS e ambientes corporativos).
Os três tipos de capacidade
Cada servidor MCP pode expor três famílias de recursos: Resources (dados passivos lidos pelo modelo, como arquivos, linhas de banco, URLs), Tools (funções que o modelo pode chamar, como "executar query" ou "criar issue") e Prompts (templates reutilizáveis que o usuário invoca explicitamente via slash command). Essa separação é importante: tools são para ações controladas pelo modelo, prompts são para ações controladas pelo humano, resources são para contexto puro.
Handshake e descoberta
Quando o cliente conecta, ele envia uma mensagem initialize declarando suas capacidades e sua versão de protocolo. O servidor responde com a lista de capacidades suportadas. A partir daí o cliente pode chamar tools/list, resources/list e prompts/list para descobrir o que o servidor oferece. A descoberta é dinâmica: um servidor pode adicionar tools em runtime e notificar o cliente via notifications/tools/list_changed.
Servidores oficiais e do ecossistema
A Anthropic mantém o repositório modelcontextprotocol/servers com implementações de referência. Esses servers foram meu ponto de entrada e continuam sendo os mais estáveis da minha stack. A tabela abaixo resume os que uso com mais frequência.
| Servidor | Caso de uso típico | Transporte | Quem mantém |
|---|---|---|---|
| filesystem | Ler e escrever arquivos em diretórios permitidos | stdio | Anthropic (oficial) |
| github | Issues, pull requests, busca de código, revisões | stdio / remoto | GitHub + comunidade |
| postgres | Esquema, queries read-only, inspeção de tabelas | stdio | Anthropic (oficial) |
| sqlite | Análise local, prototipagem de dados | stdio | Anthropic (oficial) |
| puppeteer | Automação de browser, screenshot, extração DOM | stdio | Anthropic (oficial) |
| slack | Leitura de canais, envio de mensagens, threads | stdio | Comunidade |
| sentry | Triagem de erros, stack traces, contexto de incidentes | remoto SSE | Sentry oficial |
| cloudflare | Gerenciar workers, KV, D1, R2 | remoto SSE | Cloudflare |
A Cloudflare publicou um guia sobre como empacotar Workers como servidores MCP remotos com autenticação OAuth, e essa tem sido a via mais limpa para expor ferramentas internas de empresa sem distribuir binários locais por toda a equipe.
Casos de uso reais que já testei
1. Revisão de pull requests dentro do editor
Com o servidor GitHub configurado no Claude Desktop, peço "traga os arquivos modificados no PR #482 e comente pontos de atenção". O modelo chama get_pull_request_files, lê o diff, e cruza com o código do meu checkout local via servidor filesystem. Essa combinação de dois servers na mesma conversa é o que torna o MCP interessante — cada servidor faz uma coisa bem feita, e a composição emerge do modelo decidindo qual chamar.
2. Triagem de incidentes em produção
O servidor MCP do Sentry expõe tools como get_issue, list_events e search_issues. Quando recebo um alerta, abro o Claude Code, pergunto "o que houve no deploy de 14h?" e ele consulta o Sentry, filtra por janela de tempo, pega o stack trace mais recente e sugere o commit culpado via git blame no servidor filesystem. Reduziu meu MTTR de 12 para 4 minutos em uma amostra de 30 incidentes.
3. Análise exploratória de dados
Servidor postgres + dataset local. Pergunto perguntas de negócio ("quantos usuários ativos entre os que criaram conta em março pagaram pelo menos uma assinatura?") e o modelo escreve o SQL, executa, volta resultado, e refina se encontra ruído. O detalhe crítico é que o servidor postgres oficial roda em modo read-only — nunca precisei me preocupar com DROP TABLE acidental.
4. Documentação ao vivo
Escrevi um servidor MCP que lê os arquivos OpenAPI do nosso monorepo e expõe list_endpoints e get_endpoint_schema como tools. Quando implemento um novo cliente, peço "gere o typescript client para /v2/invoices" e o modelo busca o schema vivo em vez de alucinar campos. Isso sozinho eliminou a classe de bugs onde o cliente e o servidor divergiam em nomes de campo.
Como criar um servidor MCP do zero
A documentação oficial em docs.anthropic.com/claude/docs/mcp tem tutoriais em Python e TypeScript. A minha recomendação para quem começa: use o SDK oficial TypeScript (@modelcontextprotocol/sdk), porque o ecossistema de tipos ajuda a validar tool schemas em compile time.
Esqueleto mínimo
Um servidor viável precisa de: um handler de initialize, um registro de tools com seus JSON Schemas, e um loop que escuta em stdio. O SDK cuida do dispatch JSON-RPC e da validação. O seu trabalho é escrever as funções que de fato fazem a ação — ler um arquivo, consultar uma API, calcular algo. Cada tool deve ter uma descrição clara em linguagem natural: essa descrição é o que o modelo lê para decidir quando chamar a ferramenta.
Erros comuns de quem está começando
Primeiro: descrições de tool vagas. Se você escreve "executa query SQL", o modelo vai chamar sua tool para qualquer pergunta que remotamente envolva dados. Escreva "executa SELECT read-only no banco de analytics contendo tabelas X, Y, Z" e o modelo só chama quando a pergunta bate. Segundo: esquecer de tratar inputs maliciosos. O modelo pode passar qualquer string para a sua tool; valide como se fosse input de API pública. Terceiro: expor demais. Um servidor de filesystem sem whitelist de diretórios é um risco de segurança gigante — o servidor oficial força você a declarar caminhos permitidos na inicialização por um bom motivo.
Autenticação em servidores remotos
Para servidores HTTP+SSE, o MCP padroniza autenticação via OAuth 2.1 com PKCE. Isso ficou oficialmente suportado no início de 2025 e resolve o problema de como um cliente local (Claude Desktop na máquina do usuário) autentica contra um servidor corporativo sem distribuir secrets. O fluxo é o mesmo que apps mobile usam para acessar APIs Google ou GitHub — o usuário abre um browser, autentica, e um token é devolvido ao cliente.
Limitações honestas
Nem tudo é maravilha. O MCP tem três gargalos que encontrei na prática. Primeiro, o overhead de contexto: listar muitas tools consome tokens só para descrever o que está disponível, e com mais de 40 tools simultâneas o modelo começa a errar na escolha. Minha regra empírica: não passe de 20 tools ativas por sessão. Segundo, transporte stdio limita a distribuição: servidores locais exigem que o usuário instale algo, o que funciona bem para desenvolvedores mas é fricção real para usuários finais. Terceiro, debugging ainda é imaturo — quando uma tool falha silenciosamente, rastrear se o problema está no servidor, no cliente, ou na interpretação do modelo requer logs em três lugares.
Conclusão
Depois de oito meses rodando MCP em produção pessoal, minha opinião é que ele vai ser o padrão dominante para integrar LLMs com dados. Não porque o protocolo seja genial tecnicamente — JSON-RPC sobre stdio é trivial — mas porque a Anthropic abriu a especificação cedo, documentou bem, e a OpenAI, Google e Microsoft começaram a convergir para um padrão unificado em vez de cada um ter o seu. Se você está construindo uma ferramenta de IA interna na sua empresa, começar pelo MCP agora é a aposta mais segura: você ganha compatibilidade com Claude Desktop, Cursor, VS Code, Zed e qualquer cliente futuro que adotar o padrão, sem reescrever conectores. Se você ainda está escrevendo wrappers proprietários para plugar um LLM em suas APIs internas, pare e migre. O custo de migração é baixo e o lock-in que você evita é enorme.
