Por que un servidor MCP en tu plugin de WordPress es la jugada de IA que sobrevive

#Por que un servidor MCP en tu plugin de WordPress es la jugada de IA que sobrevive

Dos puntos de datos de una sola semana, mayo de 2026.

Bryce Adams, fundador de Metorik, en WP Product Talk: la nueva integración MCP de la empresa atrajo a 500 usuarios en pocos días tras un lanzamiento discreto en preview, la adopción más rápida de una funcionalidad en su experiencia de diez años. Misma conversación, mismo Adams: los clientes que se van de Metorik tienen un MRR promedio 40 por ciento inferior a los que se quedan. Lo leyó como la IA tomando los casos de uso commodity (reportes básicos, dashboards simples) y dejando en paz el trabajo analítico central.

GravityKit publico esta semana Block MCP como open-source. Es un servidor MCP de WordPress que opera a nivel de bloque, en lugar de tratar el contenido del post como una unica cadena HTML. El equipo lo construyo porque los servidores MCP existentes basados en la REST API eliminan los delimitadores de bloque que WordPress usa para identificar bloques, colapsando el contenido estructurado en un bloque Classic. Chocaron con el bug suficientes veces en su propio sitio como para comprometerse con una correccion.

No son dos historias. Es una historia. En 2026, el plugin de WordPress que envia un servidor MCP es el plugin que compone. El plugin que pega una chatbox en su administracion es el plugin que es canibalizado.

Este texto es la continuacion de nuestro pilar de implementación de IA y conecta directamente con nuestro trabajo de desarrollo de servidores MCP y con la historia de integracion de la Abilities API en WordPress 7.0. El argumento aqui es comercial, no solo tecnico.

#TL;DR

• Dos puntos de datos de mayo de 2026 dicen lo mismo. Metorik MCP: 500 usuarios en días, adopción mas rapida en diez años. Adams: MRR de los que se van 40 por ciento inferior a los retenidos, sugiriendo que la IA toma casos commodity. GravityKit Block MCP: open-source, corrige el bug de eliminacion de delimitadores de bloque vía REST API.
• Un servidor MCP expone las operaciones de dominio del plugin como tools invocables por el agente elegido por el usuario. Una chatbox atrapada en la administracion solo compone consigo misma.
• La capa commodity (reportes, dashboards, variantes de graficos) es canibalizada por herramientas de IA genericas. La capa profunda de dominio (atribucion personalizada, matematica de cohortes, plumbing de integracion) sobrevive porque la IA no tiene el contexto de dominio a menos que el plugin se lo de vía MCP.
• El contrato del servidor MCP vive en el repositorio del plugin y es estable a traves de las versiones de modelos. Una chatbox entrenada contra un proveedor especifico cambia bajo el mantenedor cada seis semanas.
• Accion: envia un servidor MCP, expon de tres a siete operaciones de dominio como tools, documenta el contrato en el repositorio, versiona la superficie MCP por separado de la UI.

#El experimento natural que condujo Adams

Adams dijo en WP Product Talk que estaba nervioso con la IA por la misma razon por la que cualquier autor de plugin lo esta en 2026: el fondo de la piramide de valor (reportes básicos, agregaciones simples) es donde la IA es mas rapida copiando. Podia imaginar un mundo donde Claude o ChatGPT, apuntados a los mismos datos en bruto de Shopify o WooCommerce, produzcan los mismos graficos que Metorik, gratis.

Lo que encontro, despues de un ano observando, fue que los clientes que abandonaban Metorik eran sistematicamente los de bajo MRR. MRR promedio de los que se van 40 por ciento por debajo de los retenidos. Su interpretacion: la IA hizo exactamente lo que el temia en el fondo de la piramide, y nada en la cima.

