Em um exemplo hipotético, uma loja recebe duas propostas para vender por assistentes. Uma oferece consulta ao catálogo por MCP; a outra cria uma sessão de checkout por UCP. As duas usam a palavra integração, mas entregam capacidades diferentes. Comparar apenas a lista de siglas pode levar a contratar consulta esperando receber pedidos pagos.
Desenhe a jornada pretendida antes de escolher a tecnologia: descobrir um item, comparar opções, calcular a compra, obter autorização, cobrar e acompanhar o pedido. Marque quem executa cada etapa e qual sistema confirma o resultado. Esse desenho expõe lacunas que uma apresentação comercial costuma esconder.
Neste guia
Qual função cada protocolo descreve?
| Protocolo | O que examinar na proposta |
|---|---|
| UCP | Capacidades de comércio negociadas, como catálogo e checkout. |
| ACP | Interação programática entre comprador, agente e vendedor na compra. |
| AP2 | Vínculo verificável entre autorização e transação. |
| MCP | Acesso a recursos e ferramentas, com permissões delimitadas. |
Essa comparação não significa equivalência entre todos os recursos. UCP e ACP podem atender etapas semelhantes por contratos diferentes. AP2 não substitui catálogo ou controle de estoque, e uma ferramenta MCP não passa a ser um checkout só porque aceita uma chamada.
Por que registrar a versão e as extensões?
Uma especificação muda ao longo do tempo, e uma implementação pode aceitar apenas parte dela. A documentação UCP de 25/08/2026 distingue capacidades e extensões negociadas. No checkout dessa versão, a conclusão manual em interface confiável é o padrão, salvo quando a extensão de mandatos AP2 é aceita no fluxo aplicável.
Exija versão, operações implementadas, extensões, ambiente de teste e limites de uso por escrito. A presença de um endereço público de descoberta não comprova uma compra concluída. Tampouco um exemplo de documentação prova disponibilidade comercial no país, no meio de pagamento ou no fornecedor contratado.
Quando faz sentido combinar protocolos?
Combine quando existir uma necessidade concreta entre sistemas que adotam contratos diferentes. Um adaptador pode traduzir uma solicitação do assistente para o serviço comercial da loja, desde que preserve produto, total, autorização e estado do pedido. A equipe precisa mostrar onde essa tradução ocorre e quem responde por ela.
Evite criar quatro integrações antes de provar uma jornada. Cada caminho amplia a superfície de falha e o trabalho de manutenção. Para a loja do exemplo, uma consulta de catálogo pode ser suficiente no primeiro teste; pagamento exige um projeto adicional, com financeiro e operação participando do aceite.
O que cobrar numa demonstração de arquitetura?
Peça que o fornecedor execute o fluxo e explique as recusas. Um produto pode ficar indisponível entre consulta e compra; o preço pode mudar; a autorização pode expirar. O sistema deve apresentar essas condições de forma verificável, sem deixar o modelo escolher sozinho se deve ignorá-las.
Registre também a recuperação: como uma requisição repetida evita duplicar o pedido, onde se consulta o estado real e como uma pessoa assume a operação. O roteiro de homologação de compras por agente transforma essas perguntas em cenários de teste.
Qual deve ser a primeira decisão da loja?
Escolha um único problema e compare alternativas pelo resultado observável. Se a tarefa é responder dúvidas sobre produtos, acesso de leitura pode bastar. Se é reservar mercadoria, existe efeito operacional. Se é pagar, autorização e confirmação financeira precisam ser tratadas separadamente. O guia de identidade e delegação aprofunda essa separação.
O curso MCP para quem decide ajuda a avaliar conectores e limites de acesso. Use-o para montar uma matriz com tarefa, protocolo, versão, responsável e evidência de funcionamento. Contrate a primeira jornada que a equipe consiga demonstrar e interromper com segurança.