MCP vs REST: cuándo gana cada uno en la integración de agentes de IA
Tratar MCP y REST como alternativas es plantearlo mal. Están en capas distintas: REST es transporte más convenciones, MCP es un protocolo tipado diseñado para un consumidor LLM. La decisión real es con qué superficie habla cada consumidor y cómo comparten las dos superficies un mismo backend. Este artículo recoge el marco que uso al definir el alcance de integraciones de IA en proyectos WordPress y WooCommerce.
Este artículo forma parte del pilar desarrollo de servidores MCP.
En resumen
- MCP y REST se complementan, no son alternativas.
- REST gana con clientes deterministas, con un conjunto de acciones fijo y documentación OpenAPI.
- MCP gana con agentes LLM que necesitan descubrir herramientas en tiempo de ejecución y sobres tipados para acciones que modifican datos.
- La configuración por defecto en producción es REST como system of record y MCP como superficie para agentes delante.
- El mismo backend, dos superficies, una única fuente de verdad.
Qué es MCP y qué es una API REST
REST. Un estilo arquitectónico de la tesis doctoral de Roy Fielding de 2000 (la fuente de la tesis), que normalmente se expresa sobre HTTP con verbos y URLs de recursos. WordPress expone una API REST en /wp-json/wp/v2/ (manual de la API REST de WordPress); WooCommerce la amplía en /wp-json/wc/v3/. La documentación suele ser OpenAPI (especificación OpenAPI) y los SDKs se generan a partir del esquema en tiempo de build.
MCP. Un protocolo basado en JSON-RPC 2.0 que Anthropic anunció el 25 de noviembre de 2024 (anuncio de Anthropic) para conectar hosts LLM (Claude Desktop, IDEs, entornos de agentes propios) con datos y herramientas. Tres primitivas: tools (funciones invocables), resources (documentos de solo lectura), prompts (plantillas que proporciona el servidor). El descubrimiento ocurre en tiempo de ejecución mediante tools/list; el agente aprende las capacidades disponibles en cada sesión.
De lejos, las formas parecen similares. Bajo carga, se separan enseguida.
Matriz de decisión entre MCP y API REST
Seis factores que valoro antes de elegir la superficie para una acción concreta:
| Factor | Favorece REST | Favorece MCP |
|---|---|---|
| Tipo de consumidor | Cliente web o de socio determinista | Agente LLM |
| Descubrimiento de capacidades | En compilación vía OpenAPI | En ejecución vía tools/list |
| Forma de la acción | Fija, bien conocida | Intención libre |
| Seguridad de las modificaciones | Basada en convenciones | Sobre tipado + idempotencia integrada |
| Autenticación | Tokens bearer, OAuth | Lo mismo, más scopes asignados por herramienta |
| Caché | Cabeceras de caché HTTP | Fuera de banda, a nivel de aplicación |
La matriz me dice qué protocolo es preferible para una acción, no para toda la API. La mayoría de los proyectos acaban divididos.
Cuándo usar una API REST en lugar de MCP
Una tienda online que obtiene una página de categoría. Programada contra /wp-json/wp/v2/categories?slug=widgets. La forma es conocida, las cabeceras de caché hacen su trabajo y la CDN puede cachear por URL.
La integración ERP de un socio que sincroniza el inventario a diario. El equipo del socio lee el OpenAPI, genera un SDK tipado y programa un cron a las 03:00 UTC. Quiere URLs estables, formas de respuesta predecibles y códigos de estado HTTP. MCP añadiría complejidad sin aportar valor.
Tráfico público y anónimo de lectura. Un crawler de SEO que recorre fichas de producto, un comparador de precios que descarga feeds de productos. REST con rate limiting cubre este caso con la infraestructura más madura que existe.
Entrega de webhooks. WooCommerce envía woocommerce_order_status_completed a un endpoint del socio. Ese endpoint es un receptor REST. MCP es la forma equivocada, porque el agente no participa en el ciclo; el receptor es un sistema determinista.
Cuándo usar MCP en lugar de REST
Un agente LLM que actúa según la intención libre del usuario. “Búscame una chaqueta impermeable de menos de 200 euros que se envíe a Madrid.” El agente no sabe de antemano qué combinación de filtros aplicar; tiene que examinar las herramientas disponibles, leer las descripciones y decidir. REST le ofrece 47 parámetros de query repartidos en tres endpoints y ninguna pista sobre cuáles usar.
Acciones que modifican datos en las que importa la idempotencia. Crear un pedido desde un LLM es el ejemplo más claro. La herramienta MCP order.intent, con un esquema de entrada tipado y una clave de idempotencia, es un contrato más estricto que una llamada libre a POST /wp-json/wc/v3/orders. Los reintentos son seguros por diseño, no por convención.
Una superficie de herramientas que cambia a menudo. Añadir un nuevo filtro de búsqueda o un nuevo tipo de producto significa publicar una nueva herramienta MCP con un bloque describe; el agente la detecta en el siguiente tools/list sin cambios de código en su lado. Con REST, cada cambio es una versión coordinada del SDK.
Flujos de agente en varios pasos. “Comprueba si el SKU AC-101 está en stock; si no lo está, sugiere tres alternativas; si lo está, propón un pedido.” Cada paso es una llamada a una herramienta y el agente las combina. Con REST, el agente tiene que fijar la forma del flujo en su prompt.
MCP y REST en una tienda WooCommerce
En un proyecto WooCommerce típico, trazo la frontera así:
| Acción | Consumidor | Superficie |
|---|---|---|
| Navegación pública por el catálogo | Cliente web, crawlers | REST |
| Renderizado de la ficha de producto | Cliente web | REST |
| Sincronización de inventario (B2B) | ERP del socio | REST + OpenAPI |
| Entrega de webhooks | Endpoints de socios | REST |
| Agente: buscar producto | LLM | MCP |
| Agente: consultar estado del pedido | LLM | MCP |
| Agente: proponer pedido | LLM | MCP |
| Agente: cancelar pedido | LLM | MCP |
| Operaciones de administración | Admin de WordPress | REST + autenticación por cookie |
Los handlers de las herramientas del servidor MCP llaman a los mismos endpoints /wp-json/wc/v3/ que usan los consumidores REST. Una única fuente de verdad para la capa de datos, dos superficies para dos tipos de consumidor.
Autenticación y scopes OAuth en MCP y REST
La autenticación en REST es terreno muy trillado: tokens bearer, OAuth 2.x, basic auth en desarrollo. La convención es “quien tiene el token puede hacer todo lo que dice la documentación.” El ajuste fino de los scopes se hace por endpoint, a nivel de aplicación.
MCP recurre a las mismas opciones de la capa de transporte, pero el SDK anima a asignar scopes por herramienta. Un solo token OAuth puede llevar orders:read sin orders:write, y el servidor MCP lo hace cumplir en cada llamada a una herramienta. Los patrones OpenAPI admiten la misma idea mediante securityDefinitions y seguridad por operación, pero en la práctica la mayoría de las APIs REST documentan un único scope global y dejan que la aplicación resuelva la granularidad más fina.
En las integraciones con agentes en concreto, el mapeo de scopes por herramienta de MCP es una ventaja ergonómica real, que además encaja con el requisito de minimización de datos del RGPD. El usuario concede orders:read al agente; el agente literalmente no puede llamar a order.cancel, porque el servidor MCP rechaza la llamada con forbidden antes de que se ejecute el handler. Por debajo, la autenticación es la misma que en REST, pero el contrato resulta más legible tanto para el usuario como para el agente.
¿En qué se diferencia la caché de respuestas MCP de la caché HTTP de REST?
REST cuenta con décadas de infraestructura de caché HTTP: cabeceras Cache-Control, revalidación con ETag, reglas Vary, caché en el borde de la CDN, caché del navegador y de proxies intermedios. Una respuesta a GET /wp-json/wc/v3/products?stock_status=instock con Cache-Control: public, max-age=60 se cachea en el borde sin esfuerzo adicional.
MCP no tiene nada de esto. Las respuestas de las herramientas viajan como payloads JSON-RPC dentro de peticiones POST. Las cabeceras de caché HTTP no se aplican. La caché tiene que hacerse a nivel de aplicación, dentro del handler de la herramienta, con una clave explícita derivada de la entrada. Esto funciona bien cuando los propios handlers del servidor MCP cachean la llamada REST de origen (es lo que hago en producción), pero significa que la capa de caché es un problema que le toca diseñar a usted.
Este es el argumento más sólido para mantener el tráfico público de lectura en REST y dirigir solo el tráfico de agentes a través de MCP. La infraestructura de caché HTTP es demasiado valiosa como para renunciar a ella en la superficie pública.
Cómo combinar MCP y REST en un único backend WordPress
La arquitectura por defecto que entrego para sitios WordPress y WooCommerce con ambiciones de agentes de IA:
┌──────────────────┐
│ WordPress core │
│ + WooCommerce │
│ (REST origin) │
└────────┬─────────┘
│
┌────────────────┼────────────────┐
│ │ │
┌───────▼────────┐ ┌────▼─────┐ ┌──────▼──────┐
│ Public REST │ │ Webhook │ │ MCP server │
│ (cache at CDN) │ │ delivery │ │ (Workers) │
└───────┬────────┘ └────┬─────┘ └──────┬──────┘
│ │ │
┌───────▼────────┐ ┌────▼─────┐ ┌──────▼──────┐
│ Storefront, │ │ Partner │ │ LLM agent │
│ price feeds, │ │ endpoints│ │ (Claude, │
│ public APIs │ │ │ │ ChatGPT, │
│ │ │ │ │ custom) │
└────────────────┘ └──────────┘ └─────────────┘El mismo origen WordPress. Tres superficies, tres perfiles de consumidor. Los handlers del servidor MCP llaman a los mismos endpoints REST que cachea la superficie pública; la entrega de webhooks comparte los mismos hooks de eventos de WordPress que escucha la lógica de invalidación del servidor MCP.
La frontera entre MCP y REST es una decisión de despliegue, no de código. La capa de datos (base de datos de WooCommerce, endpoints REST) es compartida. La capa de presentación (herramientas tipadas frente a recursos JSON) está separada.
Errores habituales de arquitectura con MCP y REST
Intentar que MCP haga el trabajo de REST. Cachear páginas públicas del catálogo a través de MCP es un error. Use REST con una CDN.
Intentar que REST haga el trabajo de MCP. Documentar en OpenAPI una superficie de acciones pensada para LLMs y esperar que el agente “se las arregle” da resultados frágiles. A los agentes les va mejor con el descubrimiento de herramientas de MCP.
Dos capas de datos paralelas. Si los handlers MCP reimplementan la lógica de negocio en lugar de llamar al origen REST, cada actualización de WordPress rompe ambas superficies. Mantenga la capa de datos en WordPress y las superficies de protocolo delgadas.
Olvidar el coste. Un servidor MCP es una unidad más que desplegar, una estrategia de autenticación más y una cosa más que monitorizar. No lo implante si su único consumidor es una integración ERP de un socio; publique el OpenAPI y dé el trabajo por terminado.
Temas relacionados
Este artículo trata la decisión a nivel de protocolo. La guía de implementación está en crear un servidor MCP para WooCommerce. La estrategia de autenticación está en patrones de autenticación MCP. El diseño de herramientas tipadas está en herramientas de catálogo tipadas con Zod para MCP. La ruta de migración desde una API existente está en migrar una API de WordPress a MCP. La página del servicio es desarrollo de servidores MCP.
El precio es individual, porque la forma adecuada depende de los consumidores a los que sirva y de las acciones que requieran contratos de nivel agente.