Esto es un experimento natural porque Adams no lo diseno. Le ocurrio mientras el mercado se desplazaba. Los datos dicen que funciones son commodity (se fueron a la IA) y cuales son duraderas (Metorik retiene al cliente). Adams listo los casos de uso de clientes retenidos como: atribucion del gasto publicitario, matematica de cohortes, segmentacion personalizada, integracion con APIs de stock y fulfilment, agregacion multitienda. No son funciones de grafico. Son operaciones de dominio que requieren la implementación especifica de Metorik, contra la forma de datos que el producto se ha ganado a lo largo de una decada.

El paralelo para el lector espanol es directo. La escena de agencias WordPress en Espana ha crecido en torno a la integracion con SaaS B2B local: Holded, Factorial, Quipu y la facturacion electronica VeriFactu que la AEAT impone para 2026. Cuando un cliente B2B espanol pide una tienda WooCommerce con facturacion VeriFactu, el problema no esta en el plugin de facturacion sino en como compone con el agente interno del cliente que ya conversa con Claude o Copilot. Sin un servidor MCP en el plugin VeriFactu, el camino directo entre el agente y la AEAT queda bloqueado por mas middleware. Con un servidor MCP, el plugin pasa a ser canalizacion indispensable en lugar de una caja de chat que nadie usa.

Despues llego la integración MCP, y 500 clientes retenidos la tomaron en la primera semana.

La integración MCP no es una nueva funcionalidad del producto. Es una forma de que el agente del cliente (Claude Desktop, Claude Code, ChatGPT Enterprise, una stack interna personalizada) llame a esas mismas operaciones de dominio de los clientes retenidos como tools. El cliente hace ahora en su agente lo que solia hacer iniciando sesion en Metorik. Metorik no los perdio, se volvio canalizacion invisible bajo el workflow del agente.

Eso es el foso.

#Por que Block MCP importa mas de lo que su forma de plugin sugiere

Block MCP de GravityKit es tecnicamente un plugin pequeno. Un servidor MCP de WordPress que expone edicion a nivel de bloque como tools. Importa porque identifica el modo de fallo de todo intento previo de MCP en WordPress.

Los servidores MCP existentes de WordPress (hay varios) escriben a traves de la REST API, que trata content como una unica cadena HTML. WordPress usa internamente comentarios HTML como delimitadores de bloque (<!-- wp:paragraph -->, <!-- wp:image {...} -->). Cuando el agente edita la cadena y la escribe de vuelta, los comentarios solo sobreviven si el agente sabe de ellos. La mayoria no. La ida y vuelta del HTML elimina los delimitadores. El post que era una stack de veinte bloques se convierte en un unico bloque Classic al guardar.

No es hipotetico. El strategic ops manager de GravityKit, Casey Burridge, dijo que el equipo choco con el bug repetidamente en su propio sitio. Cualquiera que haya intentado construir un agente de edicion de contenido contra la REST API ha chocado con el.

Block MCP arregla el fallo exponiendo operaciones a nivel de bloque como tools MCP. add_block, update_block, move_block, delete_block, en lugar de get_content mas set_content. El agente ve el post como un arbol, no como una cadena. El contrato es estable a traves de las actualizaciones de bloques de WordPress, porque se define en el servidor MCP, no en el serializador HTML que el core envie hoy.

El punto mas profundo: la diferencia entre “MCP envuelto en REST” y “MCP disenado en torno al dominio” es la diferencia entre herramienta commodity y superficie duradera. Block MCP es el primer servidor MCP de WordPress que opera en la capa de dominio (los bloques son el primitivo de dominio del contenido de WordPress), no en la capa de transporte de la API.

Cada autor de plugin deberia preguntar: cual es el primitivo de dominio de mi plugin, y mi servidor MCP lo expone, o expone un endpoint REST envuelto?

#Que es un servidor MCP, en dos parrafos

El Model Context Protocol es un estandar abierto de Anthropic para como los agentes de IA descubren y llaman tools. Un servidor MCP expone una lista de tools (cada una con un nombre, una descripcion, una JSON schema para inputs y una implementacion), y cualquier agente capaz de MCP (Claude Desktop, Claude Code, ChatGPT Enterprise, stacks personalizadas) puede conectarse, descubrir las tools y llamarlas. El servidor puede ser local (stdio) o remoto (SSE / HTTP). Para un plugin WordPress, el caso local es la forma correcta: el servidor corre junto al plugin, el agente se conecta desde la maquina del usuario.

