MCP ou API REST: quando usar cada um com agentes de IA

MCP ou API REST: quando usar cada um com agentes de IA

MCP e API REST não são concorrentes. A API REST é a porta do seu sistema para qualquer software, e o servidor MCP é uma camada que apresenta partes dessa porta a agentes de IA de um jeito que eles consigam descobrir e usar. Em geral, use API direta quando o fluxo é fixo e conhecido, MCP quando o agente precisa escolher entre várias ferramentas, e os dois quando o mesmo sistema atende código tradicional e agentes.

Principais pontos

• A API REST descreve recursos e operações para qualquer cliente. O MCP descreve ferramentas e dados para um agente de IA, em formato padronizado.
• Em muitos casos o servidor MCP não substitui a API: ele fica na frente dela e chama os mesmos endpoints.
• Fluxo previsto, com passos fixos, costuma ficar melhor como API chamada por um workflow determinístico, sem o modelo decidir nada.
• MCP compensa quando há várias ferramentas, vários agentes ou várias aplicações de IA que precisam reutilizar a mesma integração.
• Permissão, limite e registro de decisões valem igual nos dois caminhos. Nenhum protocolo substitui autorização bem desenhada.

Qual é o papel de cada um?

Uma API REST é um contrato entre sistemas. Ela define endereços, métodos, formatos de entrada e saída, códigos de erro e regras de autenticação. Quem consome é um programa escrito por uma pessoa, que já sabe exatamente qual endpoint chamar e em que ordem. O conhecimento sobre como usar a API vive no código do cliente e na documentação.

Um servidor MCP resolve outro problema. O Model Context Protocol é um padrão aberto para conectar aplicações de IA a sistemas externos, e está descrito na introdução oficial do protocolo. O servidor declara quais ferramentas e quais dados existem, com nome, descrição e parâmetros. O aplicativo de IA, que atua como cliente, lê essa lista e deixa o modelo decidir quando usar cada item.

A diferença de papel fica clara assim: na API, quem decide a sequência de chamadas é o código. No MCP, quem escolhe qual ferramenta usar a cada momento é o modelo, a partir das descrições que o servidor oferece. Por isso a qualidade dessas descrições importa tanto. Se o nome de uma ferramenta é vago ou duas ferramentas se sobrepõem, o agente erra a escolha, mesmo que a API por baixo esteja perfeita.

É comum o servidor MCP ser apenas um tradutor fino. Ele recebe o pedido do agente, valida, chama a API REST que já existe e devolve uma resposta enxuta, pensada para ser lida por um modelo. A API continua sendo a fonte da verdade.

Quando a API REST direta é a melhor escolha?

A API direta vence quando o processo já é conhecido e repetível. Se toda vez que chega um pedido você consulta o cadastro, calcula o frete e grava o resultado, não há decisão de ferramenta a ser tomada. Um workflow com etapas fixas faz isso de forma mais barata, mais rápida e mais fácil de testar. Se em alguma etapa o julgamento do modelo for necessário, como classificar a intenção de uma mensagem, ele entra só naquela etapa, e o restante segue determinístico.

Outros sinais de que a API direta basta:

• Existe um único agente ou um único fluxo consumindo a integração.
• O conjunto de operações é pequeno e estável.
• A equipe já domina a API e tem monitoramento, limites de taxa e tratamento de erro prontos.
• O resultado precisa ser idêntico a cada execução, por exigência de auditoria ou de processo.
• O sistema é de terceiros e o fornecedor já oferece só a API, sem servidor MCP confiável.

Um detalhe técnico que muitos esquecem: quando um agente chama uma API que cria ou altera algo, a mesma chamada pode ser repetida por erro de rede ou por nova tentativa do modelo. Operações que gravam dados devem ser idempotentes. A documentação da Stripe sobre requisições idempotentes mostra um desenho conhecido, com chave de idempotência enviada pelo cliente. O princípio vale para qualquer sistema, inclusive os internos.

Se você precisa construir essa camada de API para agentes, vale ver como FastAPI para agentes de IA trata rotas, validação e filas.

Quando um servidor MCP faz sentido?

MCP começa a compensar quando a integração precisa ser descoberta e reutilizada por agentes, não apenas chamada por um script. Alguns cenários típicos:

