MCP или API для ИИ-интеграций в продакшене

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

Это различие помогает не допустить дорогую ошибку в выборе архитектуры. Команды часто сравнивают MCP-сервер с REST-эндпоинтом так, будто это два конкурирующих варианта бэкенда. Обычно они находятся на разных уровнях. REST открывает программам операции приложения. MCP упаковывает некоторые из этих операций, их описания, схемы и результаты для клиента, которым управляет модель. Дополнительный уровень оправдан, только если повторное использование, обнаружение инструментов и работа агента перевешивают затраты на задержку, авторизацию и эксплуатацию.

MCP - адаптер для агента, а не новый бэкенд

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

Прямая REST-интеграция начинается с разработчика, который знает эндпоинт, метод, форму запроса и ответа, а также схему аутентификации. Приложение решает, когда делать вызов. В MCP-интеграции хост может получить каталог, а модель получает достаточно описаний и схем, чтобы выбрать инструмент и составить аргументы. Хост по-прежнему применяет правила, но модель участвует в выборе. Это другая модель исполнения, а не более красивый HTTP-клиент.

В этой области часто смешивают стандартизацию протокола со стандартизацией смысла. MCP стандартизирует то, как клиент получает список инструментов и вызывает один из них. Он не делает так, чтобы create_customer, open_account и provision_tenant означали одно и то же на трех разных серверах. Имена и описания инструментов, побочные эффекты, области доступа, ошибки и правила предметной области по-прежнему определяете вы. Слабый контракт не станет лучше после обертки в MCP.

Последняя спецификация Model Context Protocol, редакция 2026-07-28, проводит эту границу яснее прежних версий. Каждый запрос несет версию протокола, сведения о клиенте и его возможностях. Из протокола убрали обязательный обмен initialize и транспортную сессию Mcp-Session-Id. Клиент может сразу вызвать инструмент или сначала обратиться к server/discover, если ему нужны сведения о возможностях. Это убирает часть служебного обмена при подключении, но не устраняет обнаружение инструментов, обработку схемы, выбор модели и ваш нижележащий вызов.

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

Выбирайте MCP, когда независимость клиентов окупает затраты

MCP оправдывает себя, когда одна возможность должна работать в нескольких совместимых ИИ-хостах, а вы не хотите делать отдельный адаптер для каждого хоста. Полезная единица повторного использования здесь не один эндпоинт. Это связанный набор понятных модели операций с описаниями, схемами входных данных, безопасными результатами и единым поведением авторизации.

Четыре условия делают выбор убедительным:

• Одна возможность нужна нескольким агентным клиентам сейчас или в обозримом плане.
• Модель должна находить доступные операции, а не идти по заранее заданному приложением пути.
• Возможности полезен общий контракт инструментов, включая описания и аргументы в JSON Schema.
• Одна команда может отвечать за совместимость, авторизацию, наблюдаемость и выпуски сервера.

Локальные инструменты разработчика подходят особенно хорошо. Хост может запустить MCP-сервер через стандартный ввод и вывод, передать учетные данные через окружение процесса и открыть узкий набор инструментов, не поднимая сетевой порт. Официальная спецификация транспорта требует от реализаций stdio обмениваться сообщениями JSON-RPC, разделенными переводами строк, и использовать стандартный вывод только для сообщений протокола. Это скучное правило имеет практический смысл: одна отладочная строка в стандартном выводе может сломать поток. Отправляйте журналы в стандартный поток ошибок.

MCP может быть уместен и для удаленных каталогов возможностей. Представьте акселератор с несколькими внутренними агентами, которым нужен контролируемый доступ к метрикам портфельных компаний, истории поддержки и состоянию инфраструктуры. Один удаленный сервер может показывать стабильные инструменты, пока системы за ним меняются. Выигрыш дает независимость агентных клиентов от изменений в бэкенде. Если одну операцию вызывает только один внутренний процесс, такой сервер может добавить формальности без повторного использования.

