12 серверів, один протокол: Як MCP змінив моє викладання

Все почалося з проблеми: недільного вечора я сидів перед Moodle і клацав по меню. Створити курс. Додати розділ. Налаштувати тест. Ввести запитання. На один курс йшли години. На п'ять класів — половина неділі.

В якийсь момент я подумав: Має ж бути інший спосіб.

Один сервер, одна проблема

Перший MCP-сервер був простим. Невеликий Node.js-сервіс, який звертався до API веб-сервісів Moodle. Три ендпоінти: створити курс, створити тест, додати запитання. За Traefik як реверс-проксі, Let's Encrypt для HTTPS — і готово.

Того вечора, коли я вперше набрав "Створи тест на тему порушення договірних зобов'язань" і через 30 секунд мав готовий тест у Moodle, я зрозумів: це стане чимось більшим.

Від 3 до 73 інструментів

Сьогодні один лише Moodle-MCP-сервер має 73 інструменти. Курси, розділи, тести, H5P-активності, зарахування, оцінки, мітки, сторінки, URL-адреси, ресурси, папки — все через API. Додайте до цього масові операції: moodle_bulk_add_questions створює будь-яку кількість запитань за один виклик. moodle_import_gift імпортує формат GIFT від Moodle напряму.

Але Moodle-сервер був лише початком.

Екосистема

Дванадцять серверів. Понад сотня інструментів. Один протокол.

Кожен сервер — окремий Docker-контейнер. Кожен спілкується через MCP — Model Context Protocol. Кожен можна розгортати незалежно, масштабувати незалежно, замінювати незалежно.

Філософія архітектури: Багато маленьких незалежних серверів

Чому не один великий сервер з усім? Тому що маленькі сервери кращі. У всьому.

Стійкість до збоїв. Якщо Voice-сервер впаде, Moodle продовжить працювати. Якщо SharePoint потребує оновлення, решта працює далі.

Швидкість розробки. Я можу переписати IMAP-сервер за годину, не торкаючись нічого іншого.

Простота. Кожен сервер має одне завдання. Moodle-сервер спілкується з Moodle. Teams-сервер спілкується з Teams. Жоден сервер не повинен знати, що роблять інші.

Це не випадковість. Це стигмергія — принцип, за яким працюють мурахи. Жодного центрального координатора. Кожен учасник реагує на своє оточення і залишає сліди, на яких будують інші.

Недільний вечірній воркфлоу

Ось як це виглядає на практиці. Недільний вечір, 20:00. Завтра починається нова навчальна ситуація на тему "Процеси закупівель в оптовій торгівлі".

Раніше я б просидів три години перед Moodle. Сьогодні:

1. Я описую навчальну ситуацію природною мовою
2. Claude створює розділ курсу в Moodle через Moodle-MCP
3. Тестові запитання генеруються та імпортуються — 71 запитання менш ніж за хвилину
4. H5P-активності створюються та завантажуються — H5P-пайплайн
5. Все оформлюється як робочий аркуш у корпоративному дизайні моєї школи
6. Короткий підсумок надсилається моєму відділу через IMAP-MCP

20:45. Готово. Не "чернетка готова". Все вже працює в Moodle.

Решта вечора — моя. Або я використовую її, щоб побудувати наступний MCP-сервер.

Принцип стигмергії

Що відрізняє цю систему від класичної програмної архітектури — це принцип, що стоїть за нею. У традиційних системах є центральний координатор — оркестратор, який каже, хто що і коли робить.

У моїй системі такого немає. Кожен сервер існує сам по собі. Він пропонує інструменти. Він чекає на запити. Він нічого не знає про інших.

Інтелект живе не в інфраструктурі. Він живе в LLM, яка використовує сервери. Claude вирішує, які інструменти потрібні для завдання, викликає їх у правильному порядку та комбінує результати.

Це стигмергія. Середовище — доступні сервери — структурує поведінку. Не план. Не організаційна схема. Самі інструменти.

Чого я навчився

Рік з MCP-серверами навчив мене кількох речей:

Автоматизація — не розкіш. Це моральний обов'язок. Кожна година, яку я витрачаю на клацання в Moodle — це година, якої не буде для моїх учнів.

Ідеальне — ворог готового. Перший Moodle-сервер мав три ендпоінти і був кориснішим за будь-який комерційний інструмент, який я бачив до того.

Відкриті протоколи перемагають. MCP — не пропрієтарний формат. Будь-хто може побудувати MCP-сервер. Будь-хто може ним користуватися. Саме це робить екосистему стійкою.

Найкраща документація — працюючий сервер. Ніхто не читає документацію. Але якщо ви можете набрати "Створи курс" і це працює, нікому не потрібен посібник.

Що далі?

Більше серверів. Більше інструментів. Більше автоматизації. Наступний крок — MCP-сервер для адміністрування Microsoft 365: управління користувачами, призначення ліцензій — все, що повинен робити шкільний ІТ-адміністратор.

І колись, коли екосистема стане достатньо великою, вона, можливо, більше не потребуватиме мене.

Але до того часу я сидітиму за комп'ютером недільними вечорами. Вже не для того, щоб клацати по меню Moodle. А щоб побудувати наступний сервер.