{"id":1918,"date":"2026-04-04T18:34:00","date_gmt":"2026-04-04T21:34:00","guid":{"rendered":"https:\/\/www.erudio.com.br\/blog\/?p=1918"},"modified":"2026-05-10T18:39:27","modified_gmt":"2026-05-10T21:39:27","slug":"mcp-x-rest-por-que-o-backend-que-voce-conhecia-nao-e-suficiente-para-agentes-de-inteligencia-artificial","status":"publish","type":"post","link":"https:\/\/www.erudio.com.br\/blog\/mcp-x-rest-por-que-o-backend-que-voce-conhecia-nao-e-suficiente-para-agentes-de-inteligencia-artificial\/","title":{"rendered":"MCP x REST: por que o backend que voc\u00ea conhecia n\u00e3o \u00e9 suficiente para agentes de Intelig\u00eancia Artificial?"},"content":{"rendered":"\n\n\n

At\u00e9 aqui a rela\u00e7\u00e3o da maioria dos desenvolvedores com API<\/strong> foi basicamente a mesma: voc\u00ea exp\u00f5e um endpoint, documenta com Swagger e o cliente chega j\u00e1 sabendo o que vai pedir. Esse contrato funciona h\u00e1 d\u00e9cadas e ainda funciona bem para boa parte dos sistemas que a gente constr\u00f3i. O problema \u00e9 que no \u00faltimo ano surgiu um novo tipo de cliente que simplesmente n\u00e3o consegue seguir esse fluxo \u2014 e ele est\u00e1 mudando de forma silenciosa a forma como a gente vai construir software backend daqui em diante.<\/p>\n\n

O problema do REST com agentes de IA<\/h2>\n\n

O REST foi desenhado para um mundo em que quem consome a API \u00e9 um humano ou uma aplica\u00e7\u00e3o constru\u00edda por um humano. Nos dois casos algu\u00e9m leu a documenta\u00e7\u00e3o antes, entendeu que existe um GET \/flights<\/code>, escreveu o c\u00f3digo que faz essa chamada e definiu o que fazer com a resposta. O contrato entre cliente e servidor \u00e9 fechado em tempo de projeto. O cliente chega na requisi\u00e7\u00e3o j\u00e1 sabendo exatamente o que vai pedir.<\/p>\n\n

Esse modelo funcionou muito bem porque os clientes das nossas APIs sempre foram determin\u00edsticos. Um app mobile chama sempre os mesmos endpoints. Um sistema de parceiro integra contra uma lista fixa de opera\u00e7\u00f5es. A varia\u00e7\u00e3o \u00e9 pequena e previs\u00edvel.<\/p>\n\n

O agente de IA<\/strong> quebra essa premissa completamente. Um agente n\u00e3o foi programado para chamar um endpoint espec\u00edfico. Ele recebe um objetivo em linguagem natural \u2014 “marque uma passagem para Lisboa antes das 4 da tarde” \u2014 e precisa descobrir por conta pr\u00f3pria o que o servidor \u00e9 capaz de fazer para atingir esse objetivo. N\u00e3o existe c\u00f3digo escrito de antem\u00e3o para aquela intera\u00e7\u00e3o. O agente precisa explorar as capacidades dispon\u00edveis em tempo de execu\u00e7\u00e3o e decidir o que usar.<\/p>\n\n

O REST, por design, n\u00e3o tem resposta para isso. Ele pressup\u00f5e que o cliente j\u00e1 sabe o que existe. E quando o cliente \u00e9 um agente que ainda n\u00e3o sabe, o protocolo n\u00e3o oferece nenhum mecanismo nativo para que ele descubra.<\/p>\n\n

O que o MCP muda na pr\u00e1tica<\/h2>\n\n

O MCP<\/strong> \u2014 Model Context Protocol<\/em>, protocolo de contexto para modelos \u2014 foi criado pela Anthropic exatamente para preencher esse espa\u00e7o. A ideia central \u00e9 simples: em vez de expor endpoints que o cliente precisa conhecer de antem\u00e3o, o servidor MCP exp\u00f5e tools<\/strong> \u2014 ferramentas acompanhadas de descri\u00e7\u00f5es em linguagem natural que o pr\u00f3prio LLM<\/strong> \u2014 Large Language Model<\/em>, modelo de linguagem de grande escala \u2014 consegue ler e interpretar.<\/p>\n\n

Quando um agente se conecta a um servidor MCP ele pergunta primeiro: “o que voc\u00ea \u00e9 capaz de fazer?” O servidor responde com a lista de tools dispon\u00edveis, cada uma com seu nome, sua descri\u00e7\u00e3o e os par\u00e2metros que aceita. O agente l\u00ea essas descri\u00e7\u00f5es, entende o que cada tool faz e decide em tempo de execu\u00e7\u00e3o quais vai acionar para resolver o problema que recebeu. N\u00e3o existe contrato fechado antes. A descoberta acontece na hora.<\/p>\n\n\"Diagrama\n\n

O diagrama acima resume bem essa diferen\u00e7a. No lado esquerdo temos o mundo REST: um humano ou uma aplica\u00e7\u00e3o faz requisi\u00e7\u00f5es HTTP com verbos e URLs fixas \u2014 GET \/users<\/code>, POST \/orders<\/code>, PUT \/products\/42<\/code> \u2014 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\u00e3o chega sabendo o que vai pedir. Ele primeiro descobre as tools dispon\u00edveis, depois decide qual chamar e por fim interpreta o resultado \u2014 tudo de forma aut\u00f4noma, em runtime<\/em>. O contraste nas caracter\u00edsticas deixa isso ainda mais claro: enquanto o REST tem contrato fixo de URL + verbo + schema<\/em> e \u00e9 stateless<\/em> por natureza, o MCP exp\u00f5e ferramentas com schema<\/em> e descri\u00e7\u00e3o em linguagem natural e mant\u00e9m contexto entre as chamadas, sendo stateful<\/em> por design.<\/p>\n\n

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\u00e1rias outras companhias para pesquisar pre\u00e7os e hor\u00e1rios. Cada integra\u00e7\u00e3o \u00e9 um projeto \u00e0 parte: algu\u00e9m leu a documenta\u00e7\u00e3o de cada companhia, escreveu o c\u00f3digo espec\u00edfico para cada endpoint e tratou as particularidades de cada resposta.<\/p>\n\n

Com o MCP esse cen\u00e1rio muda. Imagina que voc\u00ea 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\u00e7\u00e3o o que cada uma oferece, avalia as op\u00e7\u00f5es que atendem ao crit\u00e9rio de hor\u00e1rio e te apresenta as alternativas. Voc\u00ea escolhe e confirma o pagamento. Nenhuma integra\u00e7\u00e3o foi codificada previamente para aquela combina\u00e7\u00e3o espec\u00edfica de origem, destino e restri\u00e7\u00e3o de hor\u00e1rio. O agente montou o racioc\u00ednio na hora.<\/p>\n\n

Ainda n\u00e3o \u00e9 o cen\u00e1rio que temos hoje com todas as companhias a\u00e9reas \u2014 mas \u00e9 exatamente a dire\u00e7\u00e3o para onde o mercado est\u00e1 caminhando nos pr\u00f3ximos anos.<\/p>\n\n

O que muda para quem desenvolve o backend<\/h2>\n\n

Essa mudan\u00e7a tem uma implica\u00e7\u00e3o direta na forma como voc\u00ea pensa a arquitetura do que est\u00e1 construindo.<\/p>\n\n

No REST voc\u00ea pensa em recursos<\/strong>: usu\u00e1rios, pedidos, passagens. Voc\u00ea exp\u00f5e opera\u00e7\u00f5es sobre esses recursos e o cliente precisa saber que \/orders<\/code> existe e o que fazer com ele. A modelagem gira em torno de substantivos \u2014 o que o sistema tem \u2014 e os verbos HTTP cuidam das opera\u00e7\u00f5es.<\/p>\n\n

No MCP voc\u00ea passa a pensar em capacidades<\/strong>: o que um agente pode fazer no seu sistema? A modelagem gira em torno de a\u00e7\u00f5es \u2014 o que o sistema consegue executar. Voc\u00ea exp\u00f5e uma tool cadastrar_cliente<\/code> com uma descri\u00e7\u00e3o clara o suficiente para o LLM entender quando e como us\u00e1-la. O pr\u00f3prio agente recebe um comando como “cadastre o cliente fulano, ele tem a idade tal, os documentos s\u00e3o esses e o endere\u00e7o \u00e9 esse” e executa o cadastro \u2014 sem que nenhum c\u00f3digo espec\u00edfico para aquela intera\u00e7\u00e3o tenha sido escrito antes.<\/p>\n\n

Bom, essa mudan\u00e7a de mentalidade traz consigo uma responsabilidade nova. Numa API REST mal documentada o preju\u00edzo cai sobre o desenvolvedor que vai ler a documenta\u00e7\u00e3o e perder tempo tentando entender o que cada endpoint faz. Num servidor MCP com descri\u00e7\u00f5es ruins ou amb\u00edguas o problema \u00e9 diferente: o LLM l\u00ea a descri\u00e7\u00e3o, interpreta do jeito errado e aciona a tool errada. O erro vai para produ\u00e7\u00e3o de forma silenciosa porque n\u00e3o existe um compilador, um teste de integra\u00e7\u00e3o ou uma revis\u00e3o de c\u00f3digo que pegue esse tipo de falha. A qualidade da descri\u00e7\u00e3o das tools passa a ser t\u00e3o cr\u00edtica quanto a qualidade do c\u00f3digo em si.<\/p>\n\n

Os dois v\u00e3o coexistir<\/h2>\n\n

\u00c9 importante deixar claro que o MCP n\u00e3o veio para substituir o REST. Os dois respondem a problemas diferentes e v\u00e3o continuar existindo lado a lado \u2014 como o pr\u00f3prio diagrama resume: “os dois v\u00e3o coexistir \u2014 n\u00e3o \u00e9 uma substitui\u00e7\u00e3o”.<\/p>\n\n

Empresas como Stripe, GitHub e Atlassian j\u00e1 est\u00e3o lan\u00e7ando seus servidores MCP ao lado das suas APIs REST, n\u00e3o no lugar delas. Faz todo sentido. REST continua sendo a escolha certa para apps, browsers e integra\u00e7\u00f5es entre sistemas onde o cliente \u00e9 determin\u00edstico e sabe o que quer. MCP \u00e9 a escolha certa para agentes de IA, copilots<\/em> e automa\u00e7\u00f5es aut\u00f4nomas onde o cliente precisa descobrir o que pode fazer.<\/p>\n\n

Na pr\u00e1tica o que vai acontecer \u00e9 que os backends v\u00e3o passar a ter duas interfaces de comunica\u00e7\u00e3o. A interface REST, que j\u00e1 existe e continua atendendo aplica\u00e7\u00f5es e integra\u00e7\u00f5es tradicionais. E a interface MCP, que exp\u00f5e as mesmas capacidades do sistema \u2014 ou um subconjunto delas \u2014 num formato que agentes conseguem consumir de forma aut\u00f4noma. N\u00e3o \u00e9 uma migra\u00e7\u00e3o. \u00c9 uma camada nova que se adiciona ao que j\u00e1 existe.<\/p>\n\n

A gente vai continuar desenvolvendo aplica\u00e7\u00f5es em que o cliente sabe o que quer. E vai passar a construir tamb\u00e9m aplica\u00e7\u00f5es em que o cliente descobre o que pode fazer. Essa segunda categoria \u00e9 nova, est\u00e1 crescendo r\u00e1pido e, na minha vis\u00e3o, os desenvolvedores que aprenderem a entregar esse tipo de solu\u00e7\u00e3o s\u00e3o os que v\u00e3o crescer mais na carreira daqui em diante.<\/p>\n\n

Assista tamb\u00e9m:<\/strong> Como o MCP da Anthropic Matou o Backend Tradicional? De APIs para Humanos e APPs aos Agentes de AI<\/p>\n\n