MCP en 13 CMS: quién diseñó bien sus tools y quién no

En pocas palabras: Una investigación de septiembre de 2026 evaluó 13 sistemas web con MCP usando 8 criterios de Anthropic. WordPress.com y Storyblok lograron 8/8 puntos por su diseño de herramientas, mientras que Duda sacó apenas 2/8: su tool de borrado de cuenta no tiene ningún paso de confirmación documentado.

En septiembre de 2026 una investigación evaluó el diseño de herramientas MCP en 13 sistemas de sitios web usando 8 criterios basados en las guías de Anthropic. WordPress.com y Storyblok sacaron el puntaje máximo, 8 sobre 8, mientras que Duda quedó último con apenas 2/8 por tener una herramienta de borrado de cuenta sin ningún paso de confirmación documentado.

El Model Context Protocol (MCP) es un estándar abierto que permite a los agentes de inteligencia artificial comunicarse con software externo usando el mismo lenguaje, sin que cada sitio tenga que programar una integración distinta para cada IA. Lo desarrolló Anthropic y hoy lo adoptan CMS, plataformas de e-commerce y builders de sitios web para que un agente pueda crear contenido, gestionar productos o modificar páginas directamente.

¿Qué diferencia hay entre diseñar una API tradicional y diseñar una herramienta MCP?

Una API se llama según una especificación fija: el programador sabe de antemano qué endpoint va a usar, con qué parámetros y en qué orden. Una herramienta MCP la elige el agente de IA en tiempo real, evaluando el nombre, la descripción y los resultados anteriores. Esa diferencia cambia todo el enfoque de diseño.

Ponele que armás un tool llamado update_item con la descripción “Updates an item”. Un desarrollador que lee el código fuente entiende exactamente qué hace. Pero un agente de IA que solo ve ese nombre y esa frase corta tiene que adivinar si “item” es un producto, una página o un usuario, y en qué casos conviene usarlo en vez de otra tool parecida. El propio blog de ingeniería de Anthropic sobre cómo escribir tools para agentes lo plantea así: el nombre, la descripción y el formato de respuesta de una tool se convierten en el lenguaje con el que el agente piensa. Si ese lenguaje es ambiguo, el agente elige mal, llama a la tool equivocada, o directamente no hace nada porque no entendió para qué servía cada opción.

¿Qué 8 criterios se usaron para evaluar los servidores MCP de los 13 sistemas?

La investigación armó 8 criterios combinando el blog de ingeniería de Anthropic con la guía oficial de seguridad de MCP, y le dio un punto a cada sistema por cada criterio cumplido (medio punto si la evidencia era parcial o no verificable).

• Pocas herramientas bien enfocadas: conviene agrupar pasos que se usan juntos seguido en una sola tool, en vez de envolver cada endpoint de la API por separado.
• Nombres con orden y prefijo: un prefijo que indique de qué servicio se trata ayuda al agente a elegir bien cuando tiene cientos de tools disponibles de distintos proveedores.
• Datos legibles, no códigos: devolver el nombre de un producto o de una página es mejor que devolver un UUID que el agente tiene que volver a consultar.
• Ahorro de tokens: paginación, filtros y valores por defecto que no traigan todo el bloque de datos de una.
• Descripciones pensadas para IA: que digan cuándo usar la tool y cuándo no.
• Lectura separada de escritura: el borrado de datos necesita una barrera clara, distinta de las operaciones de consulta.
• Mínimo privilegio: permisos acotados a un sitio o entorno específico, no la llave completa de la cuenta.
• Documentación con ejemplos: manuales específicos para MCP, no la documentación genérica de la API reciclada.

El campo de juego quedó armado con cinco builders de sitios (Wix, WordPress.com, Duda, Webflow y Squarespace) y siete CMS (Contentful, Storyblok, Sanity, Strapi, Directus, Payload y Drupal). Framer quedó afuera del puntaje porque no implementa MCP, usa su propio sistema de Agente Externo. Ghost tampoco entró porque todavía no tiene un servidor MCP oficial. Tema relacionado: las diferencias entre API y MCP.

¿Qué plataformas sacaron el puntaje más alto en diseño de herramientas MCP?

WordPress.com y Storyblok empataron en el primer puesto con 8 sobre 8, pero llegaron ahí con arquitecturas casi opuestas entre sí.

