MCP Está Devorando a Economia de APIs
O Protocolo Que Engenheiros Sérios Continuam Descartando
Model Context Protocol está fazendo com a integração de APIs o que REST fez com SOAP: substituir a camada de integração escrita à mão por algo que um agente pode descobrir e usar por conta própria.
Na primeira vez que a maioria dos engenheiros sêniores vê um servidor MCP, descarta como um wrapper em volta de JSON-RPC. E é. Também era o caso de REST sobre HTTP em 2005.
A pergunta que MCP realmente responde é a mesma que REST respondeu mal por vinte anos: como um software expõe suas capacidades para outro software que nunca o viu? A resposta do REST era "leia a doc e escreva um cliente." Essa resposta só funciona se o leitor for um desenvolvedor humano.
Por Que REST Era a Abstração Errada
APIs REST foram feitas para humanos escrevendo código cliente. Endpoints, docs, chamadas fetch à mão na ordem certa com os parâmetros certos. Cada integração é sob medida.
Isso funciona quando o consumidor é um desenvolvedor humano. Quebra quando o consumidor é um LLM. Um LLM não lê seu arquivo Swagger e decide quais três dos doze endpoints encadear. Ele precisa da capacidade descrita na entrada: nome da ferramenta, o que faz, schema de entrada, schema de saída, efeitos colaterais.
MCP dá exatamente esse formato. Uma chamada `tools/list` devolve cada capacidade com um schema JSON sobre o qual o modelo pode raciocinar em tempo de inferência. Sem SDK, sem geração de código, sem ticket de onboarding.
O Desbloqueio da Composabilidade
O que torna MCP transformador não é nenhuma funcionalidade isolada. É a composição em tempo de execução.
Quando cada serviço se expõe como ferramentas MCP, um agente pode descobri-las e encadeá-las em tempo de inferência. Um agente de suporte lê do CRM, consulta o serviço de faturamento, redige uma mensagem de Slack e abre um ticket — usando ferramentas das quais soube trinta segundos atrás. Sem integrações hardcoded. Sem middleware específico do provedor.
Esta é a filosofia Unix aplicada a agentes. Ferramentas pequenas e focadas que se compõem. O compositor não é mais um script de shell; é um modelo capaz de raciocinar sobre quais ferramentas combinar e em que ordem.
O Problema de Segurança Que Todos Ignoram
Tornar trivialmente fácil conectar agentes a ferramentas arbitrárias também torna trivialmente fácil conectá-los a ferramentas maliciosas. Envenenamento de ferramentas — quando a descrição promete um comportamento e a implementação faz outro — é a injeção SQL da era MCP.
A maioria das equipes que entregam servidores MCP hoje não está pensando nisso. Estão focadas em fazer funcionar. Toda grande crise de segurança na história da web começou do mesmo jeito.
As equipes que vão vencer na economia MCP não serão as mais rápidas a entregar. Serão as que resolveram proveniência de ferramentas, sanitização de saída e sandboxing antes de ter que aprender da maneira difícil.
O Que Vem a Seguir
Se você constrói software que outro software consome, já deveria estar entregando uma interface MCP. A economia obriga.
Uma integração REST custa dias de um desenvolvedor. Uma ferramenta MCP custa minutos. Quando a integração fica 100 vezes mais barata, você não ganha 100 vezes mais integrações iguais — ganha categorias inteiras de integração que antes não valiam a pena. Stripe já publica um servidor MCP. Linear também. Supabase também.
Cada SaaS eventualmente exporá ferramentas MCP. Cada serviço interno terá uma interface MCP. A única pergunta real é se você entrega uma antes do seu concorrente.
Posts Relacionados
Pronto para experimentar o SmeltSec?
Gere servidores MCP seguros em 60 segundos. Comece gratuitamente.