Que problema o MCP resolve?

O MCP resolve o problema N×M. Sem um protocolo comum, cada aplicação de IA precisa de um conector próprio para cada sistema externo: N aplicações vezes M sistemas dão N×M integrações para escrever, testar e manter. Com um protocolo, cada aplicação escreve um cliente e cada sistema escreve um servidor. São N+M.

Essa conta é a justificativa inteira do Model Context Protocol, e ela não é nova. É a mesma que motivou o USB em 1996 e o Language Server Protocol em 2016, com os mesmos ganhos e as mesmas ressalvas.

O que costuma passar batido é que o volume de código quase nunca é o problema. O que N×M conta de verdade é o número de acordos bilaterais: cada par aplicação-sistema negocia formato de erro, esquema de autenticação, paginação e nome de campo. É por isso que a comparação com uma API REST responde outra pergunta, e por que os plugins e os GPTs atacaram este mesmo problema e pararam no meio do caminho.

A conta, e onde ela mente

Quatro aplicações e cinco sistemas dão vinte conectores. Com protocolo, quatro clientes mais cinco servidores dão nove implementações. Dez por dez seriam cem contra vinte.

O ponto exato em que a troca começa a valer sai da própria aritmética. N×M passa a ser maior que N+M a partir de duas aplicações e dois sistemas: em 2×2 a conta empata em quatro, e qualquer combinação maior favorece o protocolo. Guarde esse número porque ele é o teto do argumento, não o piso: é o melhor caso, aquele em que todo conector custa igual.

E é aí que a conta mente. Ela pressupõe que as vinte integrações são vinte trabalhos independentes, e dentro de uma mesma empresa elas nunca são. Se as quatro aplicações e os cinco sistemas têm o mesmo dono, o segundo conector reaproveita o primeiro, o terceiro reaproveita os dois, e no fim existe uma biblioteca interna fazendo exatamente o papel do protocolo, de graça, sem processo separado e sem JSON-RPC no meio.

O problema N×M só é real quando as duas populações têm donos diferentes. Aí não existe biblioteca compartilhada para escrever, porque não existe repositório compartilhado. Cada par vira uma negociação: quem trata o erro 429, o que acontece quando o token expira, qual campo é o identificador estável. Um levantamento de 2025 sobre protocolos de interoperabilidade entre agentes formulou isso como o motivo de existir da categoria inteira — integrações ad hoc são difíceis de escalar, proteger e generalizar entre domínios¹.

Vale ver como isso aparece na prática. Um sistema de tickets expõe busca por cursor; o agente do time de suporte espera offset e limite. O sistema devolve o erro de permissão como HTTP 403 com corpo vazio; o agente precisa saber se deve pedir credencial ao usuário ou desistir. O identificador que aparece na interface é o número do ticket, mas o estável é um UUID interno. Nenhuma dessas três decisões é difícil. Todas as três precisam ser tomadas de novo, do zero, por cada aplicação que se conectar àquele sistema, porque não há onde escrever a resposta uma vez só. É esse “de novo, do zero” que o N×M mede.

A economia de código é o efeito colateral. A economia de coordenação é o produto.

O mesmo padrão, três vezes

O USB 1.0 foi publicado em 15 de janeiro de 1996 por um consórcio que incluía Intel, Microsoft, IBM e Compaq. Antes dele, cada classe de periférico tinha sua própria porta física: serial para modem, PS/2 para teclado e mouse, ADB no Macintosh, SCSI para armazenamento. Quem fabricava um dispositivo novo precisava escolher em qual porta encaixar e escrever um driver por sistema operacional. O USB não deixou o driver desaparecer. Ele mudou de quem é o driver: o fabricante do mouse escreve um dispositivo, não um dispositivo por computador.

O Language Server Protocol é o caso mais próximo do MCP, e o mais instrutivo. Antes dele, oferecer autocompletar, ir-para-definição e diagnóstico para a linguagem L dentro do editor E exigia um plugin específico daquele par. Microsoft, Red Hat e Codenvy anunciaram a colaboração em torno do protocolo em 27 de junho de 2016². Um trabalho de 2025 sobre geração de servidores de linguagem descreve o efeito na notação que interessa aqui: o LSP reduz as combinações L×E a L+E, com um único servidor por linguagem conversando com os editores por um plugin de protocolo³.