WordPress.com apuesta por la concentración total. En vez de exponer más de 60 operaciones como 60 herramientas separadas, según su documentación oficial de tools MCP junta todo en una sola tool llamada wpcom-mcp-content-authoring, que trabaja en tres pasos: list para ver qué operaciones existen, describe para conocer el esquema de datos de esa operación, y execute para correrla de verdad (por ejemplo, posts.create o pages.update). Lo que le suma puntos extra es el protocolo de seguridad: toda operación de escritura o borrado necesita el parámetro user_confirmed: true, y los borrados permanentes de categorías o tags piden esa misma confirmación porque no tienen papelera de reciclaje.

Storyblok va por el camino contrario: en vez de envolver los cerca de 160 endpoints de su Management API uno por uno, según su documentación del servidor MCP expone apenas 7 tools. El agente primero llama a search para encontrar la operación que necesita, después a describe para conocer los parámetros, y recién ahí ejecuta a través de tres puertas separadas según el nivel de riesgo: execute_readonly para lectura, execute_mutating para crear o modificar, y execute_destructive para borrar (esta última exige confirmación explícita del usuario en cada llamada). Esa separación en tres puertas no es estética: un administrador puede conectar un agente solo a la puerta de lectura sin escribir una sola regla adicional, porque el rol del usuario queda fijado en la URL de conexión y el agente no tiene forma de subirse el propio permiso.

¿Cuáles son las 4 arquitecturas distintas de diseño de tools que aparecieron en la investigación?

La investigación identificó cuatro enfoques claramente distintos entre los 13 sistemas analizados: todo junto en una tool, buscar antes de ejecutar, forzar la lectura de documentación antes de llamar a la API, y envolver cada endpoint uno por uno.

Todo en una sola herramienta: el caso WordPress.com

Ya lo vimos arriba: una tool, tres verbos (list, describe, execute), confirmación obligatoria para escribir o borrar. Este enfoque mantiene el catálogo de tools chico sin sacrificar cobertura funcional.

Buscar antes de ejecutar: el caso Storyblok

Storyblok describe resultados, no endpoints. En vez de decirle al agente “llamá a POST /v2/spaces/id/stories”, el agente busca la operación por palabra clave y el servidor la resuelve. Esto reduce drásticamente el tamaño del system prompt que necesita el agente para operar. Más contexto en cómo GitHub reescribe agentes de IA en Rust.

Forzar la lectura de documentación antes de llamar a la API: el caso Wix

Wix eligió un ángulo distinto. De sus 12 tools, 6 sirven exclusivamente para buscar documentación propia (manuales REST, manuales SDK, esquemas de métodos), y la puerta real hacia la API es una sola: CallWixSiteAPI, según el repositorio de Wix MCP en GitHub. La idea es obligar al agente a leer antes de ejecutar, para reducir la chance de que invente un esquema de datos que no existe. Funciona bien contra la alucinación, pero la descripción de la tool principal es tan corta (“Perform an action or query”) que no ayuda al agente a decidir cuándo usarla. Y dividir la búsqueda de documentación en 6 tools por tipo de documento es un fraccionamiento que perfectamente podría ser una sola herramienta.

Envolver cada endpoint uno por uno: los casos Duda y Contentful

Duda es el ejemplo más claro de lo que Anthropic desaconseja en su guía: 54 tools armadas una por cada endpoint, sin prefijo de servicio en los nombres (hay más de diez tools que arrancan con create_ sin distinción clara), y descripciones de una sola línea, según el manual de referencia del servidor MCP de Duda. Contentful sigue la misma lógica de fraccionamiento con más de 40 tools, pero se gana un punto a favor: según su repositorio en GitHub, tiene la variable PROTECTED_ENVIRONMENTS, que bloquea escritura y borrado en entornos críticos como producción. Es una protección a nivel de infraestructura completa, no una barrera aislada por tool.

¿Cuál es el ranking completo y qué sistema quedó peor evaluado?

Duda sacó 2 sobre 8, el puntaje más bajo de los 13 sistemas evaluados. El motivo central: tiene una tool delete_account sin ningún paso de confirmación documentado, sumado a nombres sin prefijo y descripciones de una línea que no orientan al agente sobre cuándo usar cada operación.

