Referencias técnicas consultadas el 18 de octubre de 2026. Este artículo considera la especificación AP2 v0.2 y distingue los estándares abiertos de las funciones realmente disponibles en cada canal.
MCP, ACP, UCP y AP2 no son cuatro nombres para la misma tecnología. MCP estandariza cómo acceden las aplicaciones de IA a herramientas y contexto. ACP y UCP definen contratos para interacciones comerciales, con solapamientos en capacidades como el checkout. AP2 añade mecanismos para acreditar y verificar la autorización de compras y pagos ejecutados por agentes. Las diferencias aparecen en las respectivas documentaciones de MCP (se abre en una pestaña nueva ↗), ACP (se abre en una pestaña nueva ↗), UCP (se abre en una pestaña nueva ↗) y AP2 (se abre en una pestaña nueva ↗).
Por tanto, la pregunta útil no es cuál de estas siglas sustituirá a todas las demás. Es qué responsabilidad necesita resolver tu integración: dar acceso a una capacidad, representar una compra, verificar una delegación o ejecutar el pago.
Imagina una tienda que ya dispone de catálogo, existencias, cálculo de envío e integración financiera. Conectar un agente a la API de esa tienda es un problema. Conseguir que el agente entienda el estado del checkout es otro. Demostrar que el comprador autorizó ese importe es un tercero. Saber si el pago se completó realmente exige otra respuesta más.
Un proyecto puede combinar protocolos, pero no existe una secuencia obligatoria llamada MCP → ACP → UCP → AP2. Tratar estas siglas como cuatro etapas universales oculta precisamente las fronteras que debemos diseñar.
MCP: ¿cómo accede el agente a las herramientas y al contexto?
MCP significa Model Context Protocol. Organiza la comunicación entre una aplicación de IA y servidores que ofrecen herramientas, recursos y prompts. Su arquitectura distingue la aplicación anfitriona, los clientes MCP y los servidores; la comunicación utiliza mensajes estructurados con transportes definidos por el protocolo. Esa es la función descrita en la arquitectura de MCP (se abre en una pestaña nueva ↗).
En un ejemplo de comercio, un servidor podría exponer herramientas para consultar un producto, calcular una opción de entrega o buscar un pedido. El cliente descubre esas herramientas y las invoca según sus contratos de entrada y salida. Los nombres de esas operaciones, en este ejemplo, son decisiones de la aplicación, no herramientas comerciales universales impuestas por MCP.
Esta distinción importa: MCP puede transportar la llamada a una herramienta que crea una compra, pero no define, por sí solo, el significado comercial de todas las compras. Una herramienta llamada «completar pedido» necesita reglas propias sobre precio, disponibilidad, pago y repetición.
También sería incorrecto decir que MCP no trata la seguridad. La especificación establece medidas como validación de entradas, controles de acceso, limitación de llamadas y confirmación de operaciones sensibles. Lo que no hace es convertir el permiso técnico para llamar a una herramienta en una autorización ilimitada para gastar dinero. Consulta los requisitos de seguridad de las herramientas MCP (se abre en una pestaña nueva ↗).
Para evaluar una integración, pregunta primero: ¿el servidor entrega información, ejecuta acciones o ambas cosas? Después: ¿qué acciones pueden producir efectos comerciales o financieros y quién las autoriza?
Un ejemplo de AZPay: consultar documentación no es ejecutar pagos
La documentación de AZPay describe un servidor MCP para que asistentes de IA y herramientas de desarrollo consulten referencias de la plataforma. El acceso documentado es de solo lectura: no sustituye las claves de API ni concede acceso a la API de pagos. Esta separación aparece explícitamente en la referencia del servidor MCP de AZPay.
Es un ejemplo concreto de por qué el nombre del protocolo no revela por sí solo el poder de una integración.
Un asistente puede consultar la documentación para explicar el significado de un estado o ayudar a un desarrollador a entender un campo. Eso es distinto de consultar transacciones privadas de un comercio. Y ambas situaciones son diferentes de enviar un cobro.
Por eso, «tenemos MCP» es una información incompleta para hablar de comercio mediante agentes. Es necesario explicar qué expone el servidor, a quién, con qué permisos y con qué efectos. En el caso descrito por la documentación de AZPay, se trata de acceso al conocimiento técnico, no de delegación financiera.
ACP: ¿cuál es el contrato entre el agente y el checkout?
En este artículo, ACP significa Agentic Commerce Protocol. El proyecto está mantenido por OpenAI y Stripe y define un estándar abierto para las interacciones entre compradores, agentes y empresas. Su arquitectura separa las responsabilidades del comprador, el agente, el vendedor y el proveedor de pagos. El vendedor sigue siendo responsable de su operación comercial, incluidos los precios, las existencias y la preparación y entrega del pedido. Consulta la visión general de ACP (se abre en una pestaña nueva ↗) y su arquitectura (se abre en una pestaña nueva ↗).
El componente Agentic Checkout organiza operaciones como crear, consultar, actualizar, completar y cancelar una sesión. La sesión representa el estado comercial de la compra: qué se ha seleccionado, qué información falta todavía y si se dan las condiciones para avanzar. El ciclo de vida documentado (se abre en una pestaña nueva ↗) diferencia estados de preparación, procesamiento, finalización y cancelación.
Considera un agente que ha encontrado un producto a un precio determinado. Al crear el checkout, necesita recibir el estado calculado por el vendedor, no limitarse a imponer el precio que llevaba en la conversación. Si la dirección modifica los gastos de envío, la sesión debe reflejar ese cambio antes de finalizar.
Este contrato reduce la ambigüedad entre «el agente pretende comprar» y «la tienda está preparada para aceptar esta compra». La implementación sigue teniendo que asegurar que el estado comunicado corresponda a la operación real.
ACP tampoco termina necesariamente con la respuesta de la primera solicitud. Su referencia incluye webhooks de pedidos (se abre en una pestaña nueva ↗), que permiten comunicar cambios posteriores. Por tanto, describirlo solo como un botón de pago deja fuera partes importantes del contrato.
¿Cómo limita ACP el uso de la credencial de pago?
El componente Delegate Payment trata la entrega de una credencial de pago con un alcance controlado. La referencia consultada incluye restricciones asociadas al importe máximo, la moneda, el vendedor, la sesión de checkout y la caducidad, además de un solo uso dentro del alcance documentado. El agente participa en el recorrido sin necesidad de recibir una credencial reutilizable para cualquier compra. Los campos se describen en la referencia de pagos delegados de ACP (se abre en una pestaña nueva ↗).
Piensa en la diferencia entre entregar un medio de pago sin límites y entregar una credencial válida para una situación delimitada. La segunda opción permite a los participantes comprobar si ese intento corresponde al uso autorizado.
Pero una credencial restringida no debe tratarse como una promesa de portabilidad universal. El equipo debe confirmar quién la emite, quién puede procesarla, qué restricciones se verifican y qué ocurre cuando caduca.
Tampoco conviene equiparar este mecanismo a los mandatos de AP2. Ambos ayudan a controlar pagos mediante agentes, pero la integración debe respetar los objetos y las verificaciones de cada contrato. Sin un mapeo admitido expresamente, no debe suponerse que un token de un flujo equivale a la evidencia exigida por otro.
UCP: ¿cómo se descubren y combinan las capacidades de comercio?
UCP significa Universal Commerce Protocol. Organiza la interacción entre plataformas que consumen capacidades y empresas que las ofrecen. La documentación contempla capacidades de catálogo, carrito, checkout, pedidos y vinculación de identidad, además de extensiones que añaden comportamientos específicos. Esta organización aparece en los conceptos centrales de UCP (se abre en una pestaña nueva ↗).
Una pieza importante es el perfil publicado en la ruta /.well-known/ucp. El perfil permite anunciar servicios, capacidades, versiones e información necesaria para la integración. La negociación identifica el conjunto compatible entre los participantes; no significa que toda plataforma entienda automáticamente todo lo que anuncia una tienda. La especificación general de UCP (se abre en una pestaña nueva ↗) detalla este modelo.
En términos prácticos, publicar «admito checkout» es solo el principio. Todavía hay que saber qué versión, qué extensiones, cómo se llamará a la operación y qué condiciones de pago están disponibles.
Los payment handlers también forman parte de este descubrimiento. Describen mecanismos para recopilar o preparar instrumentos de pago y la información necesaria para procesarlos. Su mera existencia en el perfil no los convierte en una nueva red de liquidación ni demuestra que cualquier credencial funcione con cualquier procesador. Consulta la guía de payment handlers (se abre en una pestaña nueva ↗).
Su utilidad arquitectónica consiste en hacer explícitas preguntas que, de otro modo, dependerían de acuerdos implícitos. ¿Ofrece mi tienda esta capacidad? ¿Entiende el canal la extensión necesaria? ¿Existe una forma compatible de presentar y procesar el pago?
¿Pueden MCP y UCP formar parte de la misma integración?
Sí. UCP documenta un binding MCP, es decir, una forma de expresar sus operaciones mediante MCP. En la capacidad de checkout, la especificación presenta herramientas como create_checkout, get_checkout, update_checkout, complete_checkout y cancel_checkout. La llamada MCP proporciona el mecanismo de invocación; el contrato UCP define los datos y el significado comercial de la operación. Consulta el binding MCP del checkout de UCP (se abre en una pestaña nueva ↗).
Esta composición ayuda a separar dos preguntas. «¿Cómo llama el cliente a la herramienta?» corresponde a la integración MCP. «¿Qué significa completar este checkout, con qué datos y en qué estado?» corresponde al contrato comercial.
Del mismo modo, no toda integración UCP necesita utilizar MCP. La especificación también documenta otras formas de integración. La elección depende de las capacidades disponibles en los participantes, no de la obligación de incluir todas las tecnologías en el mismo diseño.
Una buena prueba de comprensión consiste en retirar el nombre del transporte del diagrama. Las reglas sobre precio, pedido y finalización deberían seguir estando claras. Después, al volver a colocar MCP u otra opción admitida, debería quedar claro cómo se accederá a esas operaciones.
¿Compiten ACP y UCP o se complementan?
Existe un solapamiento real. Ambos pueden participar en la organización de un recorrido comercial y de su checkout. No son simplemente capas independientes que toda compra deba atravesar en secuencia.
Tampoco es correcto afirmar que solo UCP dispone de negociación de capacidades. ACP documenta la negociación entre participantes, extensiones y payment handlers; su historial registra la introducción de estos mecanismos en la versión del 30 de enero de 2026. La comparación debe considerar el modelo de negociación de ACP (se abre en una pestaña nueva ↗) y su changelog (se abre en una pestaña nueva ↗), no solo las descripciones de lanzamiento.
La diferencia útil para un equipo está en los contratos concretos: objetos, estados, descubrimiento, extensiones, formas de integración y requisitos del canal que consumirá esas capacidades. Que dos protocolos traten el checkout no convierte sus formatos en intercambiables.
Una tienda puede decidir atender canales que utilizan contratos distintos. Para ese escenario, nuestra propuesta es conservar un dominio comercial común y construir adaptaciones en las fronteras, en lugar de mantener dos inventarios, dos reglas de precio o dos interpretaciones del mismo pedido.
También hay que separar el estándar abierto del acceso comercial a una plataforma. Implementar una especificación no garantiza distribución, homologación ni disponibilidad de todos los flujos en un producto concreto. La documentación de comercio de OpenAI consultada, por ejemplo, enfatiza la ingestión estructurada de catálogo para el descubrimiento de productos. Los requisitos actuales del canal deben comprobarse por separado de la especificación general. Consulta la documentación de comercio de OpenAI (se abre en una pestaña nueva ↗).
AP2: ¿cómo se demuestra que el agente estaba autorizado?
AP2, Agent Payments Protocol, trata la autorización verificable de transacciones realizadas por agentes. No sustituye las API de catálogo ni el ciclo de actualizaciones del checkout: actúa como un mecanismo de seguridad dentro de un recorrido comercial. En la especificación v0.2, el núcleo está formado por dos tipos de mandato: Checkout Mandate y Payment Mandate. Consulta la especificación AP2 (se abre en una pestaña nueva ↗).
Un mandato es un objeto que representa una autorización y sus condiciones de forma verificable. El objetivo no es confiar únicamente en la frase «el usuario lo permitió» enviada por el agente. Es permitir que los participantes comprueben el origen de la autorización, su vínculo con la acción y los límites que deben respetarse.
El marco de autorización de AP2 (se abre en una pestaña nueva ↗) distingue la obtención de la autorización del usuario de la posterior verificación de la acción. Esta separación es fundamental: el componente que pretende comprar no debería poder ampliar por sí solo el permiso recibido.
AP2 también distingue las compras con participación directa del usuario de la ejecución autónoma bajo condiciones previamente aprobadas. Sus flujos documentados (se abre en una pestaña nueva ↗) muestran ambas formas de uso. La autonomía, en este contexto, no significa ausencia de autorización; significa ejecutar sin pedir una nueva aprobación en cada paso, siempre que la acción se mantenga dentro de lo autorizado.
Checkout Mandate y Payment Mandate: ¿qué acredita cada uno?
El Checkout Mandate demuestra al vendedor la autorización para completar una compra determinada. En su forma cerrada, está vinculado al checkout firmado por el vendedor mediante un resumen criptográfico. El vínculo ayuda a verificar si la compra presentada para finalizar corresponde al estado autorizado. La especificación del Checkout Mandate (se abre en una pestaña nueva ↗) detalla esa relación.
El Payment Mandate trata la autorización para pagar ese checkout. Representa condiciones financieras, como importe, moneda, destinatario e instrumento de pago, y también establece el vínculo con la compra. Sus campos y restricciones figuran en la especificación del Payment Mandate (se abre en una pestaña nueva ↗).
La separación es útil porque autorizar el contenido de una compra y autorizar su pago son responsabilidades relacionadas, pero diferentes. Una tienda necesita saber qué se aprobó para comprar; los participantes del pago deben verificar si la credencial puede utilizarse para pagar esa operación.
En la v0.2, los mandatos pueden ser abiertos o cerrados. Un mandato cerrado corresponde a una compra o un pago concretos. Un mandato abierto establece condiciones para una ejecución futura. En modo autónomo, la operación concreta debe ser demostrablemente compatible con los límites previamente aprobados, según los modelos de checkout (se abre en una pestaña nueva ↗) y pago (se abre en una pestaña nueva ↗).
«Hasta R$ 500» no equivale a «cualquier compra de R$ 500». El vendedor, los artículos, la cantidad, la vigencia y el instrumento pueden ser tan relevantes como el límite monetario. Cada condición debe estar representada mediante mecanismos admitidos por la implementación; no basta con que permanezca en lenguaje natural dentro de la conversación.
La identificación de la versión importa. Este texto utiliza la nomenclatura de AP2 v0.2. Al aprovechar ejemplos de otra revisión, el equipo debe comprobar los esquemas y las reglas de validación correspondientes, en lugar de combinar estructuras incompatibles bajo el mismo nombre.
El acceso a la API, la autorización de compra y la aprobación financiera son cosas distintas
Una forma práctica de revisar la arquitectura es separar tres preguntas que suelen recibir la misma palabra: autorización.
La primera es técnica: ¿puede este cliente acceder a este recurso o llamar a esta operación? El modelo de autorización de MCP trata el acceso a recursos, los ámbitos y los permisos. Una credencial de acceso válida no debería interpretarse como una autorización económica ilimitada. Consulta la especificación de autorización de MCP (se abre en una pestaña nueva ↗).
La segunda es comercial: ¿autorizó el usuario esta compra, en estas condiciones, mediante este agente? Es en esa frontera donde cobra relevancia la verificación de los mandatos AP2.
La tercera pertenece a la ejecución financiera: ¿aceptaron y procesaron la operación los participantes del pago? AP2 distingue las responsabilidades del vendedor, el proveedor de credenciales y el procesador. Verificar el permiso es una parte del trabajo; procesar el pago es otra. La división aparece en las consideraciones de implementación de AP2 (se abre en una pestaña nueva ↗).
El diseño de la aplicación debe mantener separadas estas respuestas. El acceso permitido no significa compra autorizada. Una compra autorizada no significa pago aprobado. Y el registro comercial debe reflejar la evidencia realmente recibida, no una deducción optimista sobre el paso anterior.
Una compra de hasta R$ 500: ¿cómo se encuentran los protocolos?
Considera un ejemplo hipotético: una persona autoriza a su agente a comprar una unidad de uno de dos modelos de auriculares previamente seleccionados, en tiendas determinadas, por hasta R$ 500 con envío incluido, en un plazo de 48 horas.
Estos importes y condiciones son ilustrativos. Cada restricción tendría que representarse mediante un mecanismo admitido o una verificación explícita de la aplicación. No estamos describiendo un único payload universal aceptado por los cuatro protocolos.
El agente encuentra una oferta de R$ 460, con R$ 25 de envío. El total es R$ 485. La primera tarea es obtener el estado correcto de la tienda: producto, cantidad, disponibilidad y condiciones actuales. La segunda es verificar si esa compra cabe en la autorización recibida.
En una implementación basada en UCP, el descubrimiento identifica las capacidades y los mecanismos de pago compatibles. MCP puede ser la forma de invocar las operaciones cuando esté disponible ese binding. La extensión AP2 añade los mandatos y sus verificaciones. Esta composición está documentada en UCP y AP2 (se abre en una pestaña nueva ↗).
Hay una condición importante: la especificación de checkout de UCP exige que el usuario complete manualmente la compra en una interfaz de confianza, salvo que exista soporte para la extensión AP2 Mandates. Por tanto, anunciar únicamente checkout UCP no debe entenderse como autorización para una compra completamente autónoma. Consulta la capacidad de checkout (se abre en una pestaña nueva ↗).
Supón ahora que, antes de finalizar, el total cambia a R$ 515. En el ejemplo, el agente no puede tratar la diferencia como un detalle irrelevante. La compra ya no cabe en el presupuesto autorizado. La implementación debe interrumpir la finalización, actualizar el estado y obtener una nueva autorización si el usuario desea continuar.
Si el cambio mantiene el total por debajo de R$ 500, todavía habrá que comprobar las demás condiciones y vincular la autorización al checkout correcto. Estar dentro del presupuesto no convierte un estado antiguo en evidencia válida para cualquier compra posterior.
Un canal que utilice ACP tendrá su propio contrato de checkout y pago delegado. No hay motivo para introducir UCP solo para completar una colección de siglas. La implementación debe seguir el flujo que realmente admiten los participantes.
La verificación no puede depender de la buena voluntad del modelo
El modelo de amenazas de AP2 considera que un agente puede ser manipulado o comportarse de forma maliciosa. Por eso, la protección no puede depender exclusivamente de instrucciones como «nunca superes el presupuesto». Las consideraciones de seguridad y privacidad (se abre en una pestaña nueva ↗) tratan precisamente la verificación independiente y la limitación del poder del agente.
AP2 llama Trusted Surface a la interfaz de confianza que presenta al usuario el contenido de la autorización, obtiene su consentimiento y participa en la creación de los mandatos firmados. Puede ser una parte determinista de la aplicación, una cartera u otra interfaz de confianza. No es simplemente el mensaje del agente afirmando que ha recibido permiso. Las responsabilidades aparecen en las consideraciones de implementación (se abre en una pestaña nueva ↗).
En la arquitectura propuesta aquí, el modelo interpreta la intención y busca opciones. Los componentes verificadores comprueban la autorización, el estado y las condiciones antes de permitir una acción con efecto financiero. La decisión de aceptar no debe sustituirse por otra respuesta en lenguaje natural que diga «parece que todo está bien».
Esto también cambia el plan de pruebas. No basta con probar una compra válida. Conviene probar un vendedor diferente, un checkout modificado, una autorización caducada, la repetición de una acción y el intento de utilizar una credencial fuera de su ámbito.
Para cada escenario, registra qué componente debe rechazar la operación y qué evidencia debe conservarse. Este ejercicio convierte la seguridad en un comportamiento verificable, en vez de depender de la interpretación de un diagrama.
Una integración multiprotocolo necesita una única fuente de verdad comercial
Para una tienda que pretende atender más de un canal, recomendamos separar el dominio comercial de los adaptadores de protocolo.
El dominio representa producto, precio, disponibilidad, pedido, intención de pago y reglas del negocio. Los adaptadores traducen ese dominio a los contratos que entiende cada canal. Es una propuesta de arquitectura, no una exigencia universal de MCP, ACP, UCP o AP2.
El cuidado está en la traducción. Si un contrato distingue «listo para finalizar» de «finalización en curso», el adaptador no puede reducir ambos a «pagado». En UCP, por ejemplo, ready_for_complete, complete_in_progress y completed representan situaciones diferentes. No existe necesariamente un pedido cuando la finalización solo se ha aceptado para procesarse, según el ciclo del checkout (se abre en una pestaña nueva ↗).
Una matriz de compatibilidad por operación permite verificar esta decisión. Debe registrar el canal, la versión del protocolo, las extensiones exigidas, las credenciales aceptadas y la necesidad de intervención humana. «Compatible» debe significar una combinación probada, no solo un endpoint que responde.
Este diseño conecta con la orquestación de pagos: conservar una intención de negocio y controlar cómo se ejecutará, sin dispersar los detalles de cada integración por toda la aplicación.
Un mandato válido no significa un pago completado
Una autorización verificable demuestra permiso dentro de un contexto determinado. No acredita que el dinero se haya movido. La especificación AP2 distingue mandatos y recibos; estos últimos registran resultados y pueden formar parte de evidencias posteriores. El formato de una autorización no sustituye la respuesta de la ejecución financiera. Los flujos AP2 (se abre en una pestaña nueva ↗) muestran la obtención de autorización y los resultados devueltos por los participantes.
Para diseñar la atención al cliente, recomendamos separar «autorizado por el usuario», «enviado para procesamiento», «resultado confirmado» y «resultado todavía desconocido», utilizando los estados reales de cada integración. La interfaz no debe presentar una finalización que el backend todavía no pueda demostrar.
La misma precaución se aplica a las disputas. Los mandatos y recibos pueden aportar pruebas sobre la transacción, pero AP2 no define por sí solo los procedimientos de resolución, conservación y recuperación de esas evidencias. Tampoco garantiza un resultado favorable en una reclamación. La sección de pruebas de disputa (se abre en una pestaña nueva ↗) delimita ese alcance.
La lección arquitectónica es sencilla: el permiso, la ejecución y la comprobación posterior merecen registros relacionados, pero distintos. Esta separación también ayuda a comprender los estados de una transacción de pago.
¿Qué ocurre cuando se pierde la respuesta?
Supón que el agente solicitó completar una compra y no recibió respuesta. No es seguro asumir que no ocurrió nada. Los errores de comunicación pueden dejar indeterminado el resultado de una operación financiera; la documentación de errores de bajo nivel de Stripe (se abre en una pestaña nueva ↗) presenta este tipo de situación.
El protocolo de comercio y los mecanismos de autorización no eliminan la necesidad de controlar la repetición. Una nueva llamada debe respetar las garantías de idempotencia y el estado de la operación anterior. Estas garantías tienen un alcance: la referencia de idempotencia de Stripe (se abre en una pestaña nueva ↗), por ejemplo, describe reglas del propio servicio, no una protección compartida automáticamente por todos los procesadores.
Para la arquitectura de este artículo, recomendamos que el agente pueda consultar la compra existente en lugar de crear otra a ciegas. El backend debe correlacionar la intención, el intento y las notificaciones posteriores. El objetivo es resolver la incertidumbre sin producir una segunda compra no deseada.
Este es un análisis distinto de la comparación de protocolos. La guía de idempotencia en API de pago explica los controles que siguen siendo necesarios después de elegir el contrato de integración.
Pix, los pagos a plazos y la operación brasileña no aparecen por arte de magia
Al diseñar una integración para Brasil, no basta con rellenar una línea llamada «pagos compatibles». Hay que especificar qué recorridos pueden ejecutar de principio a fin el canal y los proveedores.
Para un recorrido con Pix, recomendamos definir cómo se creará el cobro, cómo podrá pagar el usuario, de dónde llegará la confirmación y cómo tratará la aplicación la caducidad o la devolución. Para un recorrido de pago a plazos, la propuesta debe representar de forma comprensible el total y las condiciones que autorizará realmente el comprador.
Estas son cuestiones de implementación. La posibilidad de extender un protocolo no equivale a confirmar que un canal, una cartera o un procesador determinados ya admiten esa combinación. El diseño extensible de los payment handlers de UCP (se abre en una pestaña nueva ↗) debe traducirse en participantes y credenciales compatibles, no solo en un anuncio de capacidad.
El mismo razonamiento se aplica a la entrega, los descuentos y las reglas comerciales locales. Recomendamos conservar la lógica de la operación existente y mapear expresamente lo que puede representar cada canal. Cuando no se admita una fase necesaria, la solución debe prever intervención humana o un recorrido alternativo, no inventar una equivalencia silenciosa.
¿Por dónde empezar la implementación?
Empieza por el caso de uso y el canal. «Quiero que un asistente consulte documentación» exige un conjunto de permisos muy distinto de «quiero que un agente compre sin la presencia del usuario». A partir de esa decisión, identifica los contratos realmente aceptados por los participantes.
Después, registra versiones y capacidades. Incluso MCP evoluciona en aspectos estructurales: la arquitectura consultada en la revisión del 28 de julio de 2026 describe una comunicación sin sesión de protocolo obligatoria, con versión y capacidades por solicitud. Copiar un tutorial de otra revisión sin comprobar la compatibilidad puede introducir premisas incorrectas. Consulta la arquitectura vigente de MCP (se abre en una pestaña nueva ↗).
A continuación, diseña la frontera de autoridad. ¿Quién proporciona el estado comercial? ¿Quién obtiene la aprobación del usuario? ¿Quién valida los límites? ¿Quién emite la credencial? ¿Quién procesa y confirma el pago? ¿En qué situación debe detenerse el agente?
Por último, prueba el contrato completo: capacidad no admitida, total modificado, credencial incompatible, autorización caducada, finalización pendiente y respuesta perdida. Amplía la autonomía solo cuando estos caminos tengan un comportamiento definido y pruebas verificables.
La decisión no necesita anticipar qué protocolo tendrá mayor adopción. Necesita elegir una combinación que funcione para un recorrido concreto y conservar margen para nuevas integraciones sin reconstruir todo el negocio.
La compatibilidad es el principio. El control operativo es el objetivo
La comparación entre MCP, ACP, UCP y AP2 resulta más útil cuando deja de ser una disputa de siglas y pasa a ser un diseño de responsabilidades.
El acceso a herramientas, el contrato comercial, la delegación y la ejecución financiera deben estar conectados, pero no confundirse. La arquitectura debe poder explicar qué podía hacer el agente, qué compra se presentó, qué acción se ejecutó y cómo se confirmó su resultado.
La perspectiva que orienta este artículo es la de construcción: los nuevos canales deben ampliar la capacidad de la operación, no crear versiones paralelas y difíciles de conciliar del mismo negocio. En AZPay, el ejemplo documental de MCP ya demuestra por qué las capacidades deben describirse con precisión, sin confundir información con ejecución.
Para profundizar en la relación entre estos contratos y la operación de pagos, continúa con el artículo Pagos mediante agentes de IA: qué cambia cuando el checkout deja de ser una pantalla.
La pregunta decisiva no es cuántos protocolos aparecen en el diagrama. Es si cada compra puede autorizarse, ejecutarse y explicarse sin perder el control de la operación.