12 servidores, un protocolo: Cómo MCP transformó mi enseñanza

Todo empezó con un problema: un domingo por la noche estaba sentado frente a Moodle, haciendo clic tras clic por los menús. Crear un curso. Añadir una sección. Configurar un cuestionario. Introducir preguntas. Un solo curso me llevaba horas. Cinco clases, medio domingo.

En algún momento pensé: Tiene que haber una forma mejor.

Un servidor, un problema

El primer servidor MCP era sencillo. Un pequeño servicio en Node.js que se comunicaba con la API de servicios web de Moodle. Tres endpoints: crear un curso, crear un cuestionario, añadir preguntas. Detrás de Traefik como proxy inverso, Let's Encrypt para HTTPS, y listo.

La noche en que por primera vez escribí "Crea un cuestionario sobre incumplimiento de contratos" y 30 segundos después tenía un cuestionario listo en Moodle, supe: esto iba a crecer.

De 3 a 73 herramientas

Hoy el servidor Moodle-MCP tiene por sí solo 73 herramientas. Cursos, secciones, cuestionarios, actividades H5P, matriculaciones, calificaciones, evaluaciones, etiquetas, páginas, URLs, recursos, carpetas — todo por API. Además, operaciones masivas: moodle_bulk_add_questions crea cualquier cantidad de preguntas en una sola llamada. moodle_import_gift importa directamente el formato GIFT de Moodle.

Pero el servidor de Moodle fue solo el comienzo.

El ecosistema

Doce servidores. Más de cien herramientas. Un protocolo.

Cada servidor es su propio contenedor Docker. Cada uno habla MCP — el Model Context Protocol. Cada uno se puede desplegar de forma independiente, escalar de forma independiente, reemplazar de forma independiente.

La filosofía de arquitectura: Muchos servidores pequeños e independientes

¿Por qué no un gran servidor con todo? Porque los servidores pequeños son mejores. En todos los sentidos.

Tolerancia a fallos. Si el servidor de voz se cae, Moodle sigue funcionando. Si SharePoint necesita una actualización, el resto sigue en marcha.

Velocidad de desarrollo. Puedo reescribir el servidor IMAP en una hora sin tocar nada más.

Simplicidad. Cada servidor tiene una tarea. El servidor de Moodle habla con Moodle. El servidor de Teams habla con Teams. Ningún servidor necesita saber qué hacen los demás.

Esto no es casualidad. Es estigmergia — el principio por el que trabajan las hormigas. Sin coordinador central. Cada actor reacciona a su entorno y deja rastros sobre los que otros pueden construir.

El flujo de trabajo del domingo por la noche

Así se ve en la práctica. Domingo por la noche, 20:00. Mañana comienza una nueva situación de aprendizaje sobre "Procesos de aprovisionamiento en el comercio mayorista".

Antes habría pasado tres horas frente a Moodle. Hoy:

1. Describo la situación de aprendizaje en lenguaje natural
2. Claude crea la sección del curso en Moodle a través del Moodle-MCP
3. Las preguntas del cuestionario se generan e importan — 71 preguntas en menos de un minuto
4. Las actividades H5P se crean y suben — pipeline H5P
5. Todo se formatea como una hoja de trabajo con el diseño corporativo de mi centro
6. Un breve resumen se envía a mi departamento por IMAP-MCP

20:45. Listo. No "borrador listo". Todo en vivo en Moodle.

El resto de la noche es mío. O lo uso para construir el siguiente servidor MCP.

El principio de estigmergia

Lo que distingue a este sistema de la arquitectura de software clásica es el principio que lo sustenta. En los sistemas tradicionales hay un coordinador central — un orquestador que dicta quién hace qué y cuándo.

En mi sistema no existe eso. Cada servidor existe por sí mismo. Ofrece herramientas. Espera solicitudes. No sabe nada de los demás.

La inteligencia no reside en la infraestructura. Reside en el LLM que utiliza los servidores. Claude decide qué herramientas necesita para una tarea, las invoca en el orden correcto y combina los resultados.

Eso es estigmergia. El entorno — los servidores disponibles — estructura el comportamiento. No un plan. No un organigrama. Las herramientas mismas.

Lo que he aprendido

Un año con servidores MCP me ha enseñado algunas cosas:

La automatización no es un lujo. Es una obligación moral. Cada hora que paso haciendo clics en Moodle es una hora que no tengo para mis alumnos.

Lo perfecto es enemigo de lo terminado. El primer servidor de Moodle tenía tres endpoints y era más útil que cualquier herramienta comercial que hubiera visto hasta entonces.

Los protocolos abiertos ganan. MCP no es un formato propietario. Cualquiera puede construir un servidor MCP. Cualquiera puede usarlo. Eso es lo que hace robusto al ecosistema.

La mejor documentación es un servidor que funciona. Nadie lee la documentación. Pero si puedes escribir "Crea un curso" y funciona, nadie necesita un manual.

¿Qué viene después?

Más servidores. Más herramientas. Más automatización. El siguiente paso es un servidor MCP para la administración de Microsoft 365 — gestionar usuarios, asignar licencias, todo lo que un administrador de TI escolar necesita hacer.

Y algún día, cuando el ecosistema sea lo bastante grande, quizá ya no me necesite.

Pero hasta entonces, estaré sentado frente al ordenador los domingos por la noche. Ya no para hacer clic en los menús de Moodle. Sino para construir el siguiente servidor.