En noviembre de 2024, Anthropic publicó el Model Context Protocol (MCP), una especificación abierta para conectar modelos de lenguaje con herramientas y datos externos. OpenAI incorporó compatibilidad con el protocolo en su Agents SDK durante 2025, y el catálogo de servidores MCP no ha dejado de crecer desde entonces. Si ya tienes Ollama con modelos en tu máquina, Qdrant con embeddings y WordPress con contenido, MCP sustituye el pegamento artesanal entre los tres por un contrato común. Este artículo monta esa conexión con piezas verificables: el servidor MCP oficial de Qdrant, el proxy mcpo y un agente con soporte de herramientas.
Qué resuelve MCP exactamente
Para entenderlo, conviene partir del problema de fondo: con N aplicaciones y M fuentes de datos, cada pareja exige su propio conector.
El problema M×N de las integraciones
El problema de fondo es el de las integraciones M×N: con N aplicaciones y M fuentes de datos, cada pareja exige su propio conector. MCP reduce la ecuación a M+N. Un servidor expone sus capacidades una vez, y cualquier cliente compatible las descubre dinámicamente en el arranque. Las primitivas son tres: tools (funciones que el modelo invoca), resources (datos que el cliente lee) y prompts (plantillas reutilizables).
Dos transportes: stdio y HTTP
La especificación define dos transportes: stdio para procesos locales y HTTP para servicios en red. Hay un detalle práctico que conviene conocer antes de copiar tutoriales: la revisión de marzo de 2025 de la spec sustituyó el transporte HTTP+SSE original por Streamable HTTP, así que los ejemplos anteriores a esa fecha pueden fallar con clientes actuales.
Antes de escribir código, revisa el repositorio modelcontextprotocol/servers en GitHub. Incluye servidores de referencia para sistema de archivos, Git o PostgreSQL, y te ayuda a calibrar qué granularidad tiene una herramienta bien diseñada. Mantener el catálogo en tu servidor es la apuesta que la comparativa entre IA local y SaaS explica con números.
El papel de cada pieza en el stack
El primer componente del stack es el encargado de ejecutar los modelos en local y sostener todo el montaje.
Ollama: el motor de inferencia
Ollama es el motor de inferencia: descarga y ejecuta modelos en local y expone una API en el puerto 11434, con un endpoint compatible con OpenAI en /v1. Soporta tool calling desde mediados de 2024, aunque el soporte depende del modelo: Llama 3.1, Qwen 2.5 o Mistral Nemo incluyen variantes entrenadas para llamadas a funciones. Si el modelo elegido no sabe invocar herramientas, el resto del montaje se queda en decoración.
Qdrant: memoria de largo plazo
Qdrant aporta la memoria de largo plazo. Es una base vectorial escrita en Rust, con API REST en el puerto 6333 y gRPC en el 6334, y su equipo mantiene un servidor MCP oficial en el repositorio qdrant/mcp-server-qdrant. Ese servidor expone dos herramientas: qdrant-store, que guarda texto junto a sus embeddings, y qdrant-find, que busca por similitud.
WordPress: la API REST como terreno común
WordPress no entiende MCP de fábrica, pero sí expone una API REST madura que acepta application passwords desde la versión 5.6. En un artículo anterior montamos a mano el binomio Ollama y Qdrant dentro de WordPress; lo que cambia ahora es la capa de conexión, no las piezas. El primer chequeo práctico: lanza una petición a /api/chat y verifica que tu modelo lista las tools disponibles, porque ese es el requisito que decide si todo lo demás funciona.
mcpo: del stdio al REST
La mayoría de servidores MCP hablan por stdio, cómodo en escritorio pero incómodo para servicios web: de ahí la necesidad de un traductor.
Por qué hace falta un traductor
La mayoría de servidores MCP funcionan como procesos locales que hablan por stdio, un formato cómodo para clientes de escritorio e incómodo para servicios web. mcpo, un proxy del equipo de Open WebUI, resuelve esa fricción: convierte un servidor MCP en una API REST documentada con OpenAPI, donde cada tool aparece como un endpoint y la documentación se genera sola en /docs.
uvx mcpo --port 8000 -- uvx mcp-server-qdrant
Un contenedor, una línea de arranque
Con esa línea, mcpo arranca el servidor MCP de Qdrant como proceso hijo y publica sus herramientas en el puerto 8000. El patrón es idéntico para cualquier otro servidor: cambias el comando que va tras — y el proxy regenera los endpoints. Arranca el proxy, abre http://localhost:8000/docs y lanza una llamada de prueba con curl antes de meter al agente en escena; si el endpoint responde, la capa de transporte está lista.
Arquitectura del stack con Docker Compose
El stack se organiza en cuatro contenedores con Ollama, Qdrant, el servidor MCP de Qdrant y mcpo, sobre una red interna.
Cuatro contenedores y una red interna
El conjunto cabe en cuatro contenedores: Ollama en el 11434, Qdrant en el 6333, el servidor MCP de Qdrant y mcpo en el 8000. A ese grupo se suma un segundo servidor MCP dedicado a WordPress, que envuelve la API REST y expone operaciones como buscar entradas, crear borradores o listar categorías. Los volúmenes persistentes para los modelos de Ollama y el almacenamiento de Qdrant van en el mismo compose. Es el mismo patrón de servicios que ya montamos en la guía de IA local en WordPress con Ollama y Qdrant, con el servidor MCP como pieza nueva.
El agente: cliente MCP y modelo local
Por encima va el agente: un programa con cliente MCP y acceso al modelo de Ollama que decide qué herramienta invocar en cada paso. Si prefieres partir de un orquestador ya montado, la comunidad publica implementaciones con Docker Compose listas para esta arquitectura. Dibuja el mapa de puertos y variables de entorno antes de escribir una línea del compose: saber quién habla con quién evita depurar cadenas de conexión a ciegas. Un agente como el de Hermes Agent con Docker Compose encaja aquí sin cambios de arquitectura.
Montaje paso a paso
El orden de encendido importa, así que veamos por separado los servicios base, los servidores MCP y el agente.
Servicios base, servidores MCP y agente
El orden de encendido importa: primero los servicios base, después los servidores MCP y al final el agente.
- Levanta Ollama con la imagen ollama/ollama, monta el volumen de modelos y descarga un modelo con soporte de herramientas:
docker exec -it ollama ollama pull qwen2.5:7b. - Arranca Qdrant con la imagen qdrant/qdrant y mapea el puerto 6333.
- Lanza el servidor MCP de Qdrant con
uvx mcp-server-qdrant, indicando QDRANT_URL=http://qdrant:6333 y el nombre de la colección en la variable COLLECTION_NAME. - Coloca mcpo delante para exponer las herramientas vía REST.
- En el agente, registra el servidor MCP y comprueba que el listado de tools llega completo.
Application passwords en WordPress
Para el lado de WordPress, genera una application password desde el perfil de usuario y elige entre: un plugin MCP del directorio oficial que exponga las operaciones de edición, o un servidor MCP genérico configurado contra los endpoints de /wp-json/wp/v2. Aplica el principio de mínimo privilegio: un rol de autor basta para crear borradores, y no necesitas credenciales de administrador para escribir contenido. La validación final es un ciclo de ida y vuelta: guarda un texto con qdrant-store, recupéralo con qdrant-find y comprueba que el agente cita el contenido exacto.
Un flujo de ejemplo de principio a fin
Para aterrizarlo, sigamos una petición encadenada que recupera de Qdrant y crea un borrador en WordPress.
De Qdrant a un borrador en WordPress
Imagina esta petición al agente: recupera de Qdrant las notas más parecidas a este borrador y crea en WordPress un borrador con el resumen y los enlaces internos sugeridos. El modelo la descompone en dos llamadas encadenadas: qdrant-find con el texto del borrador y, con los resultados ya en el contexto, la herramienta de creación de entradas del servidor de WordPress. Tu trabajo está antes, en la configuración de permisos, colecciones y roles.
Cada servidor nuevo multiplica el catálogo
El beneficio real aparece al ampliar el catálogo. Si añades un servidor MCP de Git o del sistema de archivos, el agente descubre las nuevas herramientas en el arranque y puedes pedirle cosas como crear una rama con el borrador revisado. Ese es el contrato que separa a MCP de una integración a medida: las herramientas quedan descritas en un formato que cualquier cliente compatible puede leer sin trabajo adicional.
Seguridad y límites reales
Un servidor MCP actúa con tus permisos, de ahí la necesidad de acotar el alcance de las credenciales que le entregas.
Permisos de menor privilegio
Un servidor MCP actúa con tus permisos. Si le entregas una application password de administrador, cada tool puede escribir en toda la web, así que crea credenciales de alcance mínimo y documenta qué herramienta toca qué recurso. Si expones mcpo fuera de tu máquina, pon delante un proxy inverso con autenticación: una API generada automáticamente hereda el alcance combinado de todas sus herramientas, y conviene revisar la documentación del proxy antes de abrir ningún puerto.
Un protocolo joven: qué puede cambiar
El protocolo todavía se mueve. La revisión de marzo de 2025 cambió un transporte entero, y no todos los servidores publican con qué versión de la spec trabajan, así que mezclar clientes y servidores de épocas distintas exige verificación. Suma el coste de contexto: cada tool registrada añade su definición al prompt, un gasto que se nota en modelos de 7B con ventanas ajustadas. Registra en un log cada llamada a herramientas durante las primeras semanas de uso; el patrón que emerja te dirá qué servidores sobran y cuáles confunden al modelo con definiciones ambiguas.
Empieza por un solo servidor
Para no caer en la tentación de levantar cinco servidores el primer día, empieza con uno solo: el ciclo qdrant-store y qdrant-find.
Un servidor esta semana
La tentación con MCP es levantar cinco servidores el primer día, y el resultado habitual es un agente paralizado por demasiadas herramientas. El ciclo qdrant-store y qdrant-find es el mejor punto de entrada: dos herramientas, un contenedor y un proxy, con resultados visibles en la primera sesión. Cuando ese flujo funcione sin sorpresas, añade el servidor de WordPress y después lo que el uso real pida.
Dónde crece el valor con cada servidor nuevo
El valor del protocolo crece con cada servidor añadido: las herramientas nuevas quedan disponibles para cualquier cliente MCP del stack, sin repetir integraciones. El siguiente paso concreto es ejecutar el servidor MCP de Qdrant con uvx, validar el ciclo store-find contra tu colección y dejar el stack corriendo una semana antes de sumar la pieza de WordPress. Cuando el catálogo crezca y el portátil no llegue, un VPS para tu stack MCP mantiene Ollama, Qdrant y el agente siempre encendidos.