Un servidor MCP ya es lo mínimo que se espera de un CMS. Contentful, Sanity, Storyblok y Payload incluyen uno, y un agente puede escribir y publicar contenido en cualquiera de ellos. La pregunta ha cambiado: ¿a qué puede llegar el agente una vez conectado? En una tienda, la respuesta decide si un agente es un redactor o un operador.

Este artículo recorre lo que expone el servidor MCP de cmssy, cómo te conectas, un pedido mayorista gestionado de principio a fin en una sola conversación y lo que aún falta por mejorar.

Lo que cambia MCP, y lo que no

MCP estandariza cómo un agente descubre herramientas y las llama. No hace que tus datos estén más limpios. Un agente conectado a una tienda cuyos pedidos viven en un sistema, los precios en una hoja de cálculo y los textos en un CMS pasará sus turnos cosiendo tres API entre sí, y se equivocará en las costuras.

cmssy mantiene las piezas en un solo workspace: páginas y bloques, modelos de datos personalizados, productos y stock, listas de precios y canales de venta, clientes y sus empresas, carritos, pedidos, devoluciones, paquetes y facturas. Un solo servidor lo expone todo, bajo un único conjunto de roles. Ese es todo el argumento de este artículo, y lo que sigue es cómo se ve en la práctica.

Conectarse

Hay dos formas de entrar.

• Alojado, para Claude. Claude en la web, Claude Desktop y Claude Code se conectan a https://api.cmssy.io/mcp. Inicias sesión en cmssy (OAuth 2.1 con PKCE), marcas los workspaces que Claude puede usar y eliges Solo lectura o Lectura y escritura. No hay token que copiar ni nada que instalar. En Claude Code es un solo comando: claude mcp add --transport http cmssy https://api.cmssy.io/mcp, y después /mcp para iniciar sesión.
• stdio, para todo lo demás. Los jobs de CI, los scripts y cualquier cliente MCP ejecutan npx @cmssy/mcp-server con un API token (cs_…) y un id de workspace. Las mismas herramientas, los mismos permisos.

En ambos casos el agente actúa como la persona que lo conectó, con el rol de esa persona en cada workspace, y cada cambio queda en el registro de auditoría del workspace a su nombre. Una conexión puede abarcar varios workspaces: cada herramienta recibe un argumento workspace y list_workspaces devuelve los que has autorizado.

Qué expone el servidor

A octubre de 2026, el servidor tiene 132 herramientas. Comparten un mismo patrón de nombres - list_* y get_* para leer, create_*, update_* y delete_* para escribir, más verbos para los cambios de estado - y se agrupan en unos pocos bloques:

• Contenido - páginas, bloques, regiones de layout, page types, publicación, medios, formularios y sus envíos, modelos y registros personalizados. list_block_types devuelve los tipos de bloque que tu sitio registra realmente, así que el agente rellena los campos que renderizan tus componentes en lugar de adivinar.
• Catálogo - productos, variantes, tramos por volumen, precios por moneda, actualizaciones masivas.
• Precios B2B - listas de precios con un porcentaje de descuento o precios fijos por producto y variante, ventanas con fechas, canales de venta y asignación a una empresa o a un cliente.
• Clientes y empresas - las cuentas que inician sesión en tu sitio, sus empresas, los NIF-IVA de la UE y su verificación, las exenciones fiscales, las suspensiones y los restablecimientos de contraseña.
• Pedidos - pedidos manuales, ediciones, pagos registrados, reembolsos, cancelaciones, el pipeline de pedidos, paquetes y seguimiento, devoluciones, facturas y facturas rectificativas, anonimización.
• Webhooks - endpoints, registros de entregas, reenvío y rotación de secretos.

La lista completa, con el permiso que necesita cada herramienta, se genera desde el servidor en cada versión y se publica como el catálogo de herramientas MCP.

Hay dos cosas ausentes a propósito. Ninguna herramienta toca tu código: nada escribe un archivo, edita un componente ni abre un pull request, porque los esquemas de bloques viven en tu repositorio, sujetos a revisión. Y ninguna herramienta mueve dinero: cmssy registra los pagos y reembolsos que hizo tu proveedor, nunca cobra una tarjeta.

Un pedido mayorista, del presupuesto a la factura

Este es un caso B2B que suele repartirse entre un ERP, una hoja de precios y dos paneles de administración. Un distribuidor de ferretería firma con un nuevo cliente profesional, acuerda precios de contrato para tres productos, recibe el primer pedido por email y lo envía. Cada paso de abajo es un prompt a Claude y las herramientas que llama.

1. Una lista de precios para la cuenta

Crea una lista de precios "Trade - Nordbau" con un 12% de descuento sobre el catálogo,
y precios fijos para los tres acoplamientos de la hoja adjunta.

create_price_list con percentOff: 12, y después set_price_list_entries con los precios fijos en unidades menores. Un precio fijo sustituye al porcentaje para su producto o variante; todo lo demás recibe el precio de catálogo menos un 12%. La llamada es todo o nada: una fila incorrecta rechaza toda la importación e indica la fila.