Посчитайте потребителей до начала разработки. Фраза «позже у нас могут появиться агенты» не описывает спрос. Назовите хосты, владельцев и нужные им операции. Если вы не можете назвать второго потребителя или объяснить проблему обнаружения, начните с уже существующего API. Адаптер можно добавить после того, как контракт пройдет проверку реальной работой.

Для детерминированных путей продукта оставляйте REST

Прямой API обычно лучше, когда процессом управляет программа, а не модель. Оформление заказа, сброс пароля, прием вебхуков, проводка по реестру и проверка работоспособности не должны спрашивать у модели, какая операция кажется подходящей. Им нужны предсказуемые правила проверки, повтора, тайм-аута и обработки ошибок.

REST также выигрывает, когда внешним разработчикам нужна широкая публичная поверхность. OpenAPI может описывать сотни эндпоинтов, генерировать типизированные клиенты, снабжать шлюзы метаданными и поддерживать обычное версионирование. Если открыть всю эту поверхность в виде сотен MCP-инструментов, модели придется разбирать большой каталог, а вероятность плохого выбора вырастет. Агенту обычно нужна небольшая поверхность задач, а не копия справочника по API.

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

В фиксированных процессах у прямых API есть преимущество в безопасности: одному процессу можно дать ровно одну нужную операцию и вообще не открывать каталог на выбор модели. MCP может обеспечить столь же узкие разрешения, но только если сервер правильно сопоставляет личность, области доступа, вызовы инструментов и нижележащую авторизацию. Это отдельная работа. Поддержка протокола не напишет за вас правила доступа.

Нет ничего плохого в совместном использовании обоих подходов. Оставьте REST API исходным контрактом. Разместите MCP перед тем подмножеством операций, которое агенты могут безопасно вызывать. Мобильные приложения, веб-сервисы, пакетные задания и партнеры сохранят детерминированный интерфейс. ИИ-хосты получат инструменты, сформированные вокруг решений, которые модель вправе принимать. Такое разделение также упрощает откат: удаление MCP-адаптера не затронет бэкенд.

Задержка относится ко всему пути вызова

Задержка MCP складывается из транспорта, обнаружения, модели, сервера и нижележащей системы. Если измерять только обработчик сервера, получится приятное число, которого пользователь никогда не увидит. Измеряйте время от решения хоста вызвать инструмент до попадания окончательного результата в следующий ход модели.

Для удаленного вызова инструмента разделите путь на следующие интервалы:

1. Загрузка каталога или чтение из кеша, включая server/discover либо tools/list, если они нужны.
2. Выбор инструмента моделью и формирование аргументов.
3. Сеть и обработка протокола на MCP-эндпоинте.
4. Работа инструмента, включая обращения к нижележащему API и базе данных.
5. Сериализация и передача результата, затем следующий ход модели.

Спецификация 2026-07-28 помогает с двумя частями. Ответы со списками могут содержать подсказки для кеширования, а детерминированный порядок сохраняет каталоги стабильными для кеша промптов. Streamable HTTP дублирует метод и имя инструмента в заголовках Mcp-Method и Mcp-Name, поэтому шлюз может маршрутизировать или учитывать запрос, не разбирая тело JSON. Эти возможности сокращают лишнюю работу. Они не спасут инструмент, который возвращает 80 килобайт, когда модели нужны четыре поля.

Добавьте идентификатор трассировки на границе и записывайте компактный объект с таймингами. Такой формы достаточно, чтобы найти владельца задержки:

{
  "trace_id": "01J...",
  "tool": "triage_incidents",
  "catalog_ms": 0,
  "model_select_ms": 418,
  "mcp_transport_ms": 27,
  "downstream_ms": 183,
  "result_bytes": 2461,
  "total_ms": 711
}

