Por qué los MCPs "pegados con cinta" a Shopify y WooCommerce no son la respuesta — el agente termina haciendo de humano lento
Hay una diferencia enorme entre una plataforma que expone su API via MCP y una plataforma diseñada para ser operada por agentes desde el día cero. Una distinción que la mayoría de los anuncios de 2025-2026 prefieren ignorar.
El anuncio de la semana
Desde que Anthropic lanzó el Model Context Protocol a finales de 2024, el ciclo de noticias tech tiene un nuevo formato de comunicado de prensa. Va así: empresa SaaS consolidada anuncia "soporte nativo de MCP", publica un repositorio en GitHub con un servidor que expone algunos endpoints de su API admin, recibe cobertura entusiasta. Fin.
El problema no es que el anuncio sea falso. El servidor MCP existe. Funciona. Un agente puede preguntarle cuántos productos tiene la tienda o qué órdenes llegaron hoy. El problema es lo que no se dice: qué pasa cuando el agente intenta hacer algo que no estaba en la API admin desde el principio.
Ahí es donde empieza el teatro.
El gap estructural del Admin API
Shopify tiene una de las APIs admin más completas del ecommerce. Años de trabajo, miles de endpoints, documentación extensa. Y aun así, hay un gap significativo entre lo que la API expone y lo que el dashboard permite hacer.
Configurar una automatización de email con condiciones complejas basadas en comportamiento del cliente: UI-only, sin API completa. Personalizar el checkout en profundidad (scripts de descuento, lógica de envío condicional): parcialmente en API, parcialmente en UI, con algunas funciones que requieren Shopify Functions (que implican desplegar código, no configurar una opción). El diseño del storefront con Liquid templates y el editor visual de secciones: no hay un API que permita al agente manipular el layout como lo hace un humano en el editor. Ciertas integraciones de apps del marketplace de Shopify instalan configuraciones en pantallas propias de la app, completamente fuera del Admin API.
Este gap no es una falla de Shopify. Es la consecuencia natural de construir durante años una plataforma centrada en la experiencia humana. Las features de alto valor agregado — las que los merchants pagan — suelen estar en la UI porque la UI permite interacciones ricas que una API REST no captura fácilmente. El problema aparece cuando querés que un agente las opere.
El fallback que nadie menciona: computer-use
Cuando un agente basado en MCP encuentra un flujo que no tiene herramienta, tiene dos opciones: declarar que no puede hacer eso, o caer en computer-use.
Computer-use es la capacidad de los modelos modernos — Claude incluido, desde su lanzamiento documentado en el blog de Anthropic — de controlar una pantalla: ver screenshots, mover el cursor, hacer clic, escribir texto. Es poderoso para tareas donde no hay otra interfaz disponible. Pero como modo de operación principal de una plataforma de ecommerce, tiene tres problemas graves:
- Velocidad. Cada acción requiere un screenshot, análisis visual del modelo, decisión de dónde hacer clic, ejecución, nuevo screenshot para verificar. Un flujo de configuración que via API tomaría milisegundos puede tardar minutos en computer-use. Para operaciones de baja frecuencia está bien. Para el flujo de setup de una tienda o una campaña de ads, es una experiencia frustrante.
- Costo de tokens. Cada screenshot es una imagen que entra al contexto del modelo. En Claude Sonnet o GPT-4o, las imágenes cuestan tokens sustancialmente más caros que el texto equivalente. Una sesión de computer-use que dura 10 minutos puede consumir tokens por varios dólares — órdenes de magnitud más caro que las mismas operaciones via API tipada.
- Fragilidad ante cambios de UI. Shopify rediseña su dashboard. Cambia el nombre de un botón, reorganiza un menú, mueve una sección. El agente que aprendió a navegar la UI anterior falla silenciosamente o con errores crípticos. Los MCP servers con herramientas tipadas no tienen este problema: el contrato es la API, y los cambios de UI no afectan al agente.
Un agente de IA operando via computer-use es, funcionalmente, un empleado que no sabe usar el teclado: puede llegar al mismo resultado, pero con el triple del tiempo y la mitad de la confiabilidad.
WooCommerce: el mismo problema, amplificado
Si el gap en Shopify es significativo, en WooCommerce es abismal. La REST API de WooCommerce cubre productos, órdenes, clientes, cupones, reportes básicos. Para todo lo demás — configurar un plugin de envío específico, ajustar las opciones de un gateway de pago, modificar los emails transaccionales, gestionar el comportamiento del carrito — hay que navegar el panel de WordPress.
Peor aún: cada plugin de terceros trae su propia pantalla de configuración, con su propio esquema de datos, fuera del alcance de cualquier API central. Un MCP server para WooCommerce puede leer las órdenes perfectamente. Pero "configurá el plugin de Mercado Pago para que use el modo sandbox en staging" es literalmente imposible via API para la mayoría de los plugins — hay que hacer clic en pantallas que cada plugin diseñó independientemente.
La respuesta honesta de cualquier MCP server retrofitteado sobre WooCommerce es: "puedo hacer el 30-40% de lo que necesitás, y para el resto necesito un browser".
El test que deberías hacer antes de creer el anuncio
Cuando una plataforma anuncia soporte MCP, hay una pregunta simple que revela si es nativo o retrofit: ¿Qué pasa cuando le pedís al agente que configure algo que en el dashboard está a cuatro clics de profundidad?
Intentá, con el MCP server de turno, alguno de estos:
- Configurar una regla de shipping que aplique tarifa plana para órdenes de más de X peso, pero solo para ciertas provincias.
- Activar la facturación automática y conectarla con el sistema fiscal local.
- Crear una automatización de email para carrito abandonado con delay de 2 horas y descuento del 10% en el segundo email.
- Cambiar el diseño de un bloque específico de la home sin tocar código.
Si la respuesta del agente es "no tengo una herramienta para eso" o si el agente abre un browser y empieza a hacer clic, tenés tu respuesta sobre la madurez del soporte MCP.
Por qué el retrofit tiene sentido en algunos casos
Antes de seguir, hay que ser justo. Hay casos de uso donde el MCP retrofitteado funciona bien y es suficiente:
Si lo que necesitás es que el agente lea datos — órdenes, inventario, clientes, métricas de ventas — y los agregue, analice o incluya en reportes, la mayoría de los Admin APIs son suficientemente completos. Un agente que consulta tu tienda Shopify para darte un reporte diario de ventas, alertarte cuando el stock de un producto cae por debajo de un umbral, o identificar los productos con mejor margen: eso funciona perfectamente via retrofit.
El problema no es el MCP retrofit en sí. El problema es cuando el retrofit se presenta como si permitiera operar la tienda de punta a punta, y el agente inevitablemente choca contra los límites de lo que la API expone.
Shopify es excelente si querés diseñar cada pixel de tu tienda. El retrofit MCP funciona si solo querés que el agente lea datos de órdenes. Se rompe en el momento en que querés que el agente cambie la configuración de la tienda.
La diferencia arquitectónica: API-first vs. LLM-first
Una plataforma diseñada para humanos tiene una arquitectura natural: hay una base de datos, hay lógica de negocio, hay una API admin para integraciones, y hay una UI web que es la interfaz principal. El MCP server retrofitteado se enchula a la API admin. Hereda sus capacidades y sus limitaciones.
Una plataforma diseñada LLM-first invierte el orden. La interfaz primaria de configuración son las herramientas MCP. La UI web, si existe, es una representación secundaria del mismo estado. Cada operación que el negocio necesita está modelada como una herramienta tipada con esquema explícito, parámetros validados, y respuesta estructurada que el agente puede usar directamente.
El servidor MCP de Wafle — @wafle/mcp, código abierto, licencia MIT — tiene 68 herramientas. No son 68 wrappers de endpoints REST existentes. Son 68 operaciones diseñadas desde cero pensando en qué necesita hacer un agente para operar una tienda completa: crear productos con variantes y atributos, configurar métodos de pago, gestionar zonas de envío, emitir facturas AFIP, lanzar y ajustar campañas de Meta Ads, manejar devoluciones, configurar automatizaciones de email.
Cuando el agente llama a wafle_meta_ads_campaign_create, no está navegando un browser. No está parseando HTML. Está ejecutando una operación tipada que devuelve un ID de campaña y métricas iniciales en JSON. El contrato es explícito. No hay UI que pueda romperse.
El costo de la fragilidad en producción
Los efectos de la fragilidad del computer-use son difíciles de cuantificar hasta que te pegan. Un agente que opera via computer-use en una tienda de ecommerce real tiene un riesgo que no tiene el agente con herramientas tipadas: puede hacer clic en lo que no es.
En el mejor caso, el agente falla y lo sabés de inmediato — "no pude completar la acción". En el peor caso, el agente cree que completó la acción pero hizo algo levemente diferente a lo que pediste — configuró la tarifa de envío en $5 en lugar de $0.5, activó el modo producción cuando querías sandbox, publicó los precios en pesos cuando debían estar en dólares.
Las herramientas MCP tipadas tienen esquemas explícitos. Si el parámetro currency acepta solo "USD", "ARS", o "COP", el modelo no puede poner otra cosa sin que la herramienta lo rechace con un error claro. La validación ocurre en la capa de la herramienta, no en la interpretación visual del agente.
Lo que viene: el mercado va a aprender a distinguir
La buena noticia es que la distinción entre MCP nativo y MCP retrofit va a volverse más visible a medida que los equipos empiecen a usar agentes en operaciones reales de ecommerce, no en demos. Las demos siempre eligen los flujos que funcionan — leer órdenes, crear un producto simple, generar un reporte. Las operaciones reales encuentran los bordes.
Hay una prueba de madurez simple: ¿cuántas de las operaciones del MCP server requieren que el agente tenga acceso a un browser además del servidor? Si la respuesta es "algunas" o "no sé", el retrofit no está listo para operar una tienda de producción.
El estándar MCP en sí es sólido. El protocolo es bueno. Lo que varía es si la plataforma debajo fue construida para soportarlo de forma nativa o si el servidor MCP es una capa delgada sobre una arquitectura que no fue diseñada para agentes.
Esa diferencia, hoy en 2026, es exactamente la que separa las plataformas que van a dominar la próxima generación del ecommerce de las que van a seguir siendo muy buenas plataformas para humanos que hacen clic.