Що розкриває Blender MCP щодо створення корисних серверів MCP

Більшість інженерних робіт починається з знайомої схеми: хтось запускає створений вами додаток.

Ви проектуєте панель керування, вирішуєте, де розмістити кнопки, та намагаєтесь чітко показати важливі дії. Користувач користується частиною вашого інтерфейсу та виконує своє завдання.

Все частіше виникає цікаве питання: що станеться, коли ця сама людина вже має відкритого штучного інтелект-асистента та просто попросить його виконати завдання безпосередньо?

Чи справді користувачеві потрібно взагалі відкривати вашу панель керування?

Іноді відповідь все ще «так». Заміна функціональної кнопки на три абзаци діалогу — це не покращення. Але для багатьох робочих процесів примушування когось користуватися навігацією вашого додатку є лише зайвими труднощами, які не додають жодної цінності.

Це основна причина, чому сервери MCP, ймовірно, стануть ще важливішими. Blender MCP є гарним прикладом того, як це може виглядати на практиці, а також піднімає деякі менш привабливі питання щодо того, як з часом створювати, підтримувати та оцінювати такі інтеграції.

Саме ці менш привабливі питання стали мотивацією для роботи над Pulse.

Що таке MCP та як працюють сервери MCP?

MCP — це скорочення від Model Context Protocol, відкритого стандарту для підключення AI-застосунків до зовнішніх інструментів та джерел даних. Сервер, побудований за цим стандартом, може надавати інструменти для виконання дій, ресурси для надання контексту та запити, які можна повторно використовувати. У цій статті йдеться саме про інструменти.

Архітектура розділяє додаток ШІ, який називається хостом, від клієнтів та серверів MCP, з якими він взаємодіє. Хост відповідає за організацію цієї взаємодії. Клієнт дізнається, які інструменти доступні, викликаючи tools/list, а потім запускає обраний інструмент за допомогою tools/call. Сервер виконує фактичну логіку та надсилає результат. Самі сервери можуть розміщуватися локально або бути доступними на відстані.

Для простої інтеграції продукту послідовність дій може виглядати приблизно так:

User asks for something
 → AI application selects an available tool
 → MCP client sends the call
 → Your MCP server checks access and runs the operation
 → Result returns to the AI application

Сам MCP не впливає на те, чи повинен модель скористатися певним інструментом, чи має сенс запит користувача, або чи є кінцева відповідь корисною. Протокол з’єднує компоненти між собою, але зовнішній додаток все одно має керувати їхньою спільною роботою.

Відправка сервера також не гарантує, що кожен AI-асистент автоматично його прийме. Наприклад, VS Code вимагає чітких кроків для встановлення, налаштування та надання довіри серверу MCP. Існує реальний бар’єр у сфері інтеграції та прав доступу, який потрібно подолати.

Що насправді демонструє Blender MCP

Проект, створений спільнотою ahujasid/blender-mcp, з’єднує AI-клієнти з Blender за допомогою сервера MCP на основі Python у поєднанні з додатком для Blender. Він може аналізувати сцени, маніпулювати об’єктами та матеріалами, а також виконувати код на Python безпосередньо всередині Blender. Варто зазначити, що це інтеграція від стороннього розробника, а не щось, що постачається Blender офіційно.

Його архітектура виглядає приблизно так:

AI application / MCP client
  ↕ MCP
Python MCP server
  ↕ Project-specific socket connection
Blender add-on
  ↕
Blender scene and operations

Це розділення є важливим. MCP керує інтерфейсом між клієнтом та сервером. Те, що відбувається між сервером та Blender, повністю залежить від реалізації. Будь-який сервер MCP все одно потребує власного механізму для керування базовим програмним забезпеченням.

Що тут варто зазначити, так це те, що всі реальні операції все одно виконуються всередині Blender. Додаток, його існуючий набір функцій та можливість перевірки змін залишаються ключовими елементами.

Ця схема, ймовірно, буде спостерігатися також у інших типах програмного забезпечення: хтось просить про певну зміну, перевіряє результат у знайомому інтерфейсі та повертається до ручної роботи, коли це швидше.

Це здається набагато реалістичнішим, ніж очікувати, що люди кинуть свої існуючі інструменти та будуть робити все через вікно чату.

MCP проти API: що насправді змінюється?

Сервер MCP може легко працювати поверх існуючого API. Він може обгортати базу даних, локальну бібліотеку чи спеціально створений міст, як-от той, що використовується у Blender MCP. Впровадження MCP не змушує вас перебудовувати свій бекенд лише через те, що тепер його викликає штучний інтелект.

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

Корисно розглядати це як третю точку входу до продукту, що знаходиться поруч із існуючим користувацьким інтерфейсом та існуючим API.