El autor del plugin define las tools. Ese es todo el punto. Las tools son las operaciones de dominio del plugin, nombradas en el vocabulario del plugin, con schemas de input que reflejan el modelo de datos del plugin. El agente opera ahora al nivel de conocimiento de dominio del plugin. El cliente hace en el chat lo que solia hacer haciendo clic en cinco pantallas de administracion.

En nuestro tech radar, el Anthropic Model Context Protocol esta en el anillo Adopt, WordPress Abilities API en Trial (la superficie canonica de integracion en WordPress 7.0 y posteriores), y recientemente anadimos wp-agentic-admin (CloudFest Hackathon 2026) en Assess como implementación de referencia del patron.

#La matriz dos por dos

El plugin WordPress de 2026 vive en una matriz dos por dos:

El cuadrante de dominio superficial (fila de arriba) es donde se sienta la mayoria de los lanzamientos de “plugin de IA WordPress”. Envuelven una capa fina de funcionalidad basica (exportacion CSV, graficos simples, sugerencias de reescritura de contenido) y o bien anaden una chatbox o no tienen MCP en absoluto. Ambas columnas son callejones sin salida.

El cuadrante de dominio profundo (fila de abajo) es donde viven los plugins duraderos. Metorik, JetEngine de Crocoblock, GravityForms, GravityView de GravityKit. Sin MCP, estos plugins retienen clientes pero se vuelven invisibles a los workflows de agentes. Con MCP, se componen en workflows de agentes y se convierten en canalizacion indispensable.

La pregunta interesante para un autor de plugin en este cuadrante no es “deberiamos enviar MCP” (si), es “cuales son las tres a siete operaciones correctas a exponer”.

#Elegir las operaciones a exponer

Los autores de plugins a menudo quieren exponer cada endpoint CRUD como tools MCP. Esto es erroneo. El punto de MCP no es acceso a API, son operaciones a nivel de dominio. Una lista larga de tools triviales confunde al agente y produce llamadas de baja calidad. Una lista corta de operaciones significativas hace al agente útil.

La heuristica que usamos:

1. Lista las acciones que un cliente toma en tu plugin en una semana tipica. Ordena por frecuencia.
2. Agrupalas en clusters de acciones relacionadas. Para Metorik, un cluster podria ser “consultas de atribucion publicitaria”, otro “segmentacion de cohortes”.
3. Para cada cluster, define una unica tool MCP que toma los parametros del cluster y devuelve el resultado. La tool es la operacion de dominio, no el endpoint API.
4. Limita la lista a siete. Si tienes mas de siete, no has terminado el clustering.
5. Cada tool obtiene una descripcion de un parrafo en el servidor MCP. La descripcion es lo que el agente lee para decidir cuando usarla. Optimiza para la lectura del agente, no para la completitud de la documentacion humana.

Quien siga esto obtiene una superficie MCP con cinco a siete tools, cada una relevante para el cliente retenido. El agente lee y elige correctamente. El workflow diario del cliente incluye ahora las operaciones de dominio del plugin como solicitudes en lenguaje natural.

#El contrato vive en el repositorio

Esta es la parte del argumento que la mayoria de los autores de plugins pasa por alto cuando alcanza primero por “anadamos Claude a nuestra administracion”.

Una chatbox pegada a la administracion del plugin tiene un contrato que vive en el prompt, mensaje de sistema y capa de llamada de tools de la chatbox. Cuando el proveedor de modelo subyacente cambia el formato de function-calling (esto ha ocurrido tres veces en los ultimos 18 meses en Anthropic, OpenAI y Google), la chatbox se rompe hasta que el mantenedor actualiza el wrapper. Su ciclo de vida es la API del proveedor de modelo.

