Explorar la documentación
MCP server

Servidor MCP

El endpoint MCP remoto: URLs, los dos modos de autenticación, y qué ve un cliente al conectarse.

BoostEcom ejecuta un servidor MCP remoto, un endpoint por tienda conectada. Es la superficie a través de la cual un cliente de IA lee una tienda Shopify y los datos de BoostEcom asociados a ella.

Solo lectura. Cada herramienta del catálogo es una lectura, incluida la que recibe un documento GraphQL: shopifyAdminGraphQL ejecuta consultas y rechaza las mutaciones, por su nombre, en el handler. Una escritura en una tienda en producción es una decisión que alguien tiene que aprobar, y un relay no tiene a nadie dentro: un cliente de IA llama, la llamada llega, nada se interpone. Mientras no exista un circuito de aprobación, rechazar es la única respuesta que no puede cambiar en silencio el catálogo de un cliente.

El endpoint

https://boostecom.app/api/mcp/v1/<storeId>

La forma sin versión, /api/mcp/<storeId>, se lanzó primero y se mantiene en la configuración de cada cliente instalado desde entonces. Permanece, exactamente igual. Ambas son un solo endpoint con dos nombres: los mismos manejadores, y un token emitido a través de cualquiera funciona en ambas.

Usa la ruta v1 para todo lo nuevo.

Dos modos de autenticación

| Modo | Credencial | Familias de herramientas que abre | |---|---|---| | OAuth 2.1 PKCE | Token de acceso de /oauth/authorize | Relay y native. | | Estático | Bearer bst_mcp_ | Solo relay: las 15 herramientas relay, dentro de los permisos de Shopify de la tienda. |

La asimetría es deliberada y se explica en Herramientas y scopes MCP.

Una clave estática no lleva ninguna cadena de scopes: se lee como la concesión heredada, que se expande a la familia relay y a nada más. Eso tiene dos consecuencias. Las herramientas de documentación public, searchDocs y getDoc, admitirían a un llamante que el relay no puede nombrar, pero una clave estática nunca nombra su scope: no se registran para ella y solo llegan a un cliente por OAuth. Y las herramientas native nunca se registran para una clave estática, sea cual sea la concesión, porque exigen un llamante identificado.

Qué protege una herramienta

Tres puertas, y una herramienta debe superarlas todas para registrarse en una sesión dada:

  1. El scope de BoostEcom aprobado: lo que consintió el usuario.
  2. Los scopes de Shopify de la tienda: un techo duro. Si la Custom App o la instalación OAuth nunca obtuvo read_orders, ningún scope de BoostEcom lo conjura.
  3. Un llamante identificado: requerido solo por las herramientas native, porque su permiso depende de una pertenencia a organización y no hay nadie que verificar en modo estático.

Una herramienta que falla en cualquier puerta no se registra: no aparece en absoluto en la lista de herramientas del cliente, en lugar de aparecer y fallar al llamarla. Ese es el comportamiento correcto para un cliente de IA: una herramienta que puede ver es una herramienta que va a intentar.

Conectar un cliente

Cuatro clientes tienen una guía paso a paso:

Cada una da la URL, el modo de autenticación que soporta ese cliente, y un fragmento de configuración listo para pegar.

Descubrimiento de agentes

La plataforma publica un perfil de agente UCP en /.well-known/ucp-agent. Declara capacidad de lectura de catálogo y no lleva secretos. Es lo que lee cada tienda Shopify que consultamos para negociar nuestras capacidades antes de responder.

Siguiente

¿Has construido con estas docs?

Pásate por el foro si algo no está claro o es incorrecto. La documentación mejora más rápido cuando los lectores señalan los huecos.

Abrir el foro