MCP vs API para agentes de IA

A concepção errônea

A frase MCP vs API sugere uma substituição, e o protocolo convida à leitura porque parece uma API: um endpoint HTTPS, JSON, uma lista de operações chamáveis. Por baixo, é JSON-RPC 2.0 sobre HTTP Streamable, o que significa que é uma API HTTP com uma forma de mensagem fixa. O que ela padroniza não é como acessar um sistema, mas como uma aplicação de IA pergunta a um sistema o que pode fazer, como chama essas coisas com um modelo escolhendo os argumentos, como os erros são devolvidos para que o modelo possa se autocorrigir e como a pessoa por trás do modelo é autorizada. Uma API REST não padroniza nada disso, porque nunca precisou: seus chamadores eram programas cujos autores leram a documentação uma vez.

Todo servidor MCP sério para um sistema empresarial é uma camada sobre a camada de serviço ou API existente desse sistema. A questão, portanto, não é qual construir, já que você precisa da API de qualquer forma, mas qual entregar a um agente.

O que uma API oferece a um agente e o que não oferece

Dê a um modelo uma API REST e ele pode usá-la, com ajuda. A ajuda é o problema. Alguém precisa transformar os endpoints em definições de função que o modelo possa ver, no formato que o provedor do modelo espera; os formatos de chamada de função do Claude e do OpenAI são semelhantes, mas não idênticos. Alguém precisa escrever o loop que pega a função escolhida pelo modelo, chama o endpoint com as credenciais corretas e alimenta a resposta de volta. Alguém precisa decidir como os erros chegam ao modelo, porque um 422 com um corpo de validação não é algo que um modelo lê bem, a menos que seja convertido. E alguém precisa resolver a autorização, porque uma chave de API no ambiente do agente faz com que cada ação pareça a mesma conta de serviço, não a pessoa que está perguntando.

Nada disso é difícil para um sistema e um agente, razão pela qual era o estado da arte antes do protocolo. Ele escala mal. Cada combinação de um produto de agente e um sistema empresarial é sob medida, as definições se afastam da API, e não há como um usuário do Claude ou ChatGPT conectar um sistema por conta própria. A API continua excelente no que foi construída: chamadas de alto volume, de programa para programa, operações em massa, webhooks e integrações onde a lógica é fixa e o chamador é código.

O que o MCP adiciona

O protocolo responde a cada uma dessas lacunas com uma regra que cada cliente implementa uma vez. Descoberta: tools/list retorna as ferramentas com nomes, descrições e Esquemas JSON em tempo de execução, para que o produto do agente não precise de conhecimento prévio e a lista possa mudar à medida que os aplicativos são instalados ou os papéis mudam. Invocação: tools/call carrega um nome e argumentos; o resultado carrega conteúdo que o modelo lê, conteúdo estruturado opcional e um isError sinalizador que informa ao modelo para corrigir e tentar novamente em vez de desistir. Autorização: OAuth 2.1 com o token vinculado ao servidor e à pessoa, para que a lista de ferramentas e cada chamada possam ser limitadas a quem está perguntando. Consentimento: anotações permitem que um servidor diga que uma ferramenta é somente leitura, destrutiva ou idempotente, e os clientes as usam para decidir quando confirmar; um servidor também pode retornar um resultado que requer entrada para fazer uma pergunta à pessoa durante a chamada. Aqui está uma chamada e sua resposta, conforme um cliente as envia e recebe.

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "recordPayment",
    "arguments": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "amount": 4850,
      "payment_date": "2026-09-18",
      "payment_reference": "BACS 41877"
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 12,
  "result": {
    "content": [
      { "type": "text", "text": "Payment recorded against INV-1057. Amount paid 4850.00 of 4850.00; status is now paid." }
    ],
    "structuredContent": {
      "invoice_id": "9f1c2a6e-4b8d-4c1a-9e2f-2d7a1b6c5e10",
      "number": "INV-1057",
      "amount_paid": 4850,
      "status": "paid"
    },
    "isError": false
  }
}

Uma solicitação de chamada/ferramentas e resultado para uma ferramenta de pagamento Sois. A mesma operação pela API REST precisaria de uma definição de função escrita para o provedor do modelo, um loop para retransmitir a chamada e uma decisão sobre como apresentar a resposta; aqui o cliente já sabe como fazer as três.

Há um custo. O protocolo é mais jovem que o REST e ainda está em movimento: a revisão de 2026-07-28 removeu sessões em nível de protocolo e mudou a forma como os servidores pedem entrada aos clientes, e os clientes são obrigados a voltar para servidores na revisão anterior. Listas de ferramentas consomem contexto, então servidores grandes precisam de carregamento diferido ou busca de ferramentas no lado do cliente. E um chamador orientado por modelo é mais lento e menos previsível que um programa, que é precisamente o motivo pelo qual você não o usaria para uma sincronização noturna.

Quando cada um é adequado

Como os principais produtos de agentes consomem cada um hoje

As APIs do provedor resolvem a comparação para quem está construindo seu próprio agente, porque ambos agora aceitam um servidor MCP como uma ferramenta de primeira classe ao lado da chamada de função comum. Do lado do Claude, conectores personalizados nos aplicativos web e desktop e no Cowork aceitam uma URL de servidor e completam o OAuth no aplicativo; o Claude Code adiciona um servidor com um comando; e o conector MCP da API de Mensagens (beta, atrás do mcp-client-2025-11-20 cabeçalho) aceita um mcp_servers entrada e um mcp_toolset, supports tool calls only, and expects you to supply the access token. On the OpenAI side, ChatGPT's developer mode connects a remote server with OAuth or no authentication and asks for confirmation on write actions by default; the Responses API takes a tool of type mcp com um url_do_servidor, um exige aprovação configuração e uma opção ferramentas permitidas lista, retorna mcp_list_tools e mcp_call itens e funciona com HTTP Streamable ou o transporte SSE mais antigo.

A chamada de função comum continua disponível em ambas as APIs e é o caminho para um sistema apenas REST: você define as funções, chama a API e retorna os resultados. A diferença está inteiramente em quem mantém a ponte. Com o MCP, o proprietário do sistema mantém um servidor e cada cliente se beneficia; com a chamada de função, cada construtor de agente mantém suas próprias definições em relação à API.

O padrão que funciona: API por baixo, MCP por cima

Os sistemas que acertam isso expõem ambos e os roteiam através da mesma camada de permissão. Sois é uma implementação do padrão. O espaço de trabalho tem uma camada de serviço que cada tela utiliza. Seu servidor MCP publica essa camada como ferramentas em uma URL, filtrada pelo papel do chamador e verificada novamente em cada chamada, com OAuth para conectores e um token de portador para scripts. O mesmo espaço de trabalho aceita solicitações em linguagem simples em um endpoint separado para chamadores sem agente, onde o próprio agente do espaço de trabalho faz o raciocínio e responde por webhook ou polling. E para a direção de saída, seu próprio agente pode chamar servidores MCP externos através de um gateway, sob a mesma governança de permitir, perguntar e negar.

Nada nesse design exige escolha. A API serve programas, o servidor MCP serve modelos, o gateway serve chamadores sem nenhum, e um modelo de permissão governa os três. Quando alguém pergunta qual construir, a resposta honesta é que a API é uma certeza e o servidor MCP é a coisa que torna o sistema utilizável pelos agentes que as pessoas já têm.

Perguntas que as pessoas fazem

Este artigo é revisado quando os produtos que descreve mudam. Próxima revisão agendada: 4 de dezembro de 2026.