Что раскрывает Blender MCP о создании полезных серверов MCP

Большинство инженерных проектов начинаются с знакомой схемы: кто-то открывает приложение, созданное вами.

Вы проектируете панель управления, решаете, где будут располагаться кнопки, и стараетесь четко показать важные действия. Пользователь использует небольшую часть вашего интерфейса, чтобы выполнить свою задачу.

Все чаще возникает интересный вопрос: что происходит, когда у того же человека уже открыт ИИ-ассистент, и он просто просит его выполнить задачу напрямую?

Действительно ли пользователю нужно открывать вашу панель управления?

Иногда ответ все еще «да». Замена рабочей кнопки на три абзаца обмена сообщениями — это не улучшение. Но во многих рабочих процессах принуждение пользователя к использованию навигации вашего приложения лишь создает лишние трудности без какой-либо пользы.

Именно по этой причине серверы MCP, скорее всего, станут ещё более важными. Blender MCP — хороший пример того, как это может выглядеть на практике, и он также поднимает некоторые менее очевидные вопросы относительно того, как со временем создавать, обслуживать и оценивать такие интеграции.

Именно эти менее очевидные вопросы стали движущей силой разработки Pulse.

Что такое MCP и как работают серверы MCP?

MCP — это сокращение от Model Context Protocol, открытого стандарта для подключения ИИ-приложений к внешним инструментам и источникам данных. Сервер, построенный на этом стандарте, может предоставлять инструменты для выполнения действий, ресурсы для формирования контекста и шаблоны запросов, которые можно повторно использовать. В данной статье рассматриваются именно инструменты.

Архитектура разделяет приложение ИИ, называемое хостом, от клиентов и серверов 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 не влияет на то, должен ли модель использовать тот или иной инструмент, имеет ли смысл запрос пользователя или является ли окончательный ответ приемлемым. Протокол соединяет компоненты между собой, но приложение, в котором они используются, всё равно должно контролировать их совместную работу.

Отправка сервера также не гарантирует, что каждый ИИ-ассистент автоматически его обнаружит. Например, для VS Code требуются явные действия по установке, настройке и предоставлению доверия серверу MCP. Существует реальный барьер в области интеграции и разрешений, который необходимо преодолеть.

Что на самом деле демонстрирует Blender MCP

Проект, созданный сообществом ahujasid/blender-mcp, соединяет ИИ-клиенты с 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. Он также может оборачивать базу данных, локальную библиотеку или специально созданный мост, как в случае с MCP для Blender. Внедрение 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 — open-source 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 для ИИ-агентов: стандартизация интеграции инструментов в LangGraph — В этой статье объясняется, что именно стандартизирует MCP в системах ИИ-агентов, сравниваются специфические интеграции инструментов с теми, что основаны на MCP в рамках оркестратора LangGraph.
• Уроки развертывания SaaS на Next.js и создания CLI-инструмента — В статье рассматриваются основные решения, связанные с выбором технологической стека, аутентификацией, мультиарендностью, системой оплаты и управлением состоянием, а также процесс создания CLI-инструмента для упрощения настройки проектов на Next.js.