MCP vs API REST: quando usar cada um
Uma pergunta que aparece em todo diagnóstico de IA em empresa com APIs existentes: "Se já temos API REST, precisamos de MCP?". A resposta curta: depende de quem consome. MCP não é uma versão melhor de REST — é uma camada diferente para um problema diferente. Este artigo clarifica quando cada um vence.
Audiências diferentes, protocolos diferentes
API REST foi projetada para aplicações chamando aplicações: frontend que chama backend, serviço A que chama serviço B. O contrato é HTTP + JSON ou XML. A integração é programada — um dev escreve o código de chamada uma vez, e funciona para sempre até a API mudar.
MCP foi projetado para agentes LLM descobrindo e chamando ferramentas dinamicamente. O modelo não sabe de antemão quais APIs existem — ele descobre via protocolo MCP, lê a descrição da ferramenta e decide quando chamar. É a diferença entre um dev que leu o manual da API e um agente que lê o manual em tempo real.
Comparativo direto
| Dimensão | REST API | MCP |
|---|---|---|
| Consumidor primário | Aplicação / desenvolvedor | Agente LLM |
| Descoberta de capacidades | Documentação (OpenAPI) | Dinâmica via protocolo |
| Transporte | HTTP/HTTPS | stdio (local) ou HTTP/SSE (remoto) |
| Contrato | Schema OpenAPI/JSON Schema | Tool description em linguagem natural + schema |
| Autenticação | API Key, OAuth2, JWT | Depende da implementação; OAuth2 suportado |
| Overhead de integração | Alto (código por cliente) | Baixo (protocolo padrão — todos os clientes se conectam) |
| Latência por chamada | Muito baixa (HTTP direto) | Levemente maior (overhead de protocolo) |
| Observabilidade | Logs HTTP padrão | Requer implementação explícita no servidor |
| Maturidade | Décadas | Desde nov/2024 — jovem |
Quando REST continua sendo a resposta certa
- A API é consumida por aplicações programáticas (mobile app, frontend, outros serviços).
- SLA de latência é crítico (cada ms importa).
- A API já existe, está documentada e funcionando — não há problema de integração por LLM.
- O time não usa agentes LLM ainda (não faz sentido adicionar camada MCP sem consumidor).
- Domínio público ou semi-público — REST com OpenAPI é mais familiar para ecossistema amplo.
Quando MCP agrega valor claro
- Múltiplos clientes LLM (Claude Desktop, Cursor, seu chatbot interno, Copilot) precisam da mesma ferramenta — MCP escreve uma vez, serve todos.
- O agente precisa descobrir dinamicamente o que pode fazer — sem depender de lista hardcoded de chamadas.
- Você quer expor ferramentas internas (banco, ERP, CRM) para agentes sem reescrever wrapper específico por cliente.
- A ferramenta envolve múltiplos passos coordenados pelo LLM — MCP facilita a composição.
O padrão mais robusto: REST + MCP em camadas
Não é versus — é complemento. A arquitetura mais comum que vejo em 2026:
- API REST interna — serve aplicações tradicionais, tem autenticação, versionamento, SLA.
- Servidor MCP — expõe um subconjunto curado das operações REST como "tools" para agentes. O servidor MCP chama a API REST internamente.
- Agente LLM — descobre as tools via MCP, decide quando chamar, o servidor MCP faz a chamada HTTP para a REST API real.
Benefício: a REST API não precisa mudar. O servidor MCP é uma camada fina de adaptação.
Checklist: preciso de MCP?
- [ ] Algum agente LLM (Claude Desktop, Cursor, chatbot interno) precisa chamar minha API? → Se sim, MCP ajuda.
- [ ] Tenho mais de um cliente LLM diferente querendo a mesma ferramenta? → MCP economiza integração.
- [ ] O agente precisa descobrir dinamicamente o que pode fazer? → MCP resolve melhor que function_call hardcoded.
- [ ] Latência sub-milissegundo é crítica? → REST direto, sem MCP no caminho.
- [ ] O consumidor é uma aplicação (não um LLM)? → REST basta.
Conclusão
REST e MCP são ferramentas para audiências diferentes. REST serve aplicações; MCP serve agentes. Se sua empresa só tem aplicações consumindo APIs, REST é suficiente. Se agentes LLM passaram a consumir também, MCP reduz drasticamente o trabalho de integração e governança.
Quer mapear quais das suas APIs fazem sentido virar servidores MCP? O diagnóstico inicial é gratuito.