Até aqui a relação da maioria dos desenvolvedores com API foi basicamente a mesma: você expõe um endpoint, documenta com Swagger e o cliente chega já sabendo o que vai pedir. Esse contrato funciona há décadas e ainda funciona bem para boa parte dos sistemas que a gente constrói. O problema é que no último ano surgiu um novo tipo de cliente que simplesmente não consegue seguir esse fluxo — e ele está mudando de forma silenciosa a forma como a gente vai construir software backend daqui em diante.
O problema do REST com agentes de IA
O REST foi desenhado para um mundo em que quem consome a API é um humano ou uma aplicação construída por um humano. Nos dois casos alguém leu a documentação antes, entendeu que existe um GET /flights, escreveu o código que faz essa chamada e definiu o que fazer com a resposta. O contrato entre cliente e servidor é fechado em tempo de projeto. O cliente chega na requisição já sabendo exatamente o que vai pedir.
Esse modelo funcionou muito bem porque os clientes das nossas APIs sempre foram determinísticos. Um app mobile chama sempre os mesmos endpoints. Um sistema de parceiro integra contra uma lista fixa de operações. A variação é pequena e previsível.
O agente de IA quebra essa premissa completamente. Um agente não foi programado para chamar um endpoint específico. Ele recebe um objetivo em linguagem natural — “marque uma passagem para Lisboa antes das 4 da tarde” — e precisa descobrir por conta própria o que o servidor é capaz de fazer para atingir esse objetivo. Não existe código escrito de antemão para aquela interação. O agente precisa explorar as capacidades disponíveis em tempo de execução e decidir o que usar.
O REST, por design, não tem resposta para isso. Ele pressupõe que o cliente já sabe o que existe. E quando o cliente é um agente que ainda não sabe, o protocolo não oferece nenhum mecanismo nativo para que ele descubra.
O que o MCP muda na prática
O MCP — Model Context Protocol, protocolo de contexto para modelos — foi criado pela Anthropic exatamente para preencher esse espaço. A ideia central é simples: em vez de expor endpoints que o cliente precisa conhecer de antemão, o servidor MCP expõe tools — ferramentas acompanhadas de descrições em linguagem natural que o próprio LLM — Large Language Model, modelo de linguagem de grande escala — consegue ler e interpretar.
Quando um agente se conecta a um servidor MCP ele pergunta primeiro: “o que você é capaz de fazer?” O servidor responde com a lista de tools disponíveis, cada uma com seu nome, sua descrição e os parâmetros que aceita. O agente lê essas descrições, entende o que cada tool faz e decide em tempo de execução quais vai acionar para resolver o problema que recebeu. Não existe contrato fechado antes. A descoberta acontece na hora.
O diagrama acima resume bem essa diferença. No lado esquerdo temos o mundo REST: um humano ou uma aplicação faz requisições HTTP com verbos e URLs fixas — GET /users, POST /orders, PUT /products/42 — contra uma API cujos endpoints foram definidos antes e precisam ser conhecidos pelo cliente. No lado direito temos o mundo MCP: o Agente LLM não chega sabendo o que vai pedir. Ele primeiro descobre as tools disponíveis, depois decide qual chamar e por fim interpreta o resultado — tudo de forma autônoma, em runtime. O contraste nas características deixa isso ainda mais claro: enquanto o REST tem contrato fixo de URL + verbo + schema e é stateless por natureza, o MCP expõe ferramentas com schema e descrição em linguagem natural e mantém contexto entre as chamadas, sendo stateful por design.
Um exemplo concreto ajuda a entender o impacto disso. Pensa num site como o Decolar, que hoje precisa consumir as APIs da Latam, da Gol, da Azul e de várias outras companhias para pesquisar preços e horários. Cada integração é um projeto à parte: alguém leu a documentação de cada companhia, escreveu o código específico para cada endpoint e tratou as particularidades de cada resposta.
Com o MCP esse cenário muda. Imagina que você manda um comando de voz: “marque uma passagem para Lisboa no dia 20 de abril, quero chegar antes das 4 da tarde”. O agente acessa as tools que as companhias disponibilizam via MCP, descobre em tempo de execução o que cada uma oferece, avalia as opções que atendem ao critério de horário e te apresenta as alternativas. Você escolhe e confirma o pagamento. Nenhuma integração foi codificada previamente para aquela combinação específica de origem, destino e restrição de horário. O agente montou o raciocínio na hora.
Ainda não é o cenário que temos hoje com todas as companhias aéreas — mas é exatamente a direção para onde o mercado está caminhando nos próximos anos.
O que muda para quem desenvolve o backend
Essa mudança tem uma implicação direta na forma como você pensa a arquitetura do que está construindo.
No REST você pensa em recursos: usuários, pedidos, passagens. Você expõe operações sobre esses recursos e o cliente precisa saber que /orders existe e o que fazer com ele. A modelagem gira em torno de substantivos — o que o sistema tem — e os verbos HTTP cuidam das operações.
No MCP você passa a pensar em capacidades: o que um agente pode fazer no seu sistema? A modelagem gira em torno de ações — o que o sistema consegue executar. Você expõe uma tool cadastrar_cliente com uma descrição clara o suficiente para o LLM entender quando e como usá-la. O próprio agente recebe um comando como “cadastre o cliente fulano, ele tem a idade tal, os documentos são esses e o endereço é esse” e executa o cadastro — sem que nenhum código específico para aquela interação tenha sido escrito antes.
Bom, essa mudança de mentalidade traz consigo uma responsabilidade nova. Numa API REST mal documentada o prejuízo cai sobre o desenvolvedor que vai ler a documentação e perder tempo tentando entender o que cada endpoint faz. Num servidor MCP com descrições ruins ou ambíguas o problema é diferente: o LLM lê a descrição, interpreta do jeito errado e aciona a tool errada. O erro vai para produção de forma silenciosa porque não existe um compilador, um teste de integração ou uma revisão de código que pegue esse tipo de falha. A qualidade da descrição das tools passa a ser tão crítica quanto a qualidade do código em si.
Os dois vão coexistir
É importante deixar claro que o MCP não veio para substituir o REST. Os dois respondem a problemas diferentes e vão continuar existindo lado a lado — como o próprio diagrama resume: “os dois vão coexistir — não é uma substituição”.
Empresas como Stripe, GitHub e Atlassian já estão lançando seus servidores MCP ao lado das suas APIs REST, não no lugar delas. Faz todo sentido. REST continua sendo a escolha certa para apps, browsers e integrações entre sistemas onde o cliente é determinístico e sabe o que quer. MCP é a escolha certa para agentes de IA, copilots e automações autônomas onde o cliente precisa descobrir o que pode fazer.
Na prática o que vai acontecer é que os backends vão passar a ter duas interfaces de comunicação. A interface REST, que já existe e continua atendendo aplicações e integrações tradicionais. E a interface MCP, que expõe as mesmas capacidades do sistema — ou um subconjunto delas — num formato que agentes conseguem consumir de forma autônoma. Não é uma migração. É uma camada nova que se adiciona ao que já existe.
A gente vai continuar desenvolvendo aplicações em que o cliente sabe o que quer. E vai passar a construir também aplicações em que o cliente descobre o que pode fazer. Essa segunda categoria é nova, está crescendo rápido e, na minha visão, os desenvolvedores que aprenderem a entregar esse tipo de solução são os que vão crescer mais na carreira daqui em diante.
Assista também: Como o MCP da Anthropic Matou o Backend Tradicional? De APIs para Humanos e APPs aos Agentes de AI
Treinamentos relacionados com essa postagem