O MCP repete o desenho em novembro de 2024, com uma diferença de vocabulário. No LSP, o servidor é a linguagem e o cliente é o editor. No MCP, o servidor é o sistema e o cliente é a aplicação de IA. A estrutura é idêntica: JSON-RPC, uma etapa de descoberta do que existe do outro lado e um conjunto fechado de operações.

O mesmo trabalho de 2025 traz a ressalva que raramente aparece quando alguém cita o LSP como caso de sucesso. Quase dez anos depois, implementações sobrepostas de componentes linguísticos continuam sendo um problema: cada servidor de linguagem reescreve seu próprio sistema de tipos, seu próprio analisador e sua própria resolução de nomes, e é justamente essa duplicação que os autores tentam atacar com geração de servidores a partir de uma descrição modular³. O protocolo padronizou a conversa entre as duas pontas e não padronizou nada do que acontece atrás de cada uma.

Espere o mesmo do MCP. O protocolo diz como listar e chamar uma ferramenta. Ele não diz nada sobre como o seu servidor pagina resultado, o que ele faz quando o banco está fora do ar, ou como ele decide que dez linhas de log são suficientes.

O que o protocolo padroniza

Vale ser específico, porque a diferença entre o que está e o que não está na spec é onde a expectativa quebra.

A revisão 2026-07-28 fixa o envelope das mensagens em JSON-RPC 2.0, a operação de descoberta (server/discover), o formato de listagem e chamada das três primitivas, a descrição de argumentos em JSON Schema e dois transportes padrão⁴. Isso é o suficiente para que um cliente que nunca viu o seu servidor consiga descobrir o que ele faz e invocar uma ferramenta com argumentos válidos.

Fora da spec fica tudo o que dá trabalho de verdade: qual a granularidade certa de uma tool, que nome ela deve ter, o que significa cada erro do seu domínio, como você limita a taxa por usuário, como você mapeia a permissão do sistema de origem para quem está do outro lado da conversa. Um estudo de 2025 que mapeou o ciclo de vida de um servidor MCP em quatro fases mostra o tamanho desse resíduo: criação, distribuição, instalação e operação, cada uma com decisões que o protocolo não toma por você⁵.

A promessa honesta do MCP é estreita. Ele troca N×M implementações de plumbing por N+M implementações de plumbing. A lógica de domínio continua sendo N ou M, dependendo de qual lado você está.

Onde o argumento N×M falha

N igual a 1. Se você tem um agente e uma API, o protocolo é custo puro: um processo a mais, um transporte a mais, um formato de mensagem a mais, e nenhum reuso do outro lado. A conta 1×M contra 1+M nunca favorece o protocolo. O ganho só aparece quando o segundo consumidor existe, e ele precisa ser um consumidor de verdade, não um hipotético.

M é menor do que parece. O argumento popular a favor do MCP é o tamanho do catálogo de servidores prontos. Um levantamento de 2025 rastreou seis mercados por 14 dias, coletou 17.630 entradas e validou 8.401 projetos, dos quais 8.060 servidores e 341 clientes. Mais da metade do que estava listado era inválido ou de baixo valor, e os autores registraram monocultura de dependência e manutenção desigual entre os que sobraram⁶. O M efetivo, o dos servidores que você instalaria em produção, é uma fração do M anunciado.

A soma tem um custo que a multiplicação não tinha. Cada tool que um servidor anuncia ocupa espaço no contexto do modelo, em toda chamada. Conectar servidores porque eles existem transforma um ganho de engenharia em uma perda de precisão: o modelo passa a escolher entre dezenas de ferramentas parecidas. Sob N×M, cada aplicação só carregava o que tinha integrado de propósito.

O protocolo se mexe, e agora todo mundo se mexe junto. Este é o efeito colateral menos discutido de centralizar em um contrato. Sob N×M, cada par migrava no seu ritmo, e uma mudança quebrava uma integração. Sob N+M, uma revisão da spec toca N+M implementações ao mesmo tempo. A 2026-07-28 removeu o handshake de initialize e as sessões de transporte, e é a quinta revisão em vinte meses⁴. O que você economizou em conectores, você passou a pagar em acompanhamento de spec.

