Conectar un agente de IA a BigCommerce con MCP: lo que la asociación con Stripe no resuelve

El problema: tres rutas, ninguna de las cuales resuelve la cotización B2B

BigCommerce tomó un camino distinto de Shopify y HubSpot. Shopify construyó servidores Storefront MCP y Customer Accounts MCP de primera parte y co-desarrolló el Universal Commerce Protocol con Google. HubSpot publicó un Remote MCP Server de primera parte (GA abril 13, 2026) con 12 herramientas que cubren objetos CRM estándar. BigCommerce no hizo ninguno. En su lugar, el 18 de diciembre de 2025, BigCommerce se asoció con Stripe en el Agentic Commerce Suite de Stripe, construido sobre el Agentic Commerce Protocol (ACP) — un estándar abierto co-creado por Stripe, OpenAI y Meta, con licencia Apache 2.0.

El resultado son tres rutas distintas para conectar un agente de IA a una tienda BigCommerce, cada una con un perfil de cobertura diferente:

Las tres rutas de integración de agentes para BigCommerce conectan diferentes capas del stack:

Ruta 1 — el servidor MCP de documentación de BigCommerce. BigCommerce expone un endpoint MCP en https://docs.bigcommerce.com/_mcp/server que permite a los agentes de IA buscar en la documentación para desarrolladores de BigCommerce. Responde preguntas como "¿Cómo funciona la API de checkout de BigCommerce?" extrayendo información de los docs. Es un servidor MCP para documentación, no para datos de tienda. Un agente conectado a él puede aprender cómo funcionan las APIs de BigCommerce. No puede leer productos, clientes, pedidos o inventario de ninguna tienda. Es una herramienta de habilitación para desarrolladores, no una ruta de integración de tienda.

Ruta 2 — Agentic Commerce Suite de Stripe, construido sobre ACP. El anuncio de la asociación lo enmarca así: "Los comerciantes de BigCommerce podrán desbloquear flujos de descubrimiento y checkout impulsados por IA mientras continúan usando sus catálogos, sistemas de pedidos y procesos operativos existentes." El comerciante conecta su catálogo de productos a Stripe, selecciona qué agentes de IA venderán a través de la plataforma, y Stripe maneja el descubrimiento, checkout, pagos y detección de fraude. El artículo de Stripe sobre Agentic Commerce Suite cuantifica el costo alternativo: sin él, las empresas enfrentan "hasta 6 meses de trabajo de integración por cada nuevo agente de IA soportado." La ruta ACP reemplaza eso con una única integración configurable.

La arquitectura ACP es componible: agentic checkout (gestión de carrito, opciones de fulfillment, procesamiento de pagos), cart y feed (navegación del catálogo de productos), pago delegado vía Shared Payment Tokens (SPTs — limitados a un vendedor, acotados por tiempo y monto, observables a través de su ciclo de vida), autenticación delegada vía OAuth 2.0, y pedidos y webhooks para el seguimiento del ciclo de vida. Stripe Radar proporciona detección de fraude ajustada para patrones de tráfico no humano. El comerciante conserva el estado de merchant-of-record y el control sobre las relaciones con los clientes.

Esta ruta resuelve el problema de comercio de agentes consumidores: un comprador pide un producto a un agente de IA, el agente lo descubre a través del feed de catálogo de Stripe, completa el checkout a través de la API de Stripe Checkout Sessions, y paga a través de SPTs. No resuelve el problema B2B.

Ruta 3 — servidores MCP gestionados de proveedores terceros. StackOne ofrece un servidor MCP para BigCommerce con 120 acciones listas para usar. Truto expone las capacidades de la REST API de BigCommerce a través de su endpoint /tools. El proyecto de código abierto isaacgounton/bigcommerce-api-mcp envuelve toda la superficie de la REST API de BigCommerce. Estos servidores dan a un agente acceso tipado a productos, clientes, pedidos e inventario — las operaciones CRUD que la REST API soporta.

El problema no es lo que estos servidores gestionados hacen mal. El problema es lo que ninguna de las tres rutas codifica: la capa semántica B2B — el significado de negocio que determina qué precio aplica a qué cliente, qué stock es reservable, y qué pedidos se mapean a qué registros del ERP.

Lo que la ruta ACP no cubre para B2B

