MCP vs API para agentes de IA

A ideia errada

A frase MCP vs API sugere uma substituição, e o protocolo convida à leitura porque parece uma API: um ponto final 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 padroniza não é como aceder a 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 autocorrigir-se, e como a pessoa por trás do modelo é autorizada. Uma API REST não padroniza nada disso, porque nunca precisou: os seus chamadores eram programas cujos autores leram a documentação uma vez.

Cada 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, uma vez que 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 tem de transformar os endpoints em definições de função que o modelo possa ver, no formato que o fornecedor do modelo espera; os formatos de chamada de função de Claude e OpenAI são semelhantes, mas não idênticos. Alguém tem de 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 tem de 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 tem de 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á a perguntar.

Nada disso é difícil para um sistema e um agente, razão pela qual era o estado da arte antes do protocolo. Escala mal. Cada combinação de um produto de agente e um sistema empresarial é personalizada, as definições desviam-se da API, e não há forma de um utilizador de Claude ou ChatGPT conectar um sistema por si mesmo. A API continua excelente no que foi construída: chamadas de alto volume, programa a programa, operações em massa, webhooks e integrações onde a lógica é fixa e o chamador é código.

O que o MCP acrescenta

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 as aplicações são instaladas 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 sinal que diz 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á a perguntar. Consentimento: anotações permitem que um servidor diga que uma ferramenta é apenas leitura, destrutiva ou idempotente, e os clientes usam-nas 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 a sua resposta, à medida que 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
  }
}

Um pedido de chamada/ferramenta e resultado para uma ferramenta de pagamento Sois. A mesma operação sobre a API REST precisaria de uma definição de função escrita para o fornecedor do modelo, um loop para relatar 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 a nível de protocolo e alterou a forma como os servidores pedem entrada aos clientes, e os clientes são obrigados a voltar para os servidores na revisão anterior. As listas de ferramentas consomem contexto, por isso servidores grandes precisam de carregamento diferido ou pesquisa de ferramentas no lado do cliente. E um chamador orientado por modelo é mais lento e menos previsível do que um programa, que é precisamente a razão pela qual 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 fornecedor resolvem a comparação para quem está a construir o seu próprio agente, porque ambos agora aceitam um servidor MCP como uma ferramenta de primeira classe ao lado da chamada de função ordinária. Do lado do Claude, conectores personalizados nas aplicações web e desktop e no Cowork aceitam uma URL de servidor e completam o OAuth na aplicação; o Claude Code adiciona um servidor com um comando; e o conector MCP da API de Mensagens (beta, por trás do mcp-client-2025-11-20 cabeçalho) aceita um mcp_servidores 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 server_url, um requer aprovação definição e uma opcional ferramentas permitidas lista, devolve mcp_list_tools e mcp_call itens, e funciona com HTTP Streamable ou o transporte SSE mais antigo.

A chamada de função ordinária continua disponível em ambas as APIs, e é o caminho para um sistema apenas REST: você define as funções, chama a API, devolve 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 beneficia; com a chamada de função, cada construtor de agente mantém as suas próprias definições em relação à API.

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

Os sistemas que fazem isto corretamente expõem ambos e os roteiam através da mesma camada de permissões. O Sois é uma implementação do padrão. O espaço de trabalho tem uma camada de serviço que cada ecrã utiliza. O seu servidor MCP publica essa camada como ferramentas numa 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 pedidos em linguagem simples num 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, o 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 requer escolha. A API serve programas, o servidor MCP serve modelos, o gateway serve chamadores sem nenhum, e um modelo de permissões governa os três. Quando alguém pergunta qual construir, a resposta honesta é que a API é um dado adquirido 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 é revisto quando os produtos que descreve mudam. Próxima revisão agendada: 4 de dezembro de 2026.