Візьмемо систему інвентаризації як приклад. Бізнес-логіка вже знає, як знаходити продукт, перевіряти наявність його у запасах та бронювати певну кількість. Повторне використання цієї логіки є набагато доцільнішим, ніж створення паралельної реалізації лише для обслуговування допоможника ШІ.

Проте аргументи на користь MCP не є безумовними. Якщо ви працюєте з одним внутрішнім скриптом, який взаємодіє з одним відомим API, безпосередня викликання, ймовірно, все ще залишається найпростішим способом. MCP стає корисним тоді, коли вам дійсно потрібна сумісність між кількома клієнтами ШІ, або коли інтерфейс переосмисленого інструменту допомагає вирішити конкретну проблему. Додавання ще одного протоколу лише через те, що він зараз популярний, означає ще один протокол, який доведеться підтримувати.

Створення інструментів MCP — це також проектування інтерфейсу

Саме цьому етапу варто приділити більше уваги.

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

Для гіпотетичного додатку каталогу розумне початкове визначення може виглядати так:

{
  "name": "search_catalog",
  "description": "Find products in the authorized catalog by name or SKU. Returns product IDs, names, and availability. Read-only; does not reserve stock.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "minLength": 1 },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query", "limit"],
    "additionalProperties": false
  }
}

Це призначено як ілюстрація визначення інструменту, а не повної реалізації на сервері чи справжнього інструменту MCP у Blender. Назва, опис та формат вхідних даних JSON Schema, наведені тут, відповідають формату, визначеному MCP.

У описі чітко зазначено, що може шукати інструмент, що він повертає та що він навмисно не робить. Його вхідні дані мають вузьку сферу застосування. Зберігання запасів навмисно залишається окремою дією, оскільки вона має інші наслідки, ніж просте пошук.

Проте позначення чогось як „дозволеного“ у описі не робить це таким насправді. Фактичне застосування механізмів контролю доступу та перевірки вхідних даних має відбуватися під час реалізації. Будь-які дії з реальними наслідками також потребують відповідного кроку підтвердження. Керівні принципи безпеки MCP для інструментів безпосередньо стосуються цих обов’язків.

Blender MCP чітко ілюструє цей компроміс: його інструмент виконання коду на Python справді потужний, а сам проект прямо попереджає про небезпеки дозволу асистенту виконувати довільний код.

Для власних інструментів у продакшені варто починати з найменшого набору дозволів, який справді є корисним, розширюючи його лише тоді, коли є конкретна причина. Також варто тестувати інструменти на реальних запитах. Опис, який зрозумілий вам, не є доказом того, що агент правильно його інтерпретуватиме та використовуватиме.

Як дізнатися, чи корисний сервер MCP?

Функціональна демонстрація відповідає лише на одне вузьке питання: чи взагалі працює цей процес?

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

Візьмемо сервер каталогу як приклад. Ви захочете знати, чи справді викликається функція search_catalog, чи сповільнює відправка нової версії її обробник, та чи збігаються збої навколо певної операції, чи розподіляються рівномірно.

Тут також потрібна обережність під час інтерпретації. Збільшення кількості викликів інструментів може свідчити про виконання справді корисної роботи. Або ж це може означати, що агент намагається знову виконати те, що мало спрацювати вже при першій спробі. Сама кількість викликів не дозволяє розрізнити ці дві зовсім різні ситуації.

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

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

Усе це не повинно об’єднуватися в один зелений індикатор статусу, який приховує ці відмінності.

Чому я створюю Pulse для аналітики MCP

Саме ці запитання стали причиною створення Pulse — SDK з відкритим кодом, яке поєднується з необов’язковим хмарним сервісом, що розташований окремо.

Ви можете знайти публічний репозиторій проекту за адресою github.com/selimeneserd/pulse-sdk, а позначка „любиме“ там допоможе іншим його знайти.

Він оприлюднений під ліцензією MIT. Бібліотека стежить за завершенням роботи обробників інструментів MCP та може надсилати ці метадані до локальної точки призначення, до збирача, яким ви керуєте, або через необов’язковий експортер OpenTelemetry. Для його використання не потрібно реєструватися в Pulse Cloud, і в інтеграції немає жодної стандартної хмарної точки кінцевого призначення, яка б була вбудована.

Мінімальна локальна налаштування виглядає приблизно так:

import { McpServer } from '@modelcontextprotocol/server';
import { createPulse } from '@reviseflow/pulse';
import { createJsonlExporter } from '@reviseflow/pulse-core/jsonl';

const analytics = createPulse({
  environment: 'development',
  exporter: createJsonlExporter({
    path: './catalog-events.jsonl',
  }),
});

const server = analytics.wrapServer(
  new McpServer({ name: 'catalog-server', version: '1.0.0' }),
);

// Register tools on `server`, then connect your existing MCP transport.