El feed de productos ACP a Stripe lleva un precio por producto — el precio del catálogo público. La estructura de precios B2B real de BigCommerce vive en Customer Groups y Price Lists. Los Price Lists permiten anulaciones de precio a nivel de variante asignadas a Customer Groups específicas en Sales Channels específicas vía la Price List Assignment API. Un distribuidor con cuatro niveles de precios — contrato enterprise, volumen mid-market, mayorista y retail público — tiene cuatro Price List Assignments que mapean cuatro Price Lists a cuatro Customer Groups a través de uno o más canales.

Cuando un agente de IA que representa al coordinador de compras de un comprador enterprise envía una solicitud a través de la ruta ACP, el agente ve el precio del catálogo público. El cliente tiene derecho contractual al precio del nivel enterprise — potencialmente 20-40% menor. El feed ACP no lleva la estructura de niveles. El agente cotiza el precio equivocado. El distribuidor absorbe el margen o cancela y pierde la venta.

El anuncio de la asociación con BigCommerce reconoce esto: los comerciantes "informan la compra agéntica con la lógica de inventario y precios de BigCommerce." Esa redacción significa que el comerciante configura la lógica de precios en BigCommerce, y Stripe se supone que la respeta — pero la arquitectura del feed ACP aplana el catálogo a una única superficie de precio. La inteligencia de niveles B2B no está en el feed.

La segunda brecha es el inventario. La Catalog Products API de BigCommerce reporta niveles de stock pero no los reserva. Un agente que cotiza 200 unidades contra un conteo en vivo de 240 puede estar equivocado para cuando la orden de compra llega, porque tres otras cotizaciones consumieron el mismo stock en el intermedio. La arquitectura del motor RFQ — reservas atómicas de disponibilidad con TTL, snapshots de políticas de cancelación, bloqueos de tasa FX — vive en el ERP y la capa de cotización, no en el storefront de ecommerce, y no en la ruta ACP.

La tercera brecha es la escritura al ERP. La ruta ACP entrega la orden aceptada al comerciante vía webhooks. El sistema de pedidos del comerciante — BigCommerce Orders API — la recibe. Pero el objeto de orden en BigCommerce no codifica contabilidad GL, subsidiaria, tax nexus o los campos personalizados que NetSuite o Brightpearl necesitan para contabilizar la orden correctamente. El análisis del módulo MCP de NetSuite cubre esto en profundidad: la brecha semántica entre una orden de ecommerce y un registro de orden en el ERP es qué cuentas GL, qué subsidiaria, qué tax nexus y qué campos personalizados constituyen una contabilización válida. La ruta ACP no cubre esa brecha.

Lo que los servidores MCP gestionados no codifican

Los servidores MCP gestionados (StackOne, Truto, Apideck) resuelven un problema distinto: dan al agente acceso tipado a la REST API de BigCommerce. Las 120 acciones de StackOne cubren productos, clientes, pedidos, inventario y gestión de tienda. Truto envuelve la REST API detrás de un endpoint unificado /tools. Estos son productos reales, no demos — hacen la API de BigCommerce legible para un agente de IA sin código de integración personalizado.

Pero el acceso tipado a la API no es lo mismo que significado de negocio tipado. Un servidor MCP gestionado que expone get_products(filters) da al agente la capacidad de consultar productos. No le dice al agente que para esta tienda, el grupo de clientes 4 ("Enterprise Contract") tiene derecho al Price List 7 en el canal "B2B Portal", y que una solicitud de un comprador en ese grupo debe resolverse a través de GET /v3/pricelists/7/records?variant_id={id} no a través del precio del catálogo por defecto. El servidor gestionado envuelve la superficie de la API. No codifica las reglas de negocio que determinan qué llamada a la API significa qué.

Este es el mismo patrón estructural que aparece a lo largo de la serie por conector. El análisis de HubSpot documenta seis vacíos de capacidad en el servidor de primera parte de HubSpot — sin objetos personalizados, sin planes de escritura revisables, un portal por conexión, sin diseño a nivel de sistema, consultas solo a la API en vivo y una restricción de datos sensibles. El análisis de Shopify documenta la ruta B2B — precios por nivel de cliente, cotización RFQ en volumen, reservas de inventario, atribución de pedidos — que el Storefront MCP de primera parte no cubre. En cada caso, el conector del proveedor resuelve el problema de conexión. El módulo MCP personalizado resuelve el problema de la capa semántica.

Para BigCommerce, el proveedor ni siquiera construyó el servidor MCP de la capa de conexión — se asoció con Stripe para el comercio de agentes consumidores y dejó la superficie MCP de datos de tienda a proveedores terceros. La brecha de la capa semántica es la misma. La diferencia es que la capa de conexión en sí está más fragmentada.