Sistema	Puntaje	Punto más fuerte
WordPress.com	8/8	Una tool para 60+ operaciones + confirmación obligatoria en cada escritura
Storyblok	8/8	7 tools en vez de 160 endpoints + tres puertas según riesgo
Sanity	7.5/8	Descripciones que enseñan al agente cómo usar la tool
Webflow	7/8	Agrupa varias acciones por recurso + separa Data de Designer
Squarespace*	7/8	Buen diseño, pero solo 2 tools de dominios en estado preview
Strapi	7/8	Las tools sin permiso ni siquiera se muestran al agente
Directus	7/8	Se pueden desactivar tools no usadas por deployment
Contentful	6.5/8	Bloqueo estructural de escritura en producción
Payload	6.5/8	Genera tools automáticamente según cada colección
Wix	6/8	Fuerza la lectura de documentación antes de ejecutar
Drupal	6/8	Arquitectura de plugins flexible
Duda	2/8	Cobertura amplia, pero casi sin barreras de seguridad

¿Cuáles son los errores más comunes que se repiten en casi todos los sistemas evaluados?

Cuatro fallas se repiten en la mayoría de los 13 sistemas, más allá de sus diferencias de arquitectura.

• Descripciones de una sola línea: la mitad del campo evaluado escribe descripciones tan cortas que el agente no tiene forma de saber cuándo conviene usar esa tool, a pesar de que la guía de Anthropic insiste específicamente en este punto.
• Permisos más amplios de lo necesario: varios sistemas siguen usando tokens con acceso a la cuenta completa, en contra del principio de mínimo privilegio que la propia guía de seguridad de MCP recomienda.
• Borrado sin ninguna barrera: salvo dos o tres excepciones (WordPress.com, Storyblok), la mayoría permite borrar datos de forma permanente sin ningún paso de confirmación, justo en el punto donde el daño no tiene vuelta atrás.
• Formato de respuesta sin documentar: muchos sistemas no explican qué forma tiene el dato que devuelve cada tool, lo que hace imposible evaluar si esa respuesta es legible para un agente o no.

Acá viene lo interesante para cualquiera que esté por diseñar sus propias tools: los errores no son de falta de funcionalidad. Duda, por ejemplo, cubre prácticamente toda su API. El problema es que cubrir todo sin pensar en cómo lo consume un agente termina generando el riesgo opuesto al que se buscaba resolver.

¿Qué está confirmado y qué queda pendiente de esta evaluación?

Lo confirmado es la evaluación misma: los puntajes se basan en documentación oficial y código fuente abierto, disponibles públicamente hasta septiembre de 2026, según reconoce el propio artículo original. Lo que no está confirmado es el comportamiento real de cada tool en producción, porque la investigación no ejecutó cada operación de forma práctica. Complementá con comparativa completa entre Claude y Gemini 2.5.

• Confirmado: los 8 criterios de evaluación y su origen (blog de ingeniería de Anthropic + guía oficial de seguridad de MCP).
• Confirmado: el puntaje de 8/8 para WordPress.com y Storyblok, y de 2/8 para Duda, basado en documentación pública.
• Pendiente de verificación: el formato exacto de las respuestas de cada tool en uso real, porque no se probaron todas las llamadas en producción.
• Pendiente: MCP cambia mes a mes en varios de estos proveedores, en particular Duda sigue marcado como beta, así que este ranking es una foto de un momento puntual, no un veredicto definitivo.

¿Qué preguntas conviene hacerle a un proveedor de CMS antes de conectar un agente de IA?

Dos preguntas concretas alcanzan para filtrar bastante: cuántas tools ve el agente cuando se conecta, y cuántas capas de confirmación tiene el borrado de datos. Si el equipo de ventas de la plataforma no puede responder eso con precisión, probablemente tampoco lo sepan sus propios ingenieros.

Como criterio práctico, antes de dejar que un agente opere sobre un sitio en producción conviene probarlo primero contra un entorno de staging, pedirle que liste las tools disponibles y revisar manualmente cuáles permiten borrar o modificar datos sin pasos intermedios. Es una verificación que cualquier equipo técnico puede hacer en una tarde, sin depender de lo que diga el marketing del proveedor. Si estás evaluando dónde alojar un proyecto que va a integrar agentes de IA vía MCP, en Argentina donweb.com es una opción de hosting a tener en cuenta para la infraestructura de base, más allá de qué CMS elijas para la capa de contenido.

