Я не хотів ще одного загального CMS, прикріпленого до мого сайту. На мою думку, така конфігурація завжди створює тертя. Я хотів mcp cms, який відчувався б як частина продукту, а не як зовнішня система, з якою мені доводилося б боротися щодня.
Ця стаття пояснює, як я створив свій mcp cms з Next.js, Supabase, MCP та agent flows. Я розглядаю архітектуру, шар інструментів, адміністративну панель та контентний конвеєр, щоб ви могли побачити, як вся система працює на практиці.
Чому я створив MCP CMS замість використання загального безголового стеку
Я створив сайт і CMS в одному додатку Next.js, тому що хотів одну кодову базу, одну модель даних і один робочий процес публікації. Я використав достатньо відокремлених стеків, щоб знати, як швидко вони перетворюються на борг з обслуговування. Коли ваш фронтенд, CMS та автоматизаційний шар живуть в різних місцях, кожна зміна коштує більше часу, ніж повинна.
Мій mcp cms тримає публічний сайт, адміністративний інтерфейс, маршрути API та AI-інструменти всередині однієї межі продукту. Це означає, що я можу змінювати SEO-метадані, локалізацію або логіку статей, не стрибаючи між трьома системами. Я також уникаю звичайної "проблеми синхронізації", коли контент живе в одному інструменті, а реальна логіка - десь ще.
На практиці це дало мені швидшу ітерацію та менше зламаних країв. Це також зробило систему легшою для спостереження, оскільки кожна дія запису проходить через один і той же шар. Якщо ви хочете більше контексту про те, як я думаю про операційні контентні системи, мій пост про Мульти-агентний контентний конвеєр у Next.js з Search Console показує дослідницьку сторону цього робочого процесу.
Основна ідея системи
Основна ідея проста: CMS має поводитися як продукт, а не як конструктор форм. Я хотів типізований контент, контрольовані записи та автоматизаційний шар, який міг би допомогти мені публікувати швидше, не втрачаючи контролю. Ось чому я зберіг архітектуру суворою, а межі чіткими.
Що я змінив у традиційному CMS
Традиційний CMS зазвичай розділяє редагування контенту від кодової бази продукту. Це звучить гнучко, але часто сповільнює команди, коли сайт стає більш кастомізованим. Мій mcp cms усуває це розділення. Тепер я можу керувати контентом, SEO та логікою робочого процесу в одному місці, що дає мені більше важелів з меншими витратами.
Як MCP CMS використовує MCP як контрольний шар
Найважливішим рішенням було розміщення MCP в центрі системи. Я не хотів, щоб функції AI були затиснуті в одному вікні чату або на одній панелі. Я хотів багаторазовий командний шар, який міг би спілкуватися з тими ж правилами бекенду з різних клієнтів.
Ось чому я створив як окремий сервер MCP, так і маршрут MCP в додатку. Інструменти, які відкриваються через mcp cms, включають CRUD для блогів, публікацію, SEO-аналіз, генерацію статей, дослідження, генерацію зображень та перевірки карти сайту. Іншими словами, шар агентів не вгадує, що робити. Він викликає реальні інструменти з реальним станом.
Цей підхід узгоджується з специфікацією Model Context Protocol і з тим, як я люблю структурувати внутрішні системи: один контракт, кілька клієнтів, без дублювання. Це також полегшило повторне використання тих же дій всередині адміністративної панелі та з зовнішніх клієнтів MCP.
Інструменти, які я відкрив через MCP
Поверхня інструментів широка навмисно. Я хотів, щоб агенти виконували корисну роботу, а не просто спілкувалися.
Цей дизайн інструментів є основою mcp cms. Він зберігає систему композабельною і робить кожну операцію спостережуваною.
Чому ця архітектура важлива в реальній роботі
У моїй роботі зі створення веб-сайтів та контентних систем найбільша вузька місце рідко є написанням. Вузьке місце - це координація. MCP зменшує витрати на координацію, оскільки ту ж дію можна викликати з панелі, інтерфейсу чату або іншого потоку агентів. В результаті я витрачаю менше часу на повторення кроків і більше часу на покращення результатів.
Адміністративна панель перетворює MCP CMS на контрольну кімнату
Я не хотів, щоб адміністративна область відчувалася як нудний екран CRUD. Я побудував її як контрольну кімнату. Вона має управління постами для чернеток, перекладів, зображень, SEO та публікації, плюс операційний шар, де я можу запускати AI-робочі процеси та спостерігати за їх рухом.
Всередині панелі MCP чат відкриває ті ж інструменти контенту, що й решта системи. Я можу перерахувати пости, перевірити чернетку, запустити SEO-аналіз, розпочати дослідження або запустити повний конвеєр з запитом природною мовою. Важлива частина полягає в тому, що чат не є магією. Він ґрунтується на тих же типізованих діях, які використовує решта mcp cms.
Цей дизайн економить час на практиці. Мені не потрібно перебудовувати інтерфейси для кожного нового робочого процесу. Я просто відкриваю ще один інструмент або ще один контрольний шлях. Якщо ви хочете побачити, як я думаю про автоматизацію на системному рівні, Як я створив свій CMS з MCP та Agent Flows є більш широкою статтею про цю конфігурацію.
Що я можу робити з панелі
Панель дозволяє мені швидко рухатися, не втрачаючи контролю.
Чому я використовую контрольну кімнату замість простого редактора
Простий редактор працює, коли вам потрібно лише писати та публікувати. Мені потрібно більше. Я хотів місце, де я міг би спостерігати за робочими процесами, затверджувати зміни та втручатися, коли модель відхилялася від курсу. Це справжня цінність mcp cms: вона дає мені оперативний контроль, а не лише введення контенту.
Як насправді працює Agent Flow MCP CMS
Agent flow не є одним величезним запитом. Я розділив його на етапи, щоб я міг контролювати якість на кожному кроці. Це важливо, оскільки робота з контентом є безладною. Дослідження, SEO, структура та редагування потребують різного мислення.
Ось потік, який я використовую найчастіше:
Я тестував цей потік неодноразово, оскільки не хотів фальшивої демонстраційної лінії. Я хотів систему, де один етап може надсилати зворотний зв'язок іншому етапу. Цей зворотний зв'язок є однією з причин, чому mcp cms працює краще, ніж асистент написання з одного проходу.
Чому я розділив потік на етапи
Кожен етап вирішує різну проблему. Дослідження зменшує галюцинацію. SEO уточнює структуру. Редагування захищає якість. Публікація очищає фінальний вихід. Розділення цих завдань робить всю систему більш надійною та легшою для покращення з часом.
Як я утримую агентів від відхилення
Я тримаю агентів на короткому повідку з типізованими входами, явними виходами та перевірками якості. Це дає мені кращий результат, ніж неясний ланцюг запитів. Це також робить невдачі легшими для діагностики, що важливо, коли ви покладаєтеся на автоматизацію для виробничої роботи.
Search Console робить MCP CMS розумнішим
Однією з найсильніших частин системи є те, що я не покладаюся лише на запити. Я підключаю дані Search Console до процесу дослідження, тому агенти працюють з реальними сигналами попиту, а не з припущеннями. Це покращує етап вибору теми та допомагає мені пріоритизувати контент, який насправді може зайняти позиції.
Шар Search Console зберігає знімки в Supabase та обчислює можливості ключових слів, сторінки з низьким CTR та прогалини в контенті. Я використовую ці інсайти всередині mcp cms, щоб керувати як дослідженням, так і SEO. Це означає, що система не просто генерує статті. Вона допомагає мені приймати кращі рішення щодо публікації.
Документація Google Search Console підтверджує, чому це важливо: дані про продуктивність пошуку повинні керувати оптимізацією, а не лише інтуїцією. Я використовую цей принцип безпосередньо в конвеєрі.
Що дає мені шар даних
Чому дані переважають інтуїцію тут
Мені подобається творча робота, але стратегія контенту потребує доказів. Коли я використовую сигнали Search Console, я можу бачити, які сторінки потребують допомоги, а які теми заслуговують нових статей. Це робить mcp cms набагато кориснішим, ніж статична адміністративна панель.
Чому я розділив шляхи читання та запису
Я навмисно розділив сторону читання та сторону запису блогу. Публічні сторінки читають лише через шар контенту, тоді як адміністративні дії записують через шар мутацій. Це зберігає швидкість рендерингу та безпеку публікації.
Це розділення важливе, оскільки кожна сторона має різну роботу. Шар читання потребує кешування, метаданих та чистої поведінки за замовчуванням. Шар запису потребує автентифікації, валідації та контрольованих мутацій. У mcp cms обидва шари ділять ті ж контракти, але ніколи не змішуються.
Це розділення також полегшує додавання майбутніх інтерфейсів. Якщо я створю ще одну панель, або якщо я підключу ще одного клієнта MCP, мені не потрібно переробляти всю систему. Я просто вказую нові інструменти на ту ж межу запису.
Що захищає це розділення
Чому я віддаю перевагу цій структурі
Я бачив, як системи зазнають невдачі, оскільки все спілкується з усім. Ця архітектура зменшує цей ризик. Вона надає mcp cms стабільне ядро і зберігає продукт легким для еволюції.
Реальні результати та практичні компроміси
Найбільшим результатом не була розкішна панель. Це був важіль. Тепер я можу переходити від ідеї до дослідженого контуру, до чернетки, до SEO-огляду, не стрибаючи між інструментами. Це економить час і зберігає контекст.
Я також отримую кращу видимість того, що робить система. Я можу спостерігати за конвеєром, перевіряти рішення агентів і коригувати потік, коли це потрібно. Це важливіше, ніж проста швидкість автоматизації. Хороший mcp cms повинен зміцнювати ваш процес, а не робити його більш непрозорим.
Однак є компроміси. Кастомна система вимагає більше інженерних зусиль, ніж готовий CMS. Ви володієте помилками, функціями та обслуговуванням. Для мене ця вартість виправдана, оскільки робочий процес підходить для мого сайту та моєї контентної стратегії.
Що я отримав
Що я все ще маю управляти
Як я тепер думаю про операційні системи контенту
Цей проект змінив моє уявлення про інфраструктуру контенту. Я більше не бачу програмне забезпечення CMS як місце для зберігання постів. Я бачу це як операційну систему для створення, перегляду та публікації контенту. Цей зсув у свідомості - ось чому цей mcp cms відчувається корисним, а не декоративним.
Якщо ви створюєте щось подібне, почніть з робочого процесу спочатку. Потім визначте межу запису. Після цього додавайте інструменти MCP лише для дій, які заслуговують на автоматизацію. Цей порядок зберігає систему здоровою.
Я також рекомендую прочитати мої пов'язані статті про AI агенти, масштабування електронної комерції з Next.js та мою SEO панель. Ці матеріали пояснюють будівельні блоки цієї конфігурації та показують, як частини з'єднуються.
Висновок
Основні уроки з цього побудови прості:
Я створив цей mcp cms, щоб дати собі важіль, кращу видимість та чистіший робочий процес публікації. Якщо ви проектуєте свою власну контентну систему, почніть з робочого процесу, а потім формуйте інструменти навколо нього.
Якщо хочете, прочитайте пов'язані пости вище або залиште коментар про те, як би ви структурували свій власний CMS.