A superfície compartilhada também compartilha o risco. A descrição de uma tool entra no contexto do modelo e influencia o que ele decide fazer. Sob N×M, uma integração maliciosa afetava um par. Sob N+M, um servidor popular alcança todos os clientes que o instalaram. O mapeamento de ameaças de 2025 sobre o ciclo de vida do MCP existe por causa dessa concentração⁵.

Quanto custa a troca

Não existe número de mercado confiável aqui, então vale olhar a forma do custo em vez da magnitude.

Do lado de quem expõe um sistema, o servidor MCP é um invólucro: você já tem a API, e o servidor traduz entre ela e o protocolo. O custo real não é escrever a primeira versão, é sustentar as decisões que a spec não toma — granularidade das tools, texto das descrições, tratamento de erro que o modelo consiga usar para se corrigir.

Do lado de quem consome, o custo recorrente é contexto. Uma declaração de tool modesta, com nome, descrição e schema, fica na ordem de centenas de tokens, e ela é reenviada a cada chamada ao modelo, não uma vez por sessão. Meça as suas com o endpoint de contagem de tokens do provedor antes de decidir quantos servidores manter ligados. É a única parte dessa conta que você tem como medir com precisão.

O terceiro custo é o que a maioria dos times descobre depois: manter compatível com mais de uma revisão de protocolo enquanto o ecossistema migra. Em julho de 2026, com a 2026-07-28 recém-publicada e a maior parte dos servidores instalados falando revisões anteriores, esse custo é atual e não teórico.

Quando vale a pena

1. Conte os consumidores reais, não os possíveis. Se hoje existe um, escreva function calling direto e siga. A migração para MCP depois é mecânica; a antecipação é que custa caro.
2. Verifique se as duas populações têm donos diferentes. Se são todas suas, uma biblioteca interna entrega o mesmo N+M sem protocolo, sem processo extra e sem versionamento externo.
3. Trate o catálogo público como matéria-prima, não como inventário. Metade do que está listado não passa de protótipo. Leia o código do servidor que você pretende instalar, especialmente as tools que escrevem em algum lugar.
4. Escolha a granularidade antes de escrever a primeira tool. Trinta tools finas e cinco tools grossas resolvem o mesmo problema com custos de contexto muito diferentes, e o protocolo não tem opinião sobre isso.
5. Fixe a revisão de protocolo que você suporta e escreva isso no README. Sob N+M, essa é a informação que evita o bug de integração mais provável dos próximos meses.

O passo 2 é o que mais gente pula. O problema N×M é um problema de fronteira organizacional disfarçado de problema de arquitetura, e quem não tem a fronteira paga o protocolo sem receber o que ele veio vender.

Footnotes

1. Ehtesham et al. (2025) comparam quatro protocolos de interoperabilidade entre agentes e situam a motivação comum a todos: integrações ad hoc são difíceis de escalar, proteger e generalizar entre domínios. ↩

2. O comunicado conjunto de Red Hat, Codenvy e Microsoft, de 27 de junho de 2016, é a origem da data de padronização do LSP citada aqui. ↩

3. Bruzzone et al. (2025) descrevem o efeito do LSP como a redução das combinações linguagem-editor de L×E para L+E, e registram que implementações sobrepostas de componentes linguísticos continuam sendo um problema quase dez anos depois. ↩ ↩²

4. A revisão 2026-07-28 da especificação é a fonte para o que o protocolo fixa, para a remoção do handshake de initialize e para a contagem de revisões. Verificada em 30 de julho de 2026. ↩ ↩²

5. Hou et al. (2025) decompuseram o ciclo de vida de um servidor MCP em quatro fases e derivaram uma taxonomia de ameaças a partir dela. ↩ ↩²

6. Guo et al. (2025) rastrearam seis mercados de servidores MCP por 14 dias, coletaram 17.630 entradas e validaram 8.401 projetos, com mais da metade do catálogo classificada como inválida ou de baixo valor. ↩