Errores comunes al evaluar un servidor MCP antes de conectarlo

Elegir un CMS con MCP sin revisar el diseño real de las tools es de los errores más frecuentes, y también de los más evitables.

• Asumir que “tiene MCP” ya es garantía de seguridad: tener el protocolo implementado no dice nada sobre si el borrado tiene confirmación o no. Duda tiene MCP funcional y sacó 2/8 igual.
• Conectar el agente con un token de cuenta completa “para no complicarse”: la corrección es pedir el token más acotado posible, limitado a un sitio o entorno específico, tal como recomienda la guía de seguridad de MCP.
• No leer la descripción de cada tool antes de habilitarla: si la descripción no dice cuándo usar la tool y cuándo no, el agente va a interpretar libremente, y ese margen de interpretación es justamente donde ocurren los errores.
• Dejar el agente conectado en producción sin pasar antes por staging: probar primero en un entorno de desarrollo, como recomienda la propia documentación de Storyblok, evita que un error de interpretación del agente termine borrando contenido real.

Preguntas Frecuentes

¿Qué es el Model Context Protocol (MCP) de Anthropic?

MCP es un estándar abierto que Anthropic desarrolló para que los agentes de IA se comuniquen con software externo usando el mismo lenguaje, sin que cada plataforma tenga que programar una integración distinta para cada modelo de IA. Los desarrolladores escriben un conjunto de “herramientas” según la especificación de MCP y cualquier agente compatible puede usarlas directamente.

¿Qué diferencia hay entre una API tradicional y una herramienta MCP?

Una API se llama según una especificación fija que un programador define de antemano. Una herramienta MCP la elige el propio agente de IA en el momento, basándose en el nombre, la descripción y los resultados que devolvió antes, por lo que su diseño tiene que pensarse para que una IA la entienda, no solo un desarrollador. Cubrimos ese tema en detalle en cómo se compara Claude frente a GPT-4o.

¿Qué CMS tiene la mejor implementación de MCP según esta evaluación?

WordPress.com y Storyblok empataron con el puntaje máximo de 8 sobre 8 en la investigación, cada uno con un enfoque distinto: WordPress.com concentra todo en una tool con confirmación obligatoria para escribir o borrar, y Storyblok separa el acceso en tres puertas según el nivel de riesgo de cada operación.

¿Por qué es peligroso que un agente de IA tenga demasiadas tools MCP sin restricciones?

Porque un agente con acceso a decenas de tools sin distinción de riesgo puede confundir una operación de borrado permanente con una de simple consulta, sobre todo si las descripciones son cortas y no indican cuándo usar cada una. El caso de Duda, con una tool de borrado de cuenta sin confirmación documentada, es el ejemplo más claro de este riesgo.

¿Cómo se evita que un agente de IA borre datos sin confirmación?

Exigiendo un parámetro explícito de confirmación del usuario antes de ejecutar cualquier borrado, como hace WordPress.com con user_confirmed: true, o separando las operaciones destructivas en una puerta de acceso distinta que requiera aprobación manual, como hace Storyblok con execute_destructive.

Conclusión

El diseño de herramientas MCP dejó de ser un detalle técnico menor para convertirse en la línea que separa un agente útil de un agente peligroso. Los 13 sistemas evaluados muestran que no hace falta elegir entre cobertura funcional y seguridad: WordPress.com cubre más de 60 operaciones con una sola tool y confirmación obligatoria, Storyblok resuelve 160 endpoints con apenas 7 tools separadas por riesgo. El tema es que ninguno de los dos llegó ahí por casualidad, sino por diseñar pensando en cómo razona un agente, no en cómo se organiza una API tradicional.

Si estás evaluando qué plataforma usar para conectar IA a tu sitio, el ranking de esta investigación da un punto de partida concreto, pero la recomendación práctica es simple: preguntá cuántas tools ve el agente y cuántas capas de confirmación tiene el borrado antes de conectar nada a producción.

Fuentes

• MCP en 13 sistemas de sitios web: investigación comparativa de diseño de tools
• Anthropic – Writing effective tools for agents
• MCP – Guía oficial de mejores prácticas de seguridad
• WordPress.com – Referencia de tools MCP
• Storyblok – Documentación del servidor MCP