Не придумывайте бюджет задержки, копируя чужой тест. Выполните одну пользовательскую задачу через прямую интеграцию и через MCP, отдельно с прогретым и холодным каталогом. Запишите p50 и p95 для каждого интервала, долю ошибок, повторы, размер результата и токены модели. Сравнение должно использовать одну модель, регион, операцию бэкенда и содержимое результата. Иначе вы измеряете разные системы.

Локальный stdio исключает сетевую передачу, но при каждом запуске процесса все равно платит за старт, если хост не держит сервер готовым. Удаленный HTTP не требует локальной установки, зато добавляет сеть и авторизацию. Для долгих операций используйте расширение Tasks или идентификатор задания из вашей предметной области, если клиенты это поддерживают. Не держите обычный запрос открытым несколько минут и не называйте это стратегией интеграции.

Удаленная авторизация - часть продукта

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

Для HTTP-транспортов текущая спецификация авторизации MCP опирается на OAuth. MCP-сервер работает как защищенный ресурс. Он публикует метаданные защищенного ресурса по RFC 9728, указывает клиентам сервер авторизации и отвечает на запросы без нужных прав заголовком WWW-Authenticate. Клиенты используют метаданные сервера авторизации или обнаружение OpenID Connect, запрашивают токены для MCP-сервера через параметр resource из RFC 8707 и применяют PKCE для защиты кода авторизации. Редакция 2026-07-28 также требует проверки издателя по RFC 9207.

Это похоже на обычный вход через браузер, потому что это и есть такой вход, но у совместимости есть острые углы. Настольные клиенты используют обратные адреса на loopback-интерфейсе. Некоторые корпоративные клиенты приходят с заранее зарегистрированными учетными данными. Предпочтительным способом регистрации теперь стали документы метаданных идентификатора клиента, а динамическая регистрация клиента сохранена для совместимости и объявлена устаревшей. Ваш провайдер удостоверений может поддерживать только часть этого пути. Проверяйте те хосты, которые действительно планируете поддерживать. Список стандартов не заменяет пройденные сценарии входа, обновления, отзыва и повышения прав.

Никогда не передавайте полученный от MCP-клиента токен доступа дальше в нижележащий API. Руководство по безопасности MCP прямо запрещает сквозную передачу токена. Проверьте, что входной токен предназначен MCP-серверу, затем получите или выберите отдельные учетные данные для вышестоящего ресурса. Передача одного bearer-токена через обе границы путает аудитории и может превратить сервер в обманутого посредника.

У локального stdio другая модель. Спецификация говорит, что реализации stdio должны получать учетные данные из окружения, а не использовать поток HTTP-авторизации. Это удобно на рабочем компьютере одного разработчика, но доступ к окружению широк, а о ротации секретов легко забыть. Дайте процессу учетные данные с узкими правами, удаляйте значения окружения из диагностики и решите, вправе ли хост запускать произвольные серверные команды. Локальный процесс не становится безвредным автоматически.

Для служебной автоматизации тоже нужен четкий ответ. Интерактивное пользовательское согласие не подходит для ночного задания без оператора. Используйте поддерживаемый поток машинной идентификации, отдельную внутреннюю политику транспорта или оставьте такой процесс на прямом API. Не прячьте долгоживущий личный refresh-токен в контейнере только потому, что демоверсия так заработала.

Контракт инструмента должен описывать решение, а не эндпоинт

Полезный MCP-инструмент дает модели одно ограниченное решение и достаточно контекста для правильного вызова. Если скопировать каждый REST-путь в отдельный инструмент с теми же параметрами, наружу выйдут детали реализации, а модели придется собирать процессы, которые ваш бэкенд понимает лучше.

Допустим, API инцидентов имеет отдельные эндпоинты для поиска инцидентов, получения хронологии, списка ответственных, назначения ответственного и добавления заметки. Буквальная обертка создаст пять инструментов и попросит модель координировать их. Хороший инструмент чтения можно назвать triage_incidents: он принимает сервис, серьезность, возраст и лимит, а возвращает факты для назначения. Запись оставьте отдельному инструменту assign_incident, чтобы хост мог потребовать подтверждение, а сервер применил более узкую область доступа.