El contrato de un servidor MCP vive en el repositorio del plugin como una JSON schema por tool. Es estable a traves de las versiones de modelos. Cuando Anthropic actualiza el tool-calling de Claude, el agente se actualiza, no el servidor MCP. Cuando OpenAI envia una nueva forma de function-calling, el mismo servidor MCP sigue funcionando, porque MCP es el estandar al que el proveedor de modelo se adapta. El autor del plugin escribe las tools una vez y las envia.

Esta es la forma de ingenieria duradera. La chatbox es la desechable. El cliente lo nota en un horizonte de varios anos: la chatbox de 2025 se rompio dos veces en 2026, el servidor MCP de 2025 sigue funcionando con el agente actual del cliente.

#Contraposicion: y wp-agentic-admin?

Un lector que mire el proyecto CloudFest Hackathon 2026 wp-agentic-admin vera un modelo distinto: un WebLLM en el navegador (Qwen 1.7B o 7B via WebGPU) corriendo enteramente en el dispositivo del usuario, llamando a la WordPress Abilities API a traves de un loop ReAct. Local-first, sin coste de API, sin modelo remoto.

Ese modelo tiene su lugar. Es buena correspondencia para el administrador WordPress single-tenant o paranoico con la privacidad que quiere triar su propio sitio sin dependencia externa. No es la respuesta duradera para equipos B2B que ya corren Claude Enterprise, ChatGPT Enterprise o stacks de agentes self-hosted en todos sus workflows internos.

Para esos equipos, el agente con el que quieren hablar al plugin WordPress es el mismo que usan para su CRM, su data warehouse, su issue tracker y su documentacion. El servidor MCP es lo que hace al plugin disponible para ese agente. Ambos modelos son validos, pero el patron MCP es el que se alinea con como los equipos B2B ya trabajan.

#Que significa esto para el lector de wppoland

Si envias un plugin WordPress o WooCommerce: construye el servidor MCP. Tres a siete operaciones de dominio, expuestas como tools, contrato en el repositorio, versionado por separado de la versión de UI. Haz esto antes de anadir una chatbox. Si solo puedes hacer una cosa, haz el servidor MCP.

Si operas un sitio WordPress a escala (multi-site, agencia, enterprise): cuando evalues plugins, pregunta “envia un servidor MCP” como solias preguntar “tiene REST API”. La pregunta MCP es el equivalente de 2026.

Si eres cliente de wppoland evaluando donde invertir esfuerzo de ingenieria en 2026: aqui sugerimos invertir. Construimos Claude skills y servidores MCP a medida para equipos B2B que corren workflows agent-first sobre WordPress. El entregable es el servidor MCP, las tools de dominio, el contrato y el onboarding del equipo. El entregable no es una chatbox.

#Argumento de cierre

El punto de datos de Metorik de mayo de 2026 y el lanzamiento open-source de Block MCP son la misma senal a escalas distintas. El plugin que expone sus operaciones de dominio como tools MCP compone con el agente que su cliente adopte. El que no lo hace es canibalizado en la capa commodity y queda invisible en la capa de dominio.

Hay una pequena ventana operativa en 2026 para enviar MCP antes de que el mercado espere que cada plugin lo tenga. Los autores que alcancen la superficie MCP este ano estaran en la allow-list del integrador de agentes cuando el mercado les de alcance.

#Fuentes

• Bryce Adams en WP Product Talk (transcripcion via WP Product Talk)
• Documentacion de la integración MCP de Metorik
• Lanzamiento open-source de GravityKit Block MCP
• Anthropic Model Context Protocol
• Retrospectiva de 8 anos de JetEngine de Crocoblock y MCP Command Center

#Relacionados en nuestro sitio

• Pilar: Consultoria de implementación de IA
• Desarrollo de servidores MCP
• WordPress 7.0 features: infraestructura de IA y resumen de Abilities API
• Tech Radar: Anthropic MCP (Adopt)
• Tech Radar: WordPress Abilities API (Trial)
• Tech Radar: wp-agentic-admin (Assess)

Ultima verificacion: 2026-05-23