La forma más habitual en que esto falla es silenciosa. Sigues una guía de configuración, pegas un bloque JSON en la configuración de tu cliente, reinicias y funciona: aparece la lista de herramientas y la conexión está en verde. Luego preguntas cómo fueron los pedidos de ayer y no obtienes nada útil, sin que el motivo resulte evidente.
La razón es que Shopify ofrece dos servidores MCP distintos, y el más fácil de configurar no puede ver tu tienda.
Los dos servidores
Shopify publicó el código de su AI Toolkit en abril de 2026 y reunió su conjunto oficial de servidores MCP, habilidades de agentes y un complemento de Claude Code en un único espacio de nombres. Dentro de ese espacio hay dos cosas que la gente suele confundir.
Dev MCP se ejecuta localmente, no requiere iniciar sesión y proporciona al asistente la documentación para desarrolladores y los esquemas de API de Shopify. Está pensado para quienes crean aplicaciones de Shopify y hace muy bien ese trabajo. No leerá los pedidos de ayer ni editará un producto porque, por diseño, nunca accede a una tienda en funcionamiento.
Admin MCP es el que trabaja con datos reales de la tienda y necesita un token de Admin API. Ese token marca toda la diferencia y también supone todo el esfuerzo de configuración.
Si estás desarrollando sobre Shopify, instala Dev MCP y deja de leer. Es gratuito y oficial, y este artículo no pretende sustituirlo. Si gestionas una tienda y quieres hacer preguntas sobre ella, necesitas el otro.
Qué te exige realmente la vía de Admin
Creas una aplicación personalizada dentro del panel de administración de tu tienda, le concedes los permisos de acceso de Admin API que necesita y conservas el token resultante. Son tres decisiones que la gente tiende a tomar mal.
La primera es la amplitud de los permisos. Si concedes muy pocos, el fallo llega después, al realizar una llamada, como un error de autorización dentro de una respuesta del chat donde resulta difícil de leer. Si lo concedes todo, habrás creado un token capaz de reescribir tu catálogo, almacenado en un archivo de configuración en una computadora portátil.
La segunda es dónde se guarda el token. Un token en texto sin cifrar dentro de una configuración JSON es la opción predeterminada que muestran la mayoría de las guías, porque es la instrucción más breve de escribir. No es la que elegirías para una credencial capaz de publicar productos.
La tercera es la renovación. Los tokens siguen vigentes después de que desaparezca el motivo por el que los creaste. Nada en la configuración te lo recuerda.
Leer y escribir no implican el mismo riesgo
Preguntar qué SKU se agotaron la semana pasada es una lectura. Es barata, reversible y, si la respuesta es incorrecta, lo detectas y sigues adelante.
Cambiar un precio, editar la descripción de un producto, publicar en un canal de ventas. Todo esto se ejecuta en una tienda activa donde hay clientes comprando en este momento. El protocolo no contempla esa distinción. MCP describe una herramienta y sus argumentos; no incorpora la noción de "esta operación es irreversible".
Eso significa que el control debe estar en el cliente. Si tu cliente ejecuta las llamadas a herramientas en cuanto el modelo las emite, lo único que se interpone entre una instrucción mal interpretada y un catálogo con precios modificados es que el modelo tenga un buen día. Nadie elige deliberadamente ese perfil de riesgo; es algo que se hereda de una guía de configuración.
El mismo esquema en todas las demás plataformas
eBay, Etsy y WooCommerce ya tienen servidores MCP comunitarios, y la historia se repite de forma casi idéntica: un token o un par de claves que generas por tu cuenta, una decisión sobre los permisos, un proceso local que mantener en ejecución y un cliente al que debes confiar las escrituras. Un vendedor que opera en cuatro plataformas y elige esta vía termina gestionando cuatro pequeños servicios y conservando cuatro credenciales, lo que constituye un trabajo real que nadie incluyó en la hoja de ruta.
Dónde encaja Orkas
Orkas es un cliente MCP, así que todos los servidores descritos anteriormente funcionan con él igual que con otros clientes. También incluye su propio conector de Shopify Admin, basado en una aplicación de Dev Dashboard propiedad del comerciante, y hay dos detalles que explican su razón de ser.
Los permisos se validan al conectarte, no cuando falla una llamada. Orkas comprueba cada permiso requerido: productos, pedidos, clientes, inventario, ubicaciones, pedidos preliminares, devoluciones, descuentos, publicaciones y los permisos aplicables a las órdenes de preparación de pedidos. Te indica cuál falta antes de que hayas dedicado una conversación a descubrirlo. Las credenciales se cifran en tu propio dispositivo en lugar de quedar en un archivo de configuración.
Y el control de escritura está en el cliente, no en la instrucción. Cualquier operación que escriba, elimine, gaste o acceda a una tienda en funcionamiento pasa por una solicitud de permiso, con controles separados para las acciones irreversibles y las rutinarias. El mismo catálogo abarca eBay, Etsy, Walmart Marketplace, WooCommerce y Amazon Seller Central, además de las plataformas chinas, para que el problema de los cuatro servicios no se repita por cada tienda.
Qué no cubre esto
Nada de esto convierte a Orkas en un sistema de gestión de tiendas. No mantiene el inventario, deriva pedidos ni ajusta precios por ti; si necesitas eso, conserva el ERP. Lo que sustituye es el conjunto de pequeñas integraciones que, de otro modo, tendrías que montar para hacer preguntas sobre tu propia tienda y actuar según las respuestas. Para la parte de actuar, también sustituye la suposición de que basta con que un modelo tenga un buen día como medida de protección.