12 Servers, One Protocol: How MCP Transformed My Teaching

It all started with a problem: I was sitting in front of Moodle on a Sunday evening, clicking through menus. Create a course. Add a section. Set up a quiz. Enter questions. A single course took hours. Five classes took half a Sunday.

At some point I thought: There has to be a better way.

One Server, One Problem

The first MCP server was simple. A small Node.js service that talked to the Moodle Web Services API. Three endpoints: create a course, create a quiz, add questions. Behind Traefik as a reverse proxy, Let's Encrypt for HTTPS, done.

The evening I first typed "Create a quiz on breach of contract" and had a finished quiz in Moodle 30 seconds later, I knew: This is going to get bigger.

From 3 to 73 Tools

Today the Moodle MCP server alone has 73 tools. Courses, sections, quizzes, H5P activities, enrolments, grades, assessments, labels, pages, URLs, resources, folders — all via API. On top of that, bulk operations: moodle_bulk_add_questions creates any number of questions in a single call. moodle_import_gift imports Moodle's GIFT format directly.

But the Moodle server was just the beginning.

The Ecosystem

Twelve servers. Over a hundred tools. One protocol.

Each server is its own Docker container. Each speaks MCP — the Model Context Protocol. Each can be deployed independently, scaled independently, replaced independently.

The Architecture Philosophy: Many Small Independent Servers

Why not one big server with everything? Because small servers are better. In every way.

Fault tolerance. If the Voice server crashes, Moodle keeps working. If SharePoint needs an update, the rest keeps running.

Development speed. I can rewrite the IMAP server in an hour without touching anything else.

Simplicity. Each server has one job. The Moodle server talks to Moodle. The Teams server talks to Teams. No server needs to know what the others are doing.

This isn't accidental. It's stigmergy — the principle that ants work by. No central coordinator. Each actor responds to its environment and leaves traces that others can build on.

The Sunday Evening Workflow

Here's what it looks like in practice. Sunday evening, 8 PM. Tomorrow starts a new learning scenario on "Procurement Processes in Wholesale".

In the old days, I would have spent three hours in front of Moodle. Today:

1. I describe the learning scenario in natural language
2. Claude creates the Moodle course section via the Moodle-MCP
3. Quiz questions are generated and imported — 71 questions in under a minute
4. H5P activities are created and uploaded — H5P pipeline
5. Everything gets formatted as a worksheet in my school's corporate design
6. A brief summary goes to my department via IMAP-MCP

8:45 PM. Done. Not "draft done". Everything live in Moodle.

The rest of the evening is mine. Or I use it to build the next MCP server.

The Stigmergy Principle

What sets this system apart from classic software architecture is the principle behind it. In traditional systems, there's a central coordinator — an orchestrator that dictates who does what and when.

My system doesn't have that. Each server exists on its own. It offers tools. It waits for requests. It knows nothing about the others.

The intelligence doesn't live in the infrastructure. It lives in the LLM that uses the servers. Claude decides which tools it needs for a task, calls them in the right order, and combines the results.

That's stigmergy. The environment — the available servers — structures the behaviour. Not a plan. Not an org chart. The tools themselves.

What I've Learned

A year with MCP servers has taught me a few things:

Automation isn't a luxury. It's a moral obligation. Every hour I spend clicking through Moodle is an hour I don't have for my students.

Perfect is the enemy of done. The first Moodle server had three endpoints and was more useful than any commercial tool I'd seen up to that point.

Open protocols win. MCP isn't a proprietary format. Anyone can build an MCP server. Anyone can use one. That's what makes the ecosystem robust.

The best documentation is a working server. Nobody reads documentation. But if you can type "Create a course" and it works, nobody needs a manual.

What's Next?

More servers. More tools. More automation. The next step is an MCP server for Microsoft 365 administration — managing users, assigning licences, everything a school IT admin has to do.

And eventually, when the ecosystem is big enough, it might not even need me anymore.

But until then, I'll be sitting at my computer on Sunday evenings. No longer to click through Moodle menus. But to build the next server.