Описаниям нужны рабочие факты, а не рекламный текст. Напишите, когда использовать инструмент, что он изменит, какие идентификаторы ожидает и какое существенное ограничение действует. Входные схемы должны отвергать неоднозначные сочетания. В результате сначала должны идти стабильные поля, затем текст. Текущая спецификация MCP-инструментов поддерживает структурированное содержимое, поэтому клиент может обработать типизированный результат, а модель получит краткое объяснение.

Используйте ошибки, которые подсказывают безопасное следующее действие. Сообщение Invalid request не объясняет ни хосту, ни модели, что исправить. Возвращайте стабильный код ошибки, короткое сообщение и сведения о полях. Различайте неверные аргументы, отказ в доступе, конфликты, ограничения частоты, недоступность нижележащей системы и неизвестный итог. Если запись завершилась тайм-аутом после того, как нижележащая система могла принять запрос, сообщите о неизвестном результате и добавьте ссылочный идентификатор идемпотентности. Не подталкивайте клиента к автоматическому повтору, который способен продублировать действие.

Аннотации и имена инструментов служат подсказками, а не контролем доступа. Даже инструмент с описанием «только для чтения» требует серверной проверки. Модель может неправильно понять текст, клиент может содержать ошибку, а злоумышленник может вызвать эндпоинт без модели. Все разрешения и инварианты должны исполняться кодом за границей протокола.

Миграция может сохранить работающий API

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

Предположим, существующий сервис инцидентов открывает GET /v1/incidents и уже контролирует доступ арендаторов. Первый MCP-инструмент может сопоставить узкую схему этому эндпоинту:

{
  "name": "triage_incidents",
  "description": "Find open incidents that need an owner. Returns facts for triage and changes nothing.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "service": {"type": "string", "minLength": 1},
      "severity": {"type": "array", "items": {"enum": ["sev1", "sev2", "sev3"]}, "maxItems": 3},
      "older_than_minutes": {"type": "integer", "minimum": 0},
      "limit": {"type": "integer", "minimum": 1, "maximum": 25}
    },
    "required": ["service"],
    "additionalProperties": false
  }
}

Обработчик должен брать арендатора из проверенной личности, а не из аргумента модели. Он переносит разрешенные поля в запрос API, применяет серверный лимит, если клиент его не передал, и сокращает ответ до полей, нужных для разбора. Он также передает идентификатор трассировки, но не раскрывает учетные данные нижележащей системы.

validate MCP token audience and scopes
tenant = identity.tenant_id
query = allowlist(arguments, service, severity, older_than_minutes, limit)
response = incident_api.list(tenant, query, downstream_credential)
return compact(response, id, service, severity, opened_at, owner, summary)

Сравните прямой путь и MCP-обертку в теневом режиме, прежде чем агент начнет действовать по результату. Отправляйте один разрешенный запрос обоим, нормализуйте порядок и сравнивайте идентификаторы и поля. Теневой режим не должен дублировать запись. Для будущего инструмента назначения используйте тестового арендатора или режим без исполнения, если исходный API действительно его поддерживает. Если безопасной симуляции нет, проверяйте на контролируемых записях с явным подтверждением.

Добавьте запись как отдельный контракт:

{
  "name": "assign_incident",
  "description": "Assign one open incident to an eligible responder. This changes the incident and requires approval.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "incident_id": {"type": "string"},
      "responder_id": {"type": "string"},
      "reason": {"type": "string", "minLength": 10, "maxLength": 300},
      "idempotency_key": {"type": "string"}
    },
    "required": ["incident_id", "responder_id", "reason", "idempotency_key"],
    "additionalProperties": false
  }
}

Перед запуском проверьте, что пользователь арендатора A не может указать инцидент или ответственного из арендатора B, повторный ключ идемпотентности возвращает исходный результат, отозванное разрешение вызывает отказ, описания в каталоге соответствуют поведению, а каждая запись сохраняет исполнителя, клиента, инструмент, аргументы после удаления секретов, итог и идентификатор нижележащего запроса. Это условия выпуска. Они не относятся к необязательной доводке безопасности.

