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 esquemas tipados con anotaciones de comportamiento 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. Desde la revisión 2026-07-28 el protocolo ya no tiene sesiones: cada petición lleva la versión del protocolo y las capacidades del cliente, y el cliente vuelve a pedir la lista cuando caduca la copia en caché o llega una notificación de cambio.
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 | Semántica de los verbos HTTP (RFC 9110) | inputSchema + anotaciones readOnlyHint, destructiveHint, idempotentHint (solo indicaciones) |
| Autenticación | Tokens bearer, OAuth | Lo mismo, más scopes asignados por herramienta |
| Caché | Cabeceras de caché HTTP | ttlMs y cacheScope en las listas; tools/call sin indicación de caché |
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. Cuando un pedido cambia de estado, un webhook de WooCommerce envía el evento a un endpoint del socio. Ese endpoint es un receptor HTTP. 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 parámetros de query repartidos en varios 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. Una herramienta MCP order.intent con un esquema de entrada tipado, un parámetro idempotency_key obligatorio y destructiveHint: false le dice al agente y al cliente qué hace la llamada antes de ejecutarla. El protocolo no garantiza la idempotencia: es el handler quien tiene que rechazar un segundo pedido con la misma clave. La diferencia frente a un POST /wp-json/wc/v3/orders libre está en un contrato que el modelo puede leer.
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 description e inputSchema. El servidor envía notifications/tools/list_changed a los clientes que han abierto subscriptions/listen, y el agente detecta la herramienta 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
En WordPress, la API REST tiene tres vías documentadas (autenticación en la API REST). La autenticación por cookie sirve al código que se ejecuta en el propio sitio y exige un nonce de la acción wp_rest, enviado en la cabecera X-WP-Nonce; sin nonce, la petición se ejecuta como usuario anónimo aunque haya sesión iniciada. Las Application Passwords forman parte del núcleo desde WordPress 5.6 y funcionan con HTTP Basic, solo sobre HTTPS. OAuth 1.0a y JSON Web Tokens llegan mediante plugins. El ajuste fino de permisos se hace por ruta, en las capabilities del usuario y en el permission_callback de cada endpoint.
La autorización en MCP es opcional y se aplica a los transportes HTTP; con stdio, las credenciales salen del entorno. Cuando se usa, el servidor MCP es un resource server OAuth 2.1, tiene que publicar Protected Resource Metadata (RFC 9728) y solo acepta tokens emitidos para él: el cliente identifica el servidor en el parámetro resource (RFC 8707) y el servidor rechaza tokens de otra audiencia. El servidor tampoco puede aceptar ni reenviar otros tokens, así que se autentica ante WordPress con credenciales propias, por ejemplo una Application Password de un usuario con un rol limitado.
Los scopes funcionan como en cualquier API OAuth, con dos reglas útiles para agentes. El servidor puede devolver en tools/list solo las herramientas que permiten los scopes del token. Y cuando una llamada necesita más, responde HTTP 403 con error="insufficient_scope" y los scopes necesarios en la cabecera WWW-Authenticate, para que el cliente pida una nueva autorización con el conjunto ampliado. El usuario concede orders:read al agente; el agente ni siquiera ve order.cancel y, si intenta llamarla, recibe el 403 antes de que se ejecute el handler. OpenAPI describe lo mismo con securitySchemes y security por operación (especificación OpenAPI), pero en la práctica muchas APIs REST documentan un único scope global y dejan la granularidad fina a la aplicación.
En las integraciones con agentes, este mapeo de scopes por herramienta es una ventaja ergonómica real, que además encaja con el requisito de minimización de datos del RGPD. Por debajo, el mecanismo es el OAuth que REST ya conoce, 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.
En MCP, la revisión 2026-07-28 trajo una parte de esto (caché en MCP). Los resultados de tools/list, prompts/list, resources/list, resources/templates/list y resources/read tienen que llevar ttlMs, que funciona como max-age, y cacheScope, con los valores public y private, análogos a los de Cache-Control. Los resultados de tools/call, que son el grueso del tráfico de un agente, no están en esa lista. Viajan como payloads JSON-RPC dentro de peticiones POST y las cabeceras de caché HTTP no se aplican. La caché de las llamadas 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 te toca diseñar a ti.
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.
Anotaciones de herramientas MCP frente a verbos HTTP idempotentes
En REST, la seguridad de una operación está en el propio verbo. La RFC 9110 define GET, HEAD, OPTIONS y TRACE como métodos seguros, y PUT, DELETE y los métodos seguros como idempotentes: varias peticiones idénticas tienen el mismo efecto previsto que una sola. POST no es idempotente. Un proxy, un crawler o una biblioteca de reintentos decide qué puede repetir solo a partir del método, sin leer el cuerpo.
MCP envía todo como tools/call dentro de un POST, así que el verbo no dice nada. La información pasa a la definición de la herramienta. El esquema de la especificación define cuatro anotaciones booleanas en ToolAnnotations:
| Anotación | Significado | Valor por defecto |
|---|---|---|
readOnlyHint | la herramienta no modifica su entorno | false |
destructiveHint | puede hacer cambios destructivos, no solo aditivos | true |
idempotentHint | repetir la llamada con los mismos argumentos no tiene efecto adicional | false |
openWorldHint | interactúa con un conjunto abierto de entidades externas, como una búsqueda web | true |
Los valores por defecto son pesimistas: una herramienta sin anotaciones se trata como capaz de escribir, de destruir y de no ser idempotente. La especificación dice que todas estas propiedades son indicaciones, que no garantizan una descripción fiel del comportamiento, y que un cliente no debe decidir en función de anotaciones de servidores en los que no confía. La página de tools recomienda además una persona en el ciclo con capacidad para rechazar una invocación, y peticiones de confirmación en operaciones sensibles.
En una tienda WooCommerce se traduce así: product.search lleva readOnlyHint: true, order.cancel lleva destructiveHint: true, y la idempotencia de order.intent se garantiza en el handler con una clave que el servidor comprueba, no con la anotación. La anotación ayuda al cliente a decidir cuándo pedir confirmación. No sustituye las obligaciones del servidor que enumera la especificación: validar todas las entradas, aplicar control de acceso, limitar la tasa de invocaciones y sanear las salidas.
Cómo informa MCP de los errores frente a los códigos de estado HTTP
Una API REST comunica los fallos con el código de estado: 400 para una petición mal formada, 401 sin autenticación válida, 403 sin permiso, 404 para una ruta inexistente. La especificación de tools separa dos niveles. Los errores de protocolo (herramienta desconocida, petición que no cumple el esquema de tools/call, fallo del servidor) llegan como errores JSON-RPC normales, por ejemplo con el código -32602. Los errores de ejecución (fallo de la API de origen, fecha en formato incorrecto, regla de negocio incumplida) llegan dentro de un resultado con isError: true y un mensaje de texto.
La especificación recomienda que los clientes pasen los errores de ejecución al modelo, porque contienen información que le permite corregir los argumentos y reintentar. En un servidor MCP que envuelve la API REST de WordPress, un 400 de validación devuelto por WordPress debe convertirse en un resultado con isError: true que nombre el parámetro que falta, y no en un error de protocolo que el modelo no puede corregir.
Descubrimiento en la API REST de WordPress frente a tools/list de MCP
El REST de WordPress también se describe a sí mismo, de otra manera. Las páginas del sitio envían una cabecera Link con rel="https://api.w.org/" que apunta a la raíz de la API, y la raíz en /wp-json/ devuelve un objeto con los namespaces disponibles (wp/v2, wc/v3 y los de los plugins), las rutas y una clave authentication con los métodos admitidos (descubrimiento de la API REST). Una petición OPTIONS a una ruta devuelve su esquema, escrito en un subconjunto de JSON Schema draft 4 (esquema en la API REST).
La diferencia está en quién lee. El índice de WordPress está pensado para un programador o para un generador de SDK: lista todas las rutas registradas y cada una acepta parámetros globales como _fields (respuestas parciales, con propiedades anidadas desde WordPress 5.3), _embed (recursos enlazados en la misma respuesta) y _envelope (parámetros globales). Las colecciones paginan con per_page hasta 100 y devuelven los totales en las cabeceras X-WP-Total y X-WP-TotalPages (paginación). Todo esto sirve bien a un cliente programado, pero un modelo que reciba el índice entero gasta contexto eligiendo entre rutas que nunca va a usar.
El tools/list de MCP devuelve solo lo que el servidor ha decidido exponer, cada herramienta con description, inputSchema (JSON Schema 2020-12 por defecto) y, de forma opcional, outputSchema. La especificación permite que la lista varíe según los scopes del token y pide un orden determinista, para que el cliente pueda cachearla y el modelo aproveche la caché de prompts. Un servidor MCP para WordPress es, en la práctica, una selección curada del índice /wp-json/, con descripciones escritas para un modelo y no para un programador.
WordPress 6.9 añadió una pieza intermedia, la Abilities API. Un plugin registra una ability con input_schema, output_schema, un permission_callback opcional y show_in_rest en los metadatos. Es una forma nativa de describir unidades de funcionalidad con esquema, que es justo el contrato que necesita un servidor MCP para cada herramienta.
Qué cambió en MCP 2026-07-28 para proxies y balanceadores HTTP
Las revisiones de 2025 tenían un handshake initialize, sesiones identificadas por la cabecera Mcp-Session-Id y un flujo SSE abierto por GET. Con varios servidores detrás de un balanceador, una sesión por conexión obliga a enviar el mismo cliente al mismo servidor o a compartir el estado entre servidores, un problema que el REST sin estado no tiene. La revisión 2026-07-28 eliminó las tres cosas. Cada petición lleva la versión del protocolo y las capacidades del cliente en _meta. Quien necesita estado entre llamadas, como un carrito, devuelve un identificador explícito en una herramienta y lo recibe como argumento en las llamadas siguientes.
El transporte Streamable HTTP también refleja ahora metadatos en cabeceras. MCP-Protocol-Version y Mcp-Method son obligatorias en cada POST, Mcp-Name también en tools/call, resources/read y prompts/get, y una herramienta puede marcar parámetros con x-mcp-header para exponerlos como Mcp-Param-{nombre}. Así, un WAF o un gateway puede enrutar o limitar la tasa por herramienta sin leer el cuerpo JSON. Si una cabecera no coincide con el cuerpo, el servidor responde 400 con el error HeaderMismatch (-32020). La especificación desaconseja marcar así parámetros sensibles, porque las cabeceras quedan visibles para los intermediarios.
Para quien ya opera una API REST detrás de una CDN, las dos superficies se acercan en la operación: las mismas reglas de enrutado y de rate limiting por cabecera sirven para ambas. La caché HTTP sigue sin aplicarse a tools/call, porque cada llamada es un POST.
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. Usa 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. Mantén 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 implantes si tu único consumidor es una integración ERP de un socio; publica el OpenAPI y da 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.