2. La empresa

El NIF-IVA de Nordbau GmbH es DE123456789 - lo comprobé en VIES.
Asígnales la nueva lista.

set_company_vat_id normaliza el número y comprueba su formato, set_company_vat_verified registra que alguien lo comprobó y set_company_price_list asocia la lista. Ahora todos los miembros de la empresa pagan según ella. Un NIF-IVA verificado de un Estado miembro distinto al del vendedor aplica tipo cero a sus pedidos por inversión del sujeto pasivo, salvo que el pedido se envíe al país del vendedor.

Fíjate en la separación: verificar un NIF-IVA cambia cómo se gravan los pedidos, así que requiere un par de permisos más fuerte que el de establecer el número. Un agente conectado por alguien que no lo tiene recibe un error.

3. El pedido

Nordbau ha enviado un pedido por email: 40 x acoplamiento NW7.2, 25 x NW10,
envío a su almacén de Hamburgo. Introdúcelo.

create_manual_order con el cliente y las líneas. Como el comprador pertenece a Nordbau, las líneas se valoran con la lista de la empresa, y la dirección de envío decide el tratamiento fiscal, que el pedido congela. get_order muestra exactamente lo que se aplicó: la lista que valoró cada línea, el tratamiento del IVA y la nota legal que hay que imprimir.

4. El pago

Ha llegado la transferencia de ese pedido, referencia NB-2026-118.

record_order_payment con el importe y la referencia. Los pagos parciales no son problema; el importe está limitado al saldo pendiente y el pedido pasa a pagado cuando queda cubierto.

5. El paquete

Ha salido con DHL, número de seguimiento 00340434...

create_shipment con el transportista y el número de seguimiento. Si se omiten los artículos, se envían todas las unidades aún no enviadas y el pedido se marca como completado.

6. La factura

Nuestro sistema contable ha emitido la FV/2026/1042 para él - aquí está el enlace al PDF.

record_order_invoice guarda el número, el enlace y el proveedor en el pedido y dispara order.invoiced. Registrar el mismo número otra vez no hace nada, así que un agente que reintenta no causa ningún daño. Un reembolso posterior recibe una factura rectificativa con record_order_invoice_correction; el artículo sobre facturación cubre la versión automatizada de este paso.

Nada de esto es un benchmark. Es la forma del trabajo: cada paso es una herramienta con una entrada acotada, cada paso se comprueba contra el rol de la persona que conectó el agente, y el agente nunca necesita la API de un segundo proveedor para terminar el trabajo.

Salvaguardas

Un agente que puede verificar un NIF-IVA o reembolsar un pedido merece más cuidado que uno que edita un título. Lo limitan cuatro capas, de fuera hacia dentro.

• Aprobación en el cliente. Cada herramienta lleva anotaciones MCP: readOnlyHint en las herramientas que solo leen, destructiveHint en las que cambian o eliminan datos. Claude Code pregunta antes de cualquier herramienta que no esté en tu lista de permitidos, así que deja fuera de ella refund_order, cancel_order, publish_page y las herramientas de borrado, y aprueba cada una a medida que llega.
• Acceso de solo lectura. Una conexión alojada concedida en solo lectura rechaza en el servidor toda escritura, apruebe lo que apruebe el cliente.
• Tu rol. El agente tiene exactamente los permisos que tienes tú en ese workspace. Desconectarlo en Cuenta → Aplicaciones conectadas lo corta en todas partes a la vez; un admin del workspace puede quitar un workspace de la conexión de un miembro.
• El registro de auditoría. Cada cambio se registra a nombre de la persona que conectó el agente, como un cambio hecho en el admin.

Una nota honesta: el servidor MCP en sí no tiene un paso de confirmación. Una herramienta destructiva se ejecuta en su primera llamada, y el control es la aprobación de tu cliente. La excepción es el asistente integrado del admin - ahí el servidor retiene una herramienta destructiva hasta que la apruebas con un botón.

Lo que aún falta por mejorar

• Otros generadores de apps. El servidor alojado registra clientes mediante Client ID Metadata Documents, que Claude admite. Los generadores que solo hablan Dynamic Client Registration o un token bearer estático, como v0, Lovable y Bolt, aún no pueden conectarse al endpoint alojado, y como herramientas alojadas tampoco pueden ejecutar el paquete stdio. Las apps que generan leen el contenido a través del SDK sin problema; lo siguiente por resolver es la conexión del agente en tiempo de build.
• Búsqueda. La búsqueda de texto completo en el contenido está disponible en el asistente del admin, pero no está enlazada en el servidor MCP.
• Nuevos workspaces. Un workspace al que te unes después de conectar no se añade a la conexión. Vuelve a conectar para incluirlo.

Pruébalo

Añade el servidor alojado a Claude, inicia sesión y pídele que liste tus pedidos. La documentación del servidor MCP cubre ambos métodos de conexión, el tutorial de Claude Code construye una página con él y el caso de soporte paso a paso resuelve un reembolso, un descuento y un banner en una sola conversación. El contenido funciona en todos los planes; el carrito y el checkout requieren Pro.