O que é o Model Context Protocol (MCP)

O Model Context Protocol (MCP) e um protocolo aberto criado pela Anthropic que padroniza como modelos de linguagem (LLMs) se conectam a ferramentas externas, bancos de dados, APIs e outros sistemas. Pense nele como um "USB-C para agentes de IA": define um contrato único para que qualquer LLM possa usar qualquer ferramenta sem código de cola específico para cada combinação.

Lançado em novembro de 2024, o MCP ganhou adoção rápida. Editores como VS Code e Cursor, além de plataformas como Claude.ai e IDEs da JetBrains, já suportam servidores MCP nativamente. Em julho de 2026, a especificação recebeu uma atualização significativa: o transport agora e stateless, mudando a forma como clientes e servidores se comunicam.

Para devs brasileiros que estão construindo agentes, automações ou integrando LLMs em sistemas próprios, entender essa mudança e essencial. O protocolo que você implementou em 2024 ou 2025 pode precisar de ajustes.

Como o MCP funcionava antes: transport com estado

Na versão anterior da especificação, o MCP usava um modelo de transport stateful. O cliente (ex: Claude Desktop ou um script Python) iniciava uma conexão persistente com o servidor MCP e mantinha essa sessão aberta durante toda a interação. Era como uma chamada de telefone: a linha ficava aberta do inicio ao fim.

Isso funcionava bem para uso local (servidor MCP rodando na mesma máquina, via stdio). Mas criava problemas ao escalar para ambientes de nuvem, serverless ou quando vários agentes precisavam se conectar ao mesmo servidor simultaneamente.

O servidor precisava manter estado por cliente, o que dificultava deploys em containers sem estado, funções serverless (AWS Lambda, Cloud Run) e proxies reversos tradicionais. Cada reconexao exigia renegociação de sessão, aumentando a latência.

⚠️
Atenção

Servidores MCP implementados com o transport antigo (stateful) ainda funcionam, mas podem não ser compatíveis com clientes que já migraram para o novo padrão stateless. Verifique a versão da spec que seu cliente usa.

A mudança de julho de 2026: transport stateless

A especificação MCP de 28/07/2026 define que o transport HTTP agora deve ser stateless por padrão. Cada requisição do cliente carrega todas as informações necessárias para o servidor processar a chamada, sem depender de estado mantido entre requisições.

Na prática, isso significa que o servidor MCP não precisa mais lembrar "quem e esse cliente" entre chamadas. Cada request e independente, completo em si mesmo. O modelo se aproxima de uma API REST convencional, mas mantendo o contrato de ferramentas e recursos do MCP.

A autenticação e contexto da sessão agora são passados via headers ou no payload de cada requisição, em vez de serem estabelecidos uma vez na conexão. O servidor pode ser implantado em infraestrutura sem estado sem nenhuma adaptação adicional.

💡
Dica

Se você usa MCP via stdio (processo local), essa mudança não afeta você diretamente. O stdio continua funcionando como antes. A mudança e relevante principalmente para servidores MCP expostos via HTTP.

Como começar: atualizando seu servidor MCP para stateless

Se você tem um servidor MCP escrito em Python usando o SDK oficial, o processo de atualização e direto:

# Atualizar o SDK MCP para a versão mais recente
pip install --upgrade mcp

# Verificar a versão instalada
Python -m pip show mcp

Com o SDK atualizado, ao usar o transport HTTP, o servidor já se comporta de forma stateless automaticamente na versão mais recente da biblioteca. O SDK cuida do handshake e das mudanças de protocolo transparentemente.

Para servidores escritos em TypeScript/Node.js:

# Atualizar o pacote @modelcontextprotocol/sdk
npm install @modelcontextprotocol/sdk@latest

# ou com yarn
yarn add @modelcontextprotocol/sdk@latest

Após a atualização, revise se seu servidor armazena estado em variáveis globais ou em memoria entre requisições. Com stateless, esse estado não persiste entre chamadas HTTP separadas.

Exemplo prático: servidor MCP antes e depois

Vejamos um exemplo simplificado. No modelo antigo (stateful), o servidor poderia manter uma lista de operações em memoria:

# Padrão ANTIGO (stateful) - NÃO recomendado para HTTP
class MeuServidor:
    def __init__(self):
        self.histórico = []  # estado mantido entre requests

    def processar(self, tool_call):
        resultado = executar_tool(tool_call)
        self.histórico.append(resultado)  # problema: não escala
        return resultado

No novo modelo stateless, o servidor processa cada request de forma independente:

# Padrão NOVO (stateless) - correto para HTTP
def processar(tool_call, context_from_request):
    # Contexto vem no próprio request, não de estado global
    resultado = executar_tool(tool_call)
    return resultado  # sem efeito colateral persistente

