Hi @mp158 , welcome to our community!
You have a great question, this is actually one of the hardest (and most important) parts of building agentic workflows with MCP and n8n. I’d structure the requirements document less around “nodes” and more around the agent system you’re designing. Based on the current n8n docs and AI + MCP best practices, a practical outline could look like this:
1. Context & goals
Start with a short “problem & goals” section:
-
What is your current process management system and what data is available to the agent?
-
Where does the n8n workflow sit in the overall architecture – is the AI Agent the main orchestrator, or just one tool inside a larger multi‑agent setup?
-
Be explicit about what the agent should be able to do:
-
What it needs to read (process instances, tickets, KPI data, etc.)
-
What it should analyze (bottlenecks, cycle time, SLA violations, missing hand‑offs…)
-
What type of recommendations it should output (process improvements, alerts, new tasks, documentation updates, etc.).
You can also list expected outcomes here (for example: “create a GitHub issue”, “log a summary into Notion”, “send a Discord approval message”) similar to the examples where an n8n Agent reads a newsletter, asks for approval on Discord, then opens a GitHub issue via MCP.
2. High‑level architecture & main flow
Next, describe the architecture at a high level, ideally with a simple diagram plus text:
This section should let someone understand the end‑to‑end flow without reading any node‑level details.
3. MCP & external tool requirements
Because your thesis focuses on MCP, I’d give MCP its own dedicated section.
3.1. How MCP is used in this workflow
-
If the n8n workflow is acting as an MCP client (Agent inside n8n calling external MCP servers):
-
If the n8n workflow is exposed as an MCP server so external agents (Claude, Cursor, etc.) can call it:
- Document how the MCP Server Trigger is configured: URL path, auth, and expected input schema.
3.2. Tool‑level specification
For each MCP tool (especially the one wrapping your process management system):
-
Tool name and short description (what business capability it represents).
-
Input schema: parameters, types, constraints (you can reference the official n8n MCP tools reference if you’re using the built‑in MCP server).
-
Output schema: what the agent can expect back.
-
Limits: maximum records per call, timeouts, rate limits, permission boundaries.
This reads almost like an API spec, but from the perspective of the agent.
4. Workflow design in n8n
Here I’d list nodes and logic in a way a non‑n8n person can still follow:
4.1. Core nodes
List the main nodes in execution order:
-
Trigger node(s) (Gmail/Webhook/MCP Server Trigger, etc.).
-
AI Agent node (include: model, system prompt, planning/memory settings, guardrails).
-
MCP Client / MCP Client Tool node(s) that connect to your process management MCP server and any other MCP servers.
-
Integration nodes (HTTP, database, Notion, Discord, etc.).
-
Any Code nodes that encapsulate custom business logic.
For each node, document:
-
Purpose (in plain language).
-
Key inputs/outputs (which fields matter for the agent).
-
Important branching conditions.
4.2. Analysis & recommendation logic
Instead of only describing the prompt, capture the rules your agent must follow, such as:
-
When the agent is allowed to propose a change (e.g. “only recommend process changes if cycle time has been above threshold for the last N runs”).
-
When it must escalate to a human.
-
How it combines multiple data sources: for instance, calling more than one MCP server (process tool + documentation tool + ticketing system) and letting n8n orchestrate the results before the agent decides.
This makes your design auditable and easier to evaluate academically.
5. Human‑in‑the‑loop & control
In a thesis context this is important: explain exactly where and how humans stay in control:
-
Which steps always require explicit approval (e.g. via a “send and wait for response” node on Discord, an email, or a form).
-
Whether the human can edit the proposed action or text before it’s executed (for example: user can revise the recommendation message and the agent re‑plans based on that input).
-
Fallback behaviour if an MCP server fails, returns invalid data, or the LLM result does not pass validation.
6. Non‑functional requirements
Finally, document the things that often get lost in implementation:
-
Logging & observability
- What you log (prompts, agent decisions, tool calls, errors) and where.
-
Security
-
Performance
- Timeouts for MCP calls, maximum dataset size per analysis, expected max latency end‑to‑end.
-
Scalability & modularity
- When the workflow should be refactored into sub‑workflows or dedicated MCP tools (for example, starting with a single workflow and later extracting reusable capabilities into separate MCP tools or sub‑workflows as complexity grows).
7. Examples and artefacts
For the thesis itself, I’d include:
-
A JSON export (or excerpts) of your n8n workflow.
-
The main system prompt for the agent, annotated and tied back to the requirements.
-
One or two end‑to‑end test scenarios:
-
Input process data.
-
Which MCP tools are called in which order.
-
What analysis the agent performs.
-
What recommendation is made and how it is applied (or rejected) by a human.
This structure gives your examiner a clear map of the system without forcing them to read n8n YAML/JSON.
If you share a bit more about your concrete setup (what acts as trigger, which process tool you wrap as MCP, and whether external agents will call n8n as a server), I can help you turn this outline into a 1–2 page requirement document skeleton tailored exactly to your use case.