Одна трассировка должна проходить через оба слоя

Эксплуатация ломается, когда команда MCP видит успешный вызов инструмента, а команда API видит неудачный запрос к бэкенду без общего идентификатора. Передавайте один контекст трассировки через хост, MCP-сервер, шлюз, API и обработчик заданий. Записывайте версию протокола, личность клиента, имя инструмента, выпуск сервера, нижележащую операцию, класс результата и время, но не сохраняйте токены и чувствительные аргументы.

Версионируйте смысловой контракт, даже если протокол остается совместимым. Если сделать limit обязательным, изменить смысл status или убрать поле результата, поведение агента может сломаться без транспортной ошибки. Контрактные тесты должны получать список инструментов, проверять схемы, выполнять показательные вызовы и сравнивать структурированные результаты с эталонами. Проверяйте каждый поддерживаемый хост, потому что клиенты по-разному показывают подтверждения, кешируют каталоги и выводят ошибки.

Относитесь к адаптеру как к производственной системе. Задайте тайм-ауты на границе MCP и более короткие тайм-ауты ниже, чтобы сервер успел вернуть контролируемую ошибку. Ограничьте параллелизм. Учитывайте частоту по личности и инструменту, а не только по IP-адресу. Ограничьте размер результатов. Удаляйте секреты до отправки журналов из процесса. Опубликуйте срок совместимости для редакций протокола и изменений инструментов.

Модель запросов без состояния в последнем протоколе упрощает обычную балансировку нагрузки, но состоянию приложения все равно нужно постоянное место. Если процесс занимает несколько вызовов, верните явный идентификатор задания или процесса, который модель передаст обратно. Храните долговечное состояние в бэкенде. Скрытое состояние в памяти исчезнет при перезапуске и плохо работает при горизонтальном масштабировании.

Небольшая команда способна все это поддерживать, если ответственность определена четко. Проблемы начинаются, когда одна группа владеет описаниями инструментов, другая OAuth, третья API, а за полное действие пользователя не отвечает никто. Назначьте одного владельца сквозного контракта сервиса, даже если его части обслуживают разные команды.

Расходы на совместимость приходят после запуска

Поддержка протокола - это матрица, а не флажок. Сервер, хост, SDK, шлюз и провайдер удостоверений могут поддерживать разные редакции или разные подмножества необязательного поведения. Основной сценарий сработает, а отмена, подсказки кеша, структурированные результаты или восстановление авторизации могут отказать. Зафиксируйте точные поддерживаемые сочетания в тестовой матрице и прогоняйте ее при каждом выпуске.

Редакция июля 2026 года особенно важна, потому что из нее убрали обмен инициализации и протокольную сессию прежних версий. Старые клиенты могут все еще ожидать initialize и Mcp-Session-Id. Новые клиенты отправляют самодостаточные запросы и получают сведения о возможностях только при необходимости. Если приходится поддерживать обе эпохи, следуйте правилам совместимости спецификации или возьмите SDK, который это делает, затем проверьте оба пути. Не пишите обработчик, который гадает по отсутствующему заголовку и незаметно смешивает семантику.

Частый отказ начинается с безобидного переименования инструмента. Команда меняет get_open_incidents на triage_incidents, развертывает сервер и убеждается, что новый каталог выглядит правильно. Один хост сохранил старый список в кеше. Его модель вызывает старое имя, получает ошибку метода, повторяет попытку после еще одного хода модели и сообщает пользователю, что система инцидентов недоступна. API не падал. Протокол оставался исправным. Сбой создали смысловое изменение и устаревший результат обнаружения.

