MCP ou API para o agente? A pergunta certa não é essa
Um caso de arquitetura B2C/B2B com Salesforce, MuleSoft e um agente de compras de terceiros mostra que a decisão real está em cada HLR, não numa escolha binária
Analisando um cenário real de conectividade de agentes de IA a sistemas corporativos, fica claro que MCP e API não competem entre si. Cada requisito de negócio puxa para um lado diferente, e o trabalho do arquiteto é justificar cada escolha, não bater o martelo uma vez só.
Todo projeto de Agentforce (ou de qualquer plataforma agentic de terceiros) chega numa reunião em que alguém pergunta: "então a gente expõe tudo via MCP ou mantém API?". E a resposta correta quase nunca é uma ou outra. É as duas, dependendo do requisito.
Um cenário de referência ajuda a deixar isso concreto: uma marca de vestuário B2B legada (chamemos de Croft & Thread, só para ilustrar) quer abrir um canal de venda direta ao consumidor através de uma plataforma de personal shopper com IA agentic. A plataforma de terceiros vai precisar consultar catálogo, preço, estoque em tempo real, colocar pedidos e receber atualizações de fulfillment. Cinco frentes, cinco decisões de arquitetura diferentes.
Quebrando em HLRs antes de desenhar qualquer coisa
O primeiro erro clássico em projeto de integração agentic é já sair desenhando conector. Antes disso, vale destrinchar o requisito de negócio em High-Level Requirements paraphraseados, não copiados literalmente do texto do stakeholder. Isso força você a validar que entendeu a intenção, não só as palavras. No caso do Croft & Thread, isso vira:
- Recuperar dados ricos de produto para o agente
- Expor preço com segurança para o agente externo
- Fornecer consulta de estoque de armazém em tempo real
- Permitir que o agente coloque pedidos em nome do cliente
- Empurrar proativamente atualizações de fulfillment e status de pedido de volta para a plataforma do agente
Cada um desses HLRs puxa para um padrão de integração diferente, e é aí que a decisão MCP vs API fica interessante.
Catálogo: batch via API, sem drama
Se o catálogo de produto é relativamente estático e a plataforma do agente mantém seu próprio catálogo (comum quando ela trabalha com múltiplos fornecedores), não faz sentido nenhum expor isso via MCP em tempo real. Um job batch diário via API, roteado pelo MuleSoft para manter abstração e flexibilidade futura (trocar para FTP, por exemplo, sem reescrever tudo), resolve com muito menos complexidade do que qualquer coisa
Esse tipo de decisão está pipocando em praticamente todo projeto que envolve agente de IA de terceiros consumindo dados Salesforce. Errar a escolha entre MCP e API não quebra o sistema no dia 1, mas gera dívida de integração e retrabalho quando o volume ou a complexidade cresce. Entender que a decisão é por HLR, e não por projeto inteiro, muda a forma como você desenha a arquitetura desde a primeira reunião de descoberta.
Vale registrar que o Headless360 (ou a variação dele citada aqui como padrão de conectividade nativa Salesforce para agentes) ainda tem limitação real de suporte a contas de serviço via mecanismo de autenticação atual. Isso é fato documentado no momento da publicação e pode mudar em releases futuros, então trate como ponto de atenção, não como limitação permanente.
Ao desenhar conectividade de agente, comece sempre pelos HLRs, não pelo protocolo. Para cada requisito, pergunte: o cliente do outro lado é um agente que entende ferramentas dinâmicas (MCP) ou uma integração determinística sistema a sistema (API)? Se você já tem um servidor MCP pronto cobrindo a interação, não force API por hábito. Se é fluxo batch, estático ou side to side sem cliente agentic, API tradicional via MuleSoft continua sendo o caminho mais simples e barato de manter. E documente cada decisão como ADR, amarrando premissa a decisão, porque quando a premissa cair (por exemplo, descobrir que a plataforma do agente não tem OMS próprio), você precisa saber exatamente qual decisão revisar.
Cuidado com o modismo de "tudo agora é MCP". Nem todo agente precisa de MCP, e nem toda API precisa virar tool de MCP. Isso gera camada de abstração desnecessária e superfície de ataque maior sem ganho real. Outro ponto de atenção: contas de serviço e autenticação machine-to-machine ainda têm gargalos em alguns padrões nativos de agente, então valide isso cedo no projeto antes de prometer prazo ao cliente.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.