O problema que o MCP resolve
Um modelo de linguagem só conhece o texto da conversa. Para consultar o seu banco, ler um arquivo ou abrir uma issue, ele precisa de uma ferramenta, e alguém precisa escrever a ponte entre o modelo e o sistema. Antes do MCP, cada aplicativo de IA tinha o próprio formato de ponte: a integração feita para um não servia em outro.
O Model Context Protocol padroniza essa ponte. Quem tem um sistema escreve um servidor MCP uma vez; qualquer aplicativo que fale o protocolo consegue usá-lo. É por isso que o mesmo servidor do GitHub funciona no Claude Desktop, no Cursor e no VS Code.
As três peças: host, cliente e servidor
- Host é o aplicativo de IA: Claude Desktop, Claude Code, VS Code. Ele coordena tudo e é onde está o modelo.
- Cliente MCP é um componente dentro do host. O host cria um cliente para cada servidor, e cada cliente mantém uma conexão dedicada.
- Servidor MCP é o programa que fornece contexto: ferramentas, dados e modelos de prompt. Pode rodar na sua máquina ou em um serviço remoto.
No dia a dia, as pessoas chamam o aplicativo inteiro de "cliente" (o Cursor é um "cliente MCP"). Este site usa a palavra nesse sentido comum; a distinção entre host e cliente importa quando você lê a especificação.
O que um servidor oferece
A especificação define três primitivas do lado do servidor:
- Tools (ferramentas): funções que o modelo pode pedir para executar, como consultar um banco ou criar um arquivo. É a primitiva mais usada.
- Resources (recursos): dados que dão contexto, como o conteúdo de um arquivo ou o esquema de um banco.
- Prompts: modelos de interação reutilizáveis, que o usuário aciona.
O cliente descobre o que existe com chamadas de listagem (tools/list, por exemplo) e executa com tools/call. Cada ferramenta tem nome, descrição e um esquema dos parâmetros. O modelo lê a descrição para decidir quando usar a ferramenta, e por isso uma descrição mal escrita, ou maliciosa, muda o comportamento do assistente.
Do lado do cliente, a primitiva atual é a elicitation, que permite ao servidor pedir uma informação ou uma confirmação ao usuário. A documentação informa que sampling e logging pelo protocolo foram marcados como descontinuados na versão 2026-07-28.
Duas camadas: dados e transporte
A camada de dados é a conversa em si, em JSON-RPC 2.0: pedidos, respostas e notificações. A camada de transporte é o canal por onde as mensagens passam. Há dois:
- stdio: o host inicia o servidor como um processo local e conversa pela entrada e saída padrão. Não há rede. É o caso do servidor de arquivos.
- Streamable HTTP: o servidor fica em uma URL e recebe requisições HTTP, com streaming opcional. É o transporte dos servidores remotos, e a especificação recomenda OAuth para a autenticação.
Essa diferença aparece direto no arquivo de configuração. Um servidor local é descrito por command e args; um remoto, por uma url. O gerador escreve a forma certa para cada caso.
Uma chamada, do começo ao fim
- Você abre o aplicativo. Ele lê a configuração, inicia os servidores locais e se conecta aos remotos.
- Para cada servidor, o cliente pergunta o que ele suporta e pede a lista de ferramentas.
- Você escreve um pedido. O modelo recebe o seu texto e as descrições das ferramentas disponíveis.
- O modelo decide chamar uma ferramenta e produz os argumentos.
- O host mostra o pedido de aprovação, se estiver configurado para isso, e encaminha a chamada ao servidor certo.
- O servidor executa e devolve o resultado, que entra na conversa. O modelo usa esse resultado para responder.
Na versão 2026-07-28, a especificação descreve o protocolo como sem estado: cada requisição carrega a versão do protocolo e as capacidades do cliente, e o servidor anuncia o que suporta pelo método server/discover. Versões anteriores usavam um aperto de mão inicial (initialize). No nosso teste dos tutoriais, o SDK 2.3.0 respondeu aos dois modos.
Quem cuida do protocolo
O MCP foi criado pela Anthropic e aberto em novembro de 2024. A especificação, os SDKs e os servidores de referência ficam na organização modelcontextprotocol no GitHub. Há um registro oficial de servidores em registry.modelcontextprotocol.io, com API pública, que o nosso catálogo consulta para mostrar a situação das entradas conferidas.
O que o MCP não é
- Não é um modelo. O protocolo não gera texto. A própria documentação diz que ele trata só da troca de contexto, e não de como o aplicativo usa o modelo.
- Não é uma camada de segurança. Um servidor local roda com as suas permissões. O protocolo não impede que um servidor mal escrito, ou mal-intencionado, faça mais do que anuncia. Veja Segurança no MCP.
- Não substitui a sua API. O servidor quase sempre chama uma API que já existe. O ganho é a padronização: escrever uma vez e usar em vários clientes.
Por onde seguir
Para ver funcionando, faça o primeiro tutorial: dez minutos, sem token. Para escolher servidores, vá ao catálogo. Para escrever o seu, comece pelo servidor em TypeScript.