O MCP funciona em uma arquitetura cliente-servidor sobre JSON-RPC. Um servidor MCP é um programa pequeno que expõe um conjunto de ferramentas, recursos e prompts através de uma interface padronizada. Um cliente MCP — tipicamente uma aplicação de IA como Claude Desktop, Cursor ou Windsurf — descobre o que o servidor oferece e disponibiliza essas capacidades para o modelo. Quando o modelo decide usar uma ferramenta, o cliente envia uma requisição JSON-RPC para o servidor, recebe o resultado e o alimenta de volta na conversa. A camada de transporte é flexível: servidores podem se comunicar via stdio (para processos locais), HTTP com server-sent events (para serviços remotos) ou HTTP streamável (o transporte mais novo, combinando request-response e streaming em uma única conexão).
Construir um servidor MCP é deliberadamente simples. Em Python, você pode usar o SDK oficial mcp e ter um servidor funcionando em cerca de 20 linhas de código — você decora uma função com @server.tool(), dá a ela uma descrição e parâmetros tipados, e o SDK cuida de JSON-RPC, geração de schema e transporte. Em TypeScript, o pacote @modelcontextprotocol/sdk funciona da mesma forma. O servidor declara suas capacidades na inicialização (quais ferramentas possui, se suporta recursos ou prompts), e o cliente negocia o que quer usar. Isso significa que você pode começar pequeno — um servidor que apenas envolve a API interna da sua empresa — e adicionar capacidades incrementalmente.
O verdadeiro poder do MCP sobre integrações de ferramentas sob medida fica claro quando se considera o problema combinatório que ele resolve. Antes do MCP, se você tivesse 10 aplicações de IA e 10 ferramentas, precisaria de 100 integrações customizadas. Com MCP, você precisa de 10 servidores e 10 clientes — cada um construído uma única vez. Esse é exatamente o mesmo padrão que tornou o USB bem-sucedido: padronize a interface e o ecossistema escala. Na prática, isso significa que um servidor MCP de Postgres construído por um desenvolvedor funciona com Claude, Cursor, Zed e qualquer outro cliente compatível com MCP sem modificação. O ecossistema de servidores MCP já inclui centenas de servidores construídos pela comunidade para bancos de dados, APIs, ferramentas de desenvolvimento e serviços em nuvem.
Existem algumas nuances importantes que profissionais devem conhecer. Primeiro, servidores MCP vêm em dois sabores: servidores locais que rodam na sua máquina (ótimos para acesso a arquivos, bancos de dados locais, ferramentas de desenvolvimento) e servidores remotos que rodam como serviços hospedados (melhores para infraestrutura compartilhada, integrações SaaS). Segundo, segurança é uma consideração real — um servidor MCP tem quaisquer permissões que o processo executando-o tenha, então um servidor mal configurado pode expor dados sensíveis. O protocolo inclui uma etapa de negociação de capacidades, mas controle de acesso e autenticação para servidores remotos ainda estão evoluindo. Terceiro, MCP não é o mesmo que tool use — é uma camada de transporte e descoberta que fica abaixo do tool use. Um modelo que suporta chamada de ferramentas pode funcionar com MCP, mas o MCP também lida com coisas como subscrições de recursos (contexto com atualização ao vivo) e templates de prompt que vão além de simples chamadas de função.
A Anthropic tornou o MCP open source no final de 2024, e a adoção tem sido notavelmente rápida. No início de 2025, já era suportado por Claude, Cursor, Windsurf, Zed, Sourcegraph e muitos outros. A especificação continua evoluindo — a adição de transporte HTTP streamável, autenticação baseada em OAuth para servidores remotos e elicitação (permitindo que servidores peçam input ao usuário durante o fluxo) chegaram em 2025. Se você está decidindo entre construir uma integração de ferramenta customizada e construir um servidor MCP, a rota MCP quase sempre vence: você ganha compatibilidade com todo cliente MCP de graça, e o protocolo é simples o suficiente para que o custo de migração seja próximo de zero.