Se você precisa de persistência entre chamadas (ex: contexto de conversa, cache), isso agora e responsabilidade do cliente ou de uma camada de storage externa (Redis, banco de dados), não do servidor MCP.

🚀
Pro tip

Servidores stateless escalam horizontalmente sem configuração adicional. Você pode colocar N replicas atrás de um load balancer e qualquer replica pode atender qualquer request. Isso facilita muito o deploy em Kubernetes ou em serviços gerenciados de container.

Comparação com alternativas: MCP vs. OpenAPI vs. function calling direto

Antes do MCP, a forma mais comum de dar ferramentas a um LLM era via function calling direto na API do modelo (OpenAI, Anthropic, Google). O cliente definia as funções no próprio prompt/request e o modelo retornava qual função chamar. Funciona, mas cada integração era uma ilha: você reescrevia a lógica de tool para cada modelo.

O OpenAPI também é uma alternativa: alguns frameworks convertem specs OpenAPI em tools para LLMs automaticamente. E bom para APIs REST existentes, mas não define como o modelo acessa contexto (arquivos, bancos de dados, etc.), só funções HTTP.

O MCP resolve ambos: padroniza tanto tools (ações que o modelo pode executar) quanto resources (dados que o modelo pode ler) e prompts (templates reutilizáveis). Um servidor MCP escrito uma vez funciona com qualquer cliente MCP, independente do modelo por baixo.

Com o transport stateless, o MCP se torna ainda mais próximo de uma API REST comum, o que facilita a adoção por times que já dominam esse padrão.

Pontos positivos e limitações da nova especificação

Positivos: deploy simplificado em serverless e containers; escalabilidade horizontal sem configuração; compatibilidade maior com proxies e load balancers padrão; integração mais fácil com ferramentas de monitoramento HTTP convencionais.

Limitações: servidores que dependiam de estado em memoria precisam ser refatorados para usar storage externo, o que adiciona latência e complexidade operacional. O stdio transport (para uso local) não mudou, então a melhoria e mais relevante para casos de uso de produção e nuvem do que para uso individual no desktop.

🔴
Cuidado

Não misture lógica de negócio com estado de sessão no servidor MCP. Se seu servidor armazena tokens de autenticação de terceiros em memoria por cliente, você vai perder esses tokens entre requests no modelo stateless. Mova para um armazenamento externo antes de atualizar.

Casos de uso reais que se beneficiam do stateless

Times de produto com pipelines de IA em produção: servidores MCP podem ser deployados como funções serverless (Lambda, Cloud Run), pagando apenas pelo uso real, sem manter instâncias ativas 24h por dia.

Startups com infraestrutura na nuvem: usar um load balancer simples na frente de múltiplas replicas do servidor MCP, sem necessidade de sticky sessions ou configuração especial de afinidade de conexão.

Devs que constroem ferramentas internas: expor dados internos (Notion, Google Drive, banco próprio) via servidor MCP HTTP que qualquer agente da empresa pode consumir, sem precisar de uma instância dedicada por time.

Plataformas SaaS que integram LLMs: cada request de cliente final chega a uma replica diferente do servidor MCP sem problemas, porque não ha estado de sessão para sincronizar entre replicas.

Dicas e boas práticas para migrar

💡
Dica

Antes de migrar, mapeie todos os lugares no seu servidor MCP onde você armazena estado. Uma busca por variáveis de instância e variáveis globais no código e suficiente para identificar o escopo do trabalho.

💡
Dica

Use Redis ou outro cache distribuído para persistir contexto de curta duração entre requests (ex: resultado de uma chamada de API cara que você não quer repetir). O TTL curto (segundos ou minutos) garante que o cache não cresça indefinidamente.

🚀
Pro tip

Escreva testes de integração que criam um novo cliente para cada chamada, sem reutilizar conexão. Se seus testes passarem nesse modelo, o servidor esta genuinamente stateless e pronto para produção.

Vale a pena migrar agora?

Se você usa MCP apenas localmente via stdio (Claude Desktop, extensões de editor), não precisa fazer nada. O stdio não foi afetado pela mudança e continua funcionando normalmente.

Se você tem um servidor MCP exposto via HTTP, sim, vale a pena planejar a migração. A nova especificação e o caminho oficial e os SDKs mais novos vao aderindo a ela progressivamente. Ficar na versão antiga significa acumular divida técnica e potencial incompatibilidade com clientes futuros.

O próximo passo: leia o anuncio oficial, atualize o SDK para a versão mais recente, e rode os testes existentes. Na maioria dos casos, servidores simples não vao quebrar - só os que dependem de estado em memoria vao precisar de refatoração real.