Autenticación: la restricción favorable a headless

La autenticación de API de BigCommerce usa X-Auth-Token — un bearer token limitado a la tienda generado desde el administrador de la tienda (Store Setup → API Settings) o emitido a través del flujo de instalación de OAuth app cuando un comerciante instala una app. A diferencia del OAuth 2.1 con PKCE de HubSpot (que requiere consentimiento basado en navegador y refresh tokens de un solo uso), los tokens de API de BigCommerce no expiran a menos que sean revocados y no requieren refresco basado en navegador. Esto es más favorable a headless que el servidor MCP de primera parte de HubSpot: un agente en background que corre a las 2 AM para sincronizar cambios de pedidos overnight puede autenticarse con un X-Auth-Token estático sin ningún humano en el ciclo.

La restricción es el límite de tasa, no la autenticación:

La API devuelve el estado del límite de tasa vía headers: X-Rate-Limit-Requests-Quota, X-Rate-Limit-Requests-Left, X-Rate-Limit-Time-Reset-Ms. Los endpoints de listado devuelven 250 items por página. Un agente que dispare 30 llamadas paralelas a herramientas contra una tienda Standard agotará la ventana de 150 requests en una ráfaga y recibirá 429s en el resto. Un servidor MCP gestionado que no impone throttling por herramienta pasa esa falla al agente como un error no estructurado.

Un módulo MCP personalizado impone límites de tasa por herramienta — cada herramienta declara su límite, el backbone regula las requests para mantenerse dentro de la ventana de 30 segundos, y el agente recibe un 429 estructurado con un Retry-After derivado de X-Rate-Limit-Time-Reset-Ms en lugar de un crash. El módulo también procesa por lotes las consultas de listado — en lugar de paginar a través de 200 requests de 250 items cada una, el módulo puede usar consultas filtradas para extraer solo los registros que el agente realmente necesita, manteniéndose dentro de la ventana de tasa.

Lo que proporciona un módulo MCP personalizado

El patrón del módulo sigue el MCP Module Code Standard: cada herramienta tiene un schema de entrada tipado, un schema de salida tipado, un límite de tasa, un log de auditoría y un contrato de errores. El agente llama herramientas por nombre con argumentos estructurados, no llamadas a API de forma libre contra endpoints crudos.

Para BigCommerce, el módulo personalizado llena los vacíos que la ruta ACP y los servidores MCP gestionados dejan abiertos:

Resolución de precios por grupo de clientes. El módulo expone get_tier_price(customer_id, product_id, channel_id, quantity) — una herramienta tipada que resuelve el Customer Group del comprador, encuentra el Price List Assignment para ese grupo en el canal actual, y devuelve el precio a nivel de variante para la cantidad solicitada. El agente no necesita saber que el grupo de clientes 4 se mapea al Price List 7. El módulo codifica el mapeo. El agente llama get_tier_price y recibe el precio de contrato correcto, no el precio del catálogo público.

Reservas de disponibilidad de inventario. El módulo envuelve la verificación de nivel de stock de BigCommerce y añade una capa de reserva — ya sea contra el inventario de BigCommerce si la tienda lo soporta, o contra el ERP upstream (NetSuite, Brightpearl) donde vive el conteo de stock autoritativo. El agente llama acquire_availability_hold(product_id, quantity, duration_minutes) y recibe un token de reserva con un TTL, consistente con la arquitectura del motor RFQ. La cotización está respaldada por stock reservado, no por un conteo en vivo que puede desaparecer.

Escritura al ERP con mapeo semántico. El módulo acepta una orden de BigCommerce y la transforma al formato esperado por el ERP — contabilidad GL, subsidiaria, tax nexus, campos personalizados. El agente llama create_erp_order(bigcommerce_order_id) y el módulo maneja la transformación, la selección de superficie de API (SuiteTalk REST, RESTlets, SuiteQL para NetSuite; la API de Brightpearl para Brightpearl), la autenticación y el log de auditoría. El agente no construye una firma OAuth ni elige una superficie de API.

Planes de escritura revisables. El módulo redacta un plan estructurado para cambios multi-paso — "crear 15 órdenes de las cotizaciones aceptadas de ayer, contabilizar cada una en NetSuite con la contabilidad GL correcta, crear tareas de fulfillment en BigCommerce" — y lo enruta a un revisor humano antes de la ejecución. La ruta ACP y los servidores MCP gestionados ejecutan inmediatamente. El módulo añade la compuerta de revisión que evita que un lote equivocado distorsione el ERP.