• Vários aplicativos de IA, como um assistente de código, um agente de atendimento e um agente interno, precisam acessar o mesmo sistema.
• O agente precisa escolher entre muitas ações conforme a conversa, e não seguir um roteiro fixo.
• Você quer expor dados de consulta (documentos, cadastros, tabelas) e ações em um só lugar, com descrição clara do que cada item faz.
• Você quer trocar de modelo ou de aplicativo de IA sem reescrever a integração.
• A equipe usa ferramentas de desenvolvimento com IA e quer padronizar o acesso a sistemas internos. O guia sobre configurar MCP no Claude Code mostra como escopos local, de projeto e de usuário mudam quem enxerga o quê.

O desenho das ferramentas é o ponto que mais separa uma boa integração de uma ruim. A Anthropic publica orientações sobre como escrever ferramentas eficazes para agentes, e a ideia central é que ferramentas devem ser pensadas para o modelo, não apenas copiadas dos endpoints. Isso significa poucas ferramentas bem nomeadas, descrições sem ambiguidade, parâmetros claros e respostas que devolvam só o contexto necessário, em vez de despejar o JSON bruto da API.

Um erro frequente é transformar cada endpoint em uma ferramenta MCP, um para um. Uma API com dezenas de rotas vira dezenas de ferramentas parecidas, e o agente se confunde. Costuma funcionar melhor agrupar por tarefa: em vez de três chamadas encadeadas para consultar um pedido, uma ferramenta que recebe o número do pedido e devolve o status resumido.

Guia de decisão: API, MCP ou os dois?

Use as perguntas abaixo, na ordem, para decidir como expor um sistema. A primeira resposta afirmativa indica o caminho.

• O fluxo tem passos fixos e a ordem nunca muda? Use API direta, chamada por um workflow determinístico.
• Só uma aplicação vai consumir a integração e ela já é mantida por quem conhece a API? Use API direta.
• O agente precisa decidir qual ação executar a partir de uma lista de opções? Exponha por MCP.
• Mais de um agente ou aplicativo de IA vai reutilizar a integração? Exponha por MCP, com a API por baixo.
• O sistema também atende integrações tradicionais, como o ERP, o site e o aplicativo? Mantenha a API REST como base e acrescente o servidor MCP como camada para agentes.
• A ação é irreversível ou sensível, como cancelar, reembolsar ou apagar? Em qualquer caminho, exija aprovação humana antes da execução.

Se a dúvida persistir, comece pela API. Ela é a base de qualquer um dos dois caminhos, e o servidor MCP pode ser acrescentado depois sem desfazer nada. O inverso, construir MCP sem uma API bem definida atrás, tende a esconder problemas de contrato em descrições de ferramenta.

Segurança e permissões mudam com o protocolo?

Não mudam de lugar. Escolher MCP não reduz a necessidade de autorização, e escolher API não a resolve sozinho. O que muda é quem corre o risco de usar mal: no MCP, é um modelo que pode ser induzido a chamar uma ferramenta que não deveria.

Por isso, o princípio é aplicar o menor privilégio no servidor, não no texto do prompt. O guia da OWASP sobre autorização é uma boa referência: verificar permissão em cada requisição, negar por padrão e não confiar em decisões tomadas só no cliente. Aplicado a agentes, significa que a credencial usada pelo servidor MCP deve ter apenas as permissões da tarefa, e que a checagem deve acontecer no sistema, mesmo que a ferramenta esteja descrita como segura.

Há ainda o risco de instruções maliciosas escondidas em dados que o agente lê, como um e-mail ou um campo de cadastro. Isso é prompt injection, e o artigo sobre prompt injection em agentes de IA da empresa detalha as defesas. Na prática: separar ferramentas de leitura e de escrita, limitar o que cada uma devolve e exigir confirmação humana para ações com efeito externo.

Quanto à LGPD, o servidor é um ponto natural para controlar quais dados pessoais saem do sistema. Se a ferramenta devolve só o necessário para a tarefa, o agente nunca vê o restante. Isso reduz a exposição, e também facilita registrar quem acessou o quê. Registre cada chamada de ferramenta com parâmetros, resultado resumido e identificação do fluxo, para que uma decisão do agente possa ser revisada depois.