Цей фрагмент призначений для ілюстрації механізму вимірювання, а не для створення повноцінної реалізації сервера. Він написаний для Pulse 0.2.1 та версії 2.0.0 бібліотеки @modelcontextprotocol/server, причому серед підтримуваних середовищ виконання є Node.js 24.20.0. Просте реєстрація інструменту сама по собі не створює жодних подій аналітики; це відбувається лише під час фактичного виклику обробників. При грайсовому завершенні роботи, після того як обробники, що працюють зараз, завершать свою роботу, використовується команда await analytics.shutdown({ timeoutMs: 2_000 }).

Цей конкретний приклад стосується сервера MCP на основі TypeScript. У SDK наразі немає адаптера для Python, який би підтримував щось на кшталт Blender MCP.

Pulse Cloud забезпечує шар керованого зберігання та панель керування, які використовують ці метадані: закономірності використання інструментів, тривалість їх роботи, статус результату, а також можливість фільтрації за середовищем чи версією. Він працює за допомогою власного потоку телеметрії, тому справжній трафік інструментів ніколи не проходить через нього.

Надсилання даних до Cloud є добровільним та прямим, воно здійснюється через HTTP-експортер за допомогою URL-адреси збирача та ключа запису з боку сервера. Сам продукт Cloud є закритим, тоді як базовий шар інструменталізації залишається повністю відкритим та може використовуватися окремо.

Важливо чітко дотримуватися цих меж. Розробник, який віддає перевагу запису даних у локальні файли JSONL або вже має систему для моніторингу, має всі підстави використовувати шар з відкритим кодом, не обов’язково стаючи споживачем послуг Cloud.

Чесний аналіз вимагає чітких меж

Телеметрія Pulse навмисно не включає первинні запити, аргументи інструментів, результати їх роботи, текст помилок, стек-трейси та заголовки запитів. Навіть щось настільки просте, як назва інструменту чи технічна мітка, потребує уважної перевірки, адже самі метадані можуть видалити конфіденційну інформацію. Будь-які необов’язкові ідентифікатори облікових записів за своєю суттю є псевдонімними, що не гарантує повної анонімності.

Те, де закінчується збір даних, є таким же важливим, як і те, що саме він збирає. Pulse може бачити, що обробник був запущений та скільки часу це зайняло, але він не має можливості дізнатися, чому модель обрала саме цей інструмент, що насправді намагався досягти користувач чи чи був кінцевий бізнес-результат задовільним. Крім того, він не може записати дзвінок, який було заблоковано ще до того, як він узагалі дістався обробнику.

Надсилання телеметриї здійснюється за принципом „найкращих зусиль“: черги мають певні обмеження та відбуваються спроби повторного надсилання, але ніщо не гарантує отримання кожної події. Пропущена подія телеметрії ніколи не впливає на фактичний результат роботи інструменту, який отримує користувач, але це означає, що в даних можуть бути прогалини. Ця система призначена для аналітики, а не для створення недоступної до фальсифікації історії аудиту.

З огляду на це, здається більш чесним прямо описати ці обмеження, ніж називати функцію „спостережуваністю“ та залишати людей у невизначеності щодо того, що насправді відстежується.

Майбутнє

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

Чи може асистент справді забезпечити ту функціональність, яка потрібна користувачеві? Чи легко зрозуміти та осмислити дії, які він виконує? Чи може людина втрутитися та перевірити все важливе перед тим, як це станеться? І чи буде інтеграція продовжувати працювати, коли початкова новизна зникне?

Blender MCP вирізняється тим, що пропонує конкретний приклад асистента, який працює з реальним, вже існуючим програмним забезпеченням, а не просто говорить про нього. Такий підхід здається більш перспективним, ніж ще один чат-бот, основною функцією якого є опис кроків, які користувач може виконати самостійно десь ще.

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

Сам Pulse може стати ранньою інвестицією, але незрозуміло, наскільки швидко ця практика стане стандартною. Проте основні інженерні проблеми, пов’язані з нею, варто вирішувати вже зараз: розробляти справді корисні інструменти, встановлювати розумні межі дозволів, забезпечувати надійну роботу та бути чесними щодо того, як ці інструменти використовуються на практиці.

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

Якщо ви самі розробляєте такий сервер, як ви вирішуєте, які інструменти справді варто зберегти?

Пов’язана література

• MCP для AI-агентів: стандартизація інтеграції інструментів у LangGraph — У цій статті пояснюється, що саме стандартизує MCP у системах AI-агентів, порівнюючи спеціальні інтеграції інструментів з тими, що базуються на MCP у механізмі оркестрації LangGraph.
• Уроки випуску SaaS на базі Next.js та створення CLI-інструменту — Описуються основні рішення, пов’язані з вибором технологій, автентифікацією, мультиорендою, обліком та керуванням станом, а також процес створення CLI-інструменту для спрощення налаштування проектів Next.js.