Consultas limitadas en tasa y procesadas por lotes. El módulo impone el límite de tasa de BigCommerce internamente — throttling por herramienta, consultas de listado por lotes, y una capa de datos gestionada que sincroniza datos de catálogo y pedidos a un almacén local para análisis entre objetos sin round-trips a la API por cada pregunta. El agente pregunta "muéstrame todas las órdenes del grupo de clientes Enterprise en los últimos 30 días sin correspondencia en NetSuite" y el módulo devuelve la respuesta desde la capa local, no desde 30 minutos de llamadas paginadas a la API.

Por qué esto se generaliza

El patrón de BigCommerce — un proveedor que se asocia para la ruta de agente consumidor en lugar de construir su propio servidor MCP de datos de tienda, una capa MCP gestionada que envuelve la REST API sin codificar el significado de negocio, y una capa semántica B2B que ninguna de las superficies disponibles cubre — es la misma estructura que aparece a lo largo del panorama de ecommerce y ERP, con una distribución diferente de vacíos:

• Shopify construyó la superficie de agente de primera parte más completa (Storefront MCP, Customer Accounts MCP, UCP), pero la ruta B2B — precios por nivel de cliente, cotización RFQ en volumen, reservas de inventario contra NetSuite — no está en la superficie de primera parte. El análisis del conector de Shopify cubre esto.
• HubSpot construyó un servidor MCP de primera parte con 12 herramientas que cubren objetos CRM estándar, pero los objetos personalizados, los planes de escritura revisables, la autenticación headless y las operaciones multi-portal son vacíos. El análisis del conector de HubSpot cubre esto.
• NetSuite tiene un AI Connector Service de primera parte pero advierte en su propio FAQ que "la IA puede alucinar. Valide siempre los resultados contra los datos de origen." La brecha semántica es qué cuentas GL constituyen ingresos. El análisis del módulo MCP de NetSuite cubre esto.

El Anthropic 2026 State of AI Agents Report (500+ líderes técnicos, implementaciones reales en Novo Nordisk, Doctolib, L'Oréal, Shopify) identifica la integración con sistemas existentes como la barrera número uno para la adopción de agentes — 46% de las organizaciones la citan, por encima del acceso a datos (42%), seguridad (40%) e inteligencia del modelo. El 47% usa un enfoque híbrido build-and-buy: no enteramente pre-construido, no todo in-house, sino una plataforma que extienden con código personalizado. La ruta ACP es la mitad "buy" para BigCommerce. Los servidores MCP gestionados son la mitad "buy" para el acceso a datos de tienda. El módulo personalizado es la mitad "build" — la capa semántica que hace al agente útil para operaciones B2B, no solo para checkout de consumidores.

La asociación de BigCommerce con Stripe fue una decisión de producto acertada — Stripe maneja la infraestructura de pagos y la detección de fraude mejor de lo que la mayoría de plataformas de ecommerce podrían construirlas. Pero la asociación cubre la ruta de consumidores. La ruta B2B — donde el comprador es un coordinador de compras con precios negociados, donde el inventario debe reservarse no solo reportarse, y donde la orden debe llegar al ERP con la contabilidad GL y el mapeo de subsidiaria correctos — requiere la misma capa de módulo personalizado que cualquier otro conector en esta serie requiere. El MCP Module Code Standard define la estructura. El conector de BigCommerce es la implementación de referencia para el caso de la ruta de asociación — el caso donde el proveedor externalizó la capa de agente consumidor y dejó la capa semántica B2B al equipo de integración.

Un distribuidor B2B que corre BigCommerce en el storefront, NetSuite o Brightpearl para ERP, y cuatro niveles de precios por grupo de clientes obtiene un agente que resuelve el precio de contrato del comprador a través de la Price List Assignment API, adquiere una reserva atómica de disponibilidad contra el conteo de inventario del ERP, snapshot de los términos comerciales al momento de la cotización, y escribe la orden aceptada al ERP con la contabilidad GL y el mapeo de subsidiaria correctos — con cada llamada a herramienta limitada en tasa, registrada y enviada a un revisor humano para excepciones. Esa construcción es Phase 2-3 del método de cuatro pasos y está típicamente en producción en 5-8 semanas.

Solicite una construcción con alcance definido. Discovery de una semana. Obtendrá un inventario de sistemas, mapa de flujos de trabajo y alcance fijo — independientemente de si construye con nosotros.