Защититесь периодом совместной работы. Оставьте старый инструмент тонким псевдонимом, отметьте его устаревшим в описании, записывайте метрику его вызовов и удаляйте только после того, как использование упадет до нуля за весь поддерживаемый срок кеширования. Во время этого периода сохраните поведение аргументов и результатов. Если новый инструмент меняет смысл, дайте ему новое имя и не направляйте старые вызовы к поведению, которого они не запрашивали.

Размер каталога требует такого же внимания при эксплуатации. Каждое описание и схема занимают контекст, когда хост загружает каталог, а каждое похожее имя дает модели еще один шанс ошибиться. По мере роста делите серверы по границам доверия или связным предметным областям, а не по случайной структуре организации. Агенту по выставлению счетов не нужно видеть инструменты развертывания только потому, что оба сервиса принадлежат одной платформенной команде. Небольшие каталоги уменьшают доступную поверхность и упрощают разбор оценок.

Оценивайте поведение на наборах задач, а не только на соответствии протоколу. Набор проверок совместимости может доказать, что tools/list возвращает правильный JSON-RPC и что входные данные соответствуют JSON Schema. Он не докажет, что модель выберет read_customer вместо search_customers, запросит подтверждение перед записью или правильно объяснит частичный результат. Соберите типовые промпты, ожидаемые и запрещенные инструменты, ограничения аргументов и допустимые толкования результата. Запускайте их для каждой модели и хоста, поддержку которых обещаете.

Для обнаружения и исполнения нужны независимые средства развертывания. Сначала разрешите выбранным клиентам получать список инструментов. Затем откройте вызовы чтения небольшой группе пользователей. Записи добавляйте с явным подтверждением и серверным списком разрешений. Оставьте аварийный выключатель, который отключает один инструмент, не останавливая сервер, и возвращайте сообщение о том, что операцию отключил администратор. Общая ошибка сервера подтолкнет клиентов к повтору или небезопасной замене.

Откат должен быть столь же понятным. Нужны предыдущий выпуск сервера, прежний контракт каталога и способ отвергать вызовы, добавленные новой версией, не повреждая состояние. Миграции базы данных за инструментом должны оставаться совместимыми с обоими выпусками в период возможного отката. Это обычная производственная дисциплина, но команды пропускают ее, когда считают MCP-сервер файлом промпта с веб-эндпоинтом.

Перед разработкой примените фильтр решений

MCP-сервер должен пройти более строгую проверку, чем «наш агентный фреймворк это поддерживает». Оцените предложенную возможность по реальным потребителям, поведению и эксплуатационным ограничениям. Если несколько ответов остаются расплывчатыми, проект еще не готов.

• Каким конкретным ИИ-хостам это нужно и какую редакцию протокола поддерживает каждый?
• Модели действительно нужно обнаружение или код приложения уже знает операцию?
• Можно ли открыть небольшой контракт задачи вместо копирования всего API?
• Сохранятся ли личность и минимальные права по обе стороны MCP и нижележащей системы?
• Укладывается ли измеренная задержка в пользовательское действие с учетом ходов модели и размера результата?

Затем определите владельца и путь выхода. Одна команда должна отвечать за ошибки аутентификации, изменения схем, различия клиентов и инциденты нижележащей системы. Бэкенд API должен оставаться доступным без слоя MCP, если для жесткой связи нет веской причины. Тогда миграцию можно отменить, а выбор протокола не превратится в бизнес-правило.

Для основателей экономическая проверка проста: посчитайте устраненные адаптеры, открытые процессы и добавленное обслуживание. Общий сервер для четырех реальных агентных клиентов способен сократить повторную работу над интеграциями. Сервер ради одного фиксированного вызова добавляет развертывание, границу авторизации и еще одно дежурство. Оба решения могут быть технически правильными, но владеть стоит только одним из них.

Сначала создайте узкий инструмент чтения, измерьте полный вызов и добейтесь работы авторизации во всех названных хостах. Если этот срез не дает повторного использования или лучшего контракта для агента, остановитесь и оставьте API. Если дает, добавляйте по одному инструменту на каждое ограниченное решение.