¡Hola @mp158, bienvenido a nuestra comunidad!
Tienes una excelente pregunta; de hecho, esta es una de las partes más difíciles (y más importantes) de construir flujos de trabajo de agentes con MCP y n8n. Yo estructuraría el documento de requisitos menos en torno a “nodos” y más en torno al sistema de agentes que estás diseñando. Basándome en la documentación actual de n8n y en las mejores prácticas de IA + MCP, un esquema práctico podría verse así:
1. Contexto y objetivos
Comienza con una breve sección de “problema y objetivos”:
-
¿Cuál es tu sistema actual de gestión de procesos y qué datos están disponibles para el agente?
-
¿Dónde se sitúa el flujo de trabajo de n8n en la arquitectura general? ¿Es el Agente de IA el orquestador principal, o simplemente una herramienta dentro de una configuración más grande de múltiples agentes?
-
Sé explícito sobre lo que el agente debería poder hacer:
-
Lo que necesita leer (instancias de procesos, tickets, datos de KPI, etc.)
-
Lo que debería analizar (cuellos de botella, tiempo de ciclo, violaciones de SLA, handoffs faltantes…)
-
Qué tipo de recomendaciones debería producir (mejoras de procesos, alertas, nuevas tareas, actualizaciones de documentación, etc.).
También puedes listar los resultados esperados aquí (por ejemplo: «crear una incidencia en GitHub», «registrar un resumen en Notion», «enviar un mensaje de aprobación por Discord») similar a los ejemplos donde un Agente de n8n lee un boletín informativo, solicita aprobación en Discord y luego abre una incidencia en GitHub a través de MCP.
2. Arquitectura de alto nivel y flujo principal
A continuación, describe la arquitectura a nivel alto, idealmente con un diagrama simple más texto:
Esta sección debería permitir que alguien entienda el flujo de extremo a extremo sin leer ningún detalle a nivel de nodo.
3. Requisitos de MCP y herramientas externas
Ya que tu tesis se enfoca en MCP, le daría a MCP su propia sección dedicada.
3.1. Cómo se usa MCP en este flujo de trabajo
-
Si el flujo de trabajo de n8n actúa como un cliente MCP (Agente dentro de n8n llamando servidores MCP externos):
-
Si el flujo de trabajo de n8n se expone como un servidor MCP para que agentes externos (Claude, Cursor, etc.) lo llamen:
- Documenta cómo se configura el Disparador de Servidor MCP: ruta de URL, autenticación y esquema de entrada esperado.
3.2. Especificación a nivel de herramienta
Para cada herramienta MCP (especialmente la que envuelve tu sistema de gestión de procesos):
-
Nombre de la herramienta y descripción breve (qué capacidad empresarial representa).
-
Esquema de entrada: parámetros, tipos, restricciones (puedes hacer referencia a la referencia oficial de herramientas MCP de n8n si estás usando el servidor MCP integrado).
-
Esquema de salida: qué puede esperar el agente.
-
Límites: máximo de registros por llamada, tiempos de espera, límites de velocidad, límites de permisos.
Esto se lee casi como una especificación de API, pero desde la perspectiva del agente.
4. Diseño del flujo de trabajo en n8n
Aquí listaría nodos y lógica de una manera que una persona sin experiencia en n8n todavía pueda seguir:
4.1. Nodos principales
Lista los nodos principales en orden de ejecución:
-
Nodo(s) Disparador (Gmail/Webhook/Disparador de Servidor MCP, etc.).
-
Nodo de Agente de IA (incluye: modelo, prompt del sistema, configuraciones de planificación/memoria, protecciones).
-
Nodo(s) MCP Client / MCP Client Tool que se conecten a tu servidor MCP de gestión de procesos y a cualquier otro servidor MCP.
-
Nodos de integración (HTTP, base de datos, Notion, Discord, etc.).
-
Cualquier nodo Code que encapsule lógica empresarial personalizada.
Para cada nodo, documenta:
-
Propósito (en lenguaje simple).
-
Entradas/salidas clave (qué campos importan para el agente).
-
Condiciones de ramificación importantes.
4.2. Lógica de análisis y recomendación
En lugar de solo describir el prompt, captura las reglas que tu agente debe seguir, como:
-
Cuándo el agente puede proponer un cambio (p. ej., «solo recomendar cambios de proceso si el tiempo de ciclo ha estado por encima del umbral durante las últimas N ejecuciones»).
-
Cuándo debe escalar a un humano.
-
Cómo combina múltiples fuentes de datos: por ejemplo, llamar a más de un servidor MCP (herramienta de procesos + herramienta de documentación + sistema de tickets) y dejar que n8n orqueste los resultados antes de que el agente decida.
Esto hace que tu diseño sea auditable y más fácil de evaluar académicamente.
5. Intervención humana y control
En un contexto de tesis esto es importante: explica exactamente dónde y cómo los humanos mantienen el control:
-
Qué pasos siempre requieren aprobación explícita (p. ej., a través de un nodo «enviar y esperar respuesta» en Discord, un correo electrónico o un formulario).
-
Si el humano puede editar la acción propuesta o el texto antes de que se ejecute (por ejemplo: el usuario puede revisar el mensaje de recomendación y el agente replantea en función de esa entrada).
-
Comportamiento de fallback si un servidor MCP falla, devuelve datos inválidos o el resultado del LLM no pasa la validación.
6. Requisitos no funcionales
Finalmente, documenta las cosas que frecuentemente se pierden en la implementación:
7. Ejemplos y artefactos
Para la tesis en sí, incluiría:
-
Una exportación JSON (o extractos) de tu flujo de trabajo de n8n.
-
El prompt del sistema principal para el agente, anotado y vinculado nuevamente a los requisitos.
-
Uno o dos escenarios de prueba de extremo a extremo:
-
Datos de proceso de entrada.
-
Qué herramientas MCP se llaman en qué orden.
-
Qué análisis realiza el agente.
-
Qué recomendación se realiza y cómo la aplica (o rechaza) un humano.
Esta estructura le da a tu examinador un mapa claro del sistema sin forzarlos a leer n8n YAML/JSON.
Si compartes un poco más sobre tu configuración concreta (qué actúa como disparador, qué herramienta de proceso envuelves como MCP y si agentes externos llamarán a n8n como servidor), puedo ayudarte a convertir este esquema en un esqueleto de documento de requisitos de 1-2 páginas adaptado exactamente a tu caso de uso.