Cenário ilustrativo: oficina com agenda e orçamento

Cenário ilustrativo: uma oficina mecânica tem um sistema de gestão com API REST que consulta ordens de serviço, lista horários livres e cria agendamentos. A empresa quer um agente no WhatsApp que responda o status do carro e marque revisões.

Para o status, o fluxo é simples: o cliente informa a placa, o sistema consulta a ordem de serviço e responde. Esse passo pode ser uma chamada de API dentro de um workflow, sem o modelo escolher nada. O modelo só interpreta a mensagem e redige a resposta.

Para o agendamento, a conversa varia. O cliente pode pedir outro dia, trocar o serviço ou perguntar o que está incluso. Aqui o agente precisa escolher entre consultar horários, criar, remarcar ou cancelar. A empresa cria um servidor MCP com poucas ferramentas: consultar status por placa, listar horários livres e solicitar agendamento. Por baixo, cada uma chama a API existente. Cancelar e dar desconto ficam de fora do agente e passam para uma pessoa.

Depois, quando a oficina quiser usar o mesmo acesso em um assistente interno para a recepção, o servidor MCP já está pronto. A API continua atendendo o site e o aplicativo, sem mudança. É esse o encaixe dos dois: a API como base estável, o MCP como camada para agentes. Para o contexto de negócio desse tipo de oficina, veja IA para oficina mecânica.

Como levar isso para um piloto controlado

O método que aplicamos segue quatro movimentos: mapear, limitar, pilotar e transferir. Aplicado a esta decisão, fica assim:

• Mapear: descreva o processo atual, quem executa cada passo, quais sistemas são tocados e como se mede o resultado hoje. Sem essa linha de base, não dá para dizer se o agente ajudou.
• Limitar: liste as ações que o agente poderá executar, separe leitura de escrita, defina quais exigem aprovação humana e quais dados pessoais ficam fora do alcance.
• Pilotar: escolha um fluxo real, exponha só as ferramentas necessárias, com registro de cada chamada e uma métrica de sucesso combinada antes. Teste com ambiente simulado antes de tocar em dados reais, como explica o texto sobre testar agentes de IA com mocks e sandbox.
• Transferir: entregue a documentação das ferramentas, os registros e o plano de manutenção, e decida com a equipe se vale expandir, ajustar ou parar.

No piloto, a pergunta de MCP ou API costuma se resolver sozinha. Se o fluxo escolhido tem passos fixos, a API direta aparece como suficiente. Se o agente precisa escolher entre ações, o servidor MCP com poucas ferramentas se justifica, e o registro mostra se as escolhas do modelo foram corretas. Também ajuda definir como avaliar o comportamento, conforme as orientações da Anthropic sobre construir agentes eficazes, que recomendam começar pela solução mais simples e só adicionar complexidade quando ela se paga.

Perguntas frequentes

MCP substitui a API REST? Não. O servidor MCP normalmente chama a API REST por baixo e apenas a apresenta ao agente de forma padronizada. Sistemas que já têm API continuam precisando dela para o site, o aplicativo e outras integrações.

Preciso de MCP para colocar um agente de IA em produção? Não necessariamente. Se o fluxo é conhecido e o agente só interpreta texto e redige respostas, um workflow que chama a API diretamente costuma ser mais simples e mais fácil de testar. O MCP passa a valer quando há muitas ferramentas, vários agentes ou necessidade de reutilizar a integração.

O que é mais seguro, MCP ou API direta? Nenhum dos dois é seguro por si só. A segurança vem de credenciais com o menor privilégio possível, autorização verificada no sistema, registro das chamadas e aprovação humana para ações sensíveis. Com MCP, vale atenção extra ao risco de o modelo ser induzido a usar uma ferramenta indevida.

Posso começar com API e adicionar MCP depois? Sim, e muitas vezes é o melhor caminho. Uma API bem definida é a base para o servidor MCP, que pode ser acrescentado quando surgir a necessidade de reutilização por vários agentes. O contrário, criar o servidor sem contrato claro por baixo, tende a esconder problemas.

Fontes

• Model Context Protocol: introdução
• Anthropic: Writing effective tools for agents
• OWASP: guia de autorização
• Stripe: requisições idempotentes