Удалённым MCP-серверам нужна операционная модель

Удалённый MCP-сервер - это операционная граница, а не локальный сервер, к которому приклеили публичный URL. Как только агент получает доступ к инструментам по сети, вы отвечаете за аутентификацию, разделение клиентов, ограничения запросов, совместимость версий, журналы и последствия ситуации, когда модель вызывает не тот инструмент с действующими учётными данными.

Транспорт выбирают по этой границе. Используйте stdio, когда процесс принадлежит одному пользователю на одном компьютере. Используйте Streamable HTTP, когда нескольким клиентам, компьютерам или пользователям нужен общий сервис. Туннели помогают при разработке, но не превращают процесс на ноутбуке в продакшен. Бессерверная среда подходит для коротких вызовов без состояния, если холодный старт укладывается в тайм-аут клиента, а любую операцию в зависимой системе можно безопасно повторить.

Протокол Model Context Protocol заметно изменился в спецификации 2026-07-28. В актуальном Streamable HTTP на уровне протокола нет состояния, хотя уже развёрнутые клиенты и серверы могут работать по более старым версиям с сессиями. Если план хостинга не учитывает согласованную версию протокола, появятся сбои, похожие на случайную маршрутизацию, истёкшие сессии или оборванные потоки. До выбора инфраструктуры решите, какие версии вы поддерживаете.

Транспорт выбирает граница ответственности

Выбирайте между stdio и Streamable HTTP, ответив на три вопроса: кто запускает процесс, кто может его вызывать и где хранятся его учётные данные. Задержка и цена хостинга идут следом. Транспорт, который противоречит модели ответственности, навсегда добавляет работу по защите и поддержке.

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

Streamable HTTP превращает сервер в независимо управляемый сервис. Клиенты отправляют JSON-RPC-запросы на HTTP-эндпоинт, а сервис может находиться за шлюзом, балансировщиком нагрузки или в частной сети. Такая схема подходит, когда команде нужна единая контролируемая реализация, когда SaaS-продукт открывает инструменты для конкретных пользователей или когда клиенты не могут установить сервер локально. Серверу при этом приходится определять вызывающую сторону и проверять права для каждой операции.

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

Для решения пригодятся четыре вопроса:

• Клиент владеет компьютером и запускает сервер? Выбирайте stdio.
• Два или более компьютера должны использовать одну и ту же серверную установку? Выбирайте HTTP.
• Инструмент работает с учётными данными, которые нельзя выносить с компьютера пользователя? Оставьте его локальным, если не можете переделать передачу учётных данных.
• Администраторы должны централизованно отзывать доступ и просматривать вызовы с привязкой к личности? HTTP даёт подходящую точку контроля.

Гибридные схемы тоже имеют право на жизнь. Небольшой адаптер stdio может сохранять локальные учётные данные и пересылать на удалённый сервис запросы с узкими полномочиями. Такой адаптер должен создавать настоящую границу, например локально подписывать или фильтровать данные. Обёртка, которая без изменений пересылает все инструменты и аргументы, лишь добавляет ещё один компонент для отладки.

Stdio безопаснее локально, но не безопасен сам по себе

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

Спецификация транспорта MCP предъявляет необычно строгие требования к двум выходным потокам. Сервер читает корректные сообщения JSON-RPC из stdin, записывает в stdout только сообщения протокола, а диагностику отправляет в stderr. Один безобидный отладочный вывод в stdout может нарушить разбиение сообщений. Часто ошибка проявляется только в собранном пакете, потому что в среде разработки и продакшене у регистратора разные настройки по умолчанию.

В обёртке запуска передавайте разрешённый список переменных среды, а не всю среду оболочки. Явно задайте рабочий каталог. Запускайте процесс от пользователя, который не может читать посторонние репозитории или материалы SSH. Если сервер вызывает такие программы, как клиент базы данных или система контроля версий, закрепите полный путь к исполняемому файлу и не доверяйте PATH. Эти меры не дадут управляемому через промпт аргументу найти неожиданную программу в начале пути поиска.

Минимальная конфигурация запуска должна наглядно показывать полномочия:

{
  "command": "/opt/mcp/bin/inventory-server",
  "args": ["/work/inventory", "read_only"],
  "env": {
    "INVENTORY_API_URL": "https://inventory.internal",
    "LOG_LEVEL": "info"
  }
}

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

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

Streamable HTTP задаёт контракт сервиса

Операционные затраты на Streamable HTTP оправданы, когда удалённым MCP-серверам нужны общий доступ, централизованные правила или независимые релизы. Он работает на обычной HTTP-инфраструктуре, но полезная нагрузка по-прежнему подчиняется семантике JSON-RPC, правам инструментов и поведению конкретной версии MCP. Обычный обратный прокси не добавит эту семантику за вас.

В актуальном протоколе 2026-07-28 каждый запрос самодостаточен. Старого обмена initialize и initialized больше нет, как и протокольного Mcp-Session-Id. В запросах передаётся MCP-Protocol-Version, а Mcp-Method и, для именованных операций, Mcp-Name открывают шлюзам сведения для маршрутизации. В официальных примечаниях к релизу сказано, что любой запрос может попасть на любой экземпляр при балансировке по кругу. Для состояния протокола это верно. Состоянию приложения всё равно нужен явный дескриптор, запись в базе данных, задание в очереди или другое общее представление.

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

Старые версии усложняют картину. Streamable HTTP в спецификациях 2025 года мог выдавать Mcp-Session-Id, держать открытыми потоки Server-Sent Events и требовать привязки сессии к экземпляру или общего хранилища сессий. Более старый транспорт HTTP+SSE использовал отдельную схему подключений, и теперь он устарел. Если вы поддерживаете такие клиенты, маршрутизируйте их по согласованной версии и проверяйте полный жизненный цикл. Сервер, который принимает инициализацию, теряет сессию при масштабировании и отвечает 404 на следующий вызов инструмента, технически сообщает о потере состояния, но для пользователей продукт будет просто ненадёжным.

Начинайте с обычной модели запрос-ответ, если поддерживаемая версия и сам инструмент не требуют потоковой передачи или подписок. Открытые потоки занимают соединения прокси, усложняют корректное завершение при развёртывании и сталкиваются с тайм-аутами простоя на нескольких уровнях. Потоковая передача может сократить субъективное ожидание длинного ответа, но не ускоряет саму операцию. Дескриптор задания с опросом состояния часто легче восстановить после того, как мобильное подключение сменило сеть.

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

Варианты хостинга меняют контроль на операционную работу

Лучший хостинг - самый простой вариант, который удовлетворяет требованиям сервера к задержке, изоляции, масштабированию и сети. Нагрузка удалённого MCP обычно неравномерна: долгие периоды тишины сменяются всплеском обнаружения инструментов и вызовов, когда агент начинает работу. Средняя загрузка процессора почти ничего не говорит об этом режиме.

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

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

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

Кластер Kubernetes оправдан, если компания уже эксплуатирует его и нуждается в его сетевых правилах, идентификации нагрузок или управлении размещением. Сам по себе MCP не оправдывает кластер. Протокол не становится безопаснее от того, что у пода есть YAML-файл. Кому-то всё равно придётся определить аутентификацию на входе, ограничения исходящего трафика, секреты, поведение при сбоях и авторизацию для каждого инструмента.

Пограничные среды привлекают глобальным завершением TLS и малой задержкой подключения. Проверьте поддержку серверного SDK, потоковой передачи, криптографии, исходящих сокетов и длительности ответа. Если каждый инструмент сразу обращается к региональной базе данных, перенос одного MCP-эндпоинта на периферию может добавить ещё один сетевой участок и не сократить общее время. Размещайте выполнение рядом с медленной или чувствительной зависимостью, а глобальный шлюз используйте только там, где он действительно помогает.

Сравнивайте варианты по измерениям одного показательного вызова инструмента, а не эндпоинта hello world. Постоянная виртуальная машина подходит небольшому внутреннему сервису со стабильной нагрузкой, но нужно проверить перезапуск процесса во время вызова. Управляемый контейнер подходит общему сервису без состояния, однако прямой проверки требуют ограничения платформы, минимальное число экземпляров и давление масштабирования на квоты зависимых систем. Бессерверная функция подходит коротким независимым операциям, если повтор после тайм-аута не дублирует работу. Готовый Kubernetes подходит нагрузкам, которые уже зависят от политик кластера, но стоит проверить остановку, перенос и сетевые правила при сбоях. Пограничная среда подходит лёгким вызовам рядом с распределёнными пользователями, только если её ограничения и путь к региональной системе не обрывают и не задерживают работу.

Туннели дают доступ, но не доверие

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

Опасная схема выглядит так: локальный сервер без аутентификации слушает 0.0.0.0, после чего команда туннеля создаёт публичный URL. Такой сервер мог унаследовать облачные учётные данные и доступ к репозиторию. Случайный URL не считается секретом, а журналы доступа туннеля не исправляют отсутствие авторизации в приложении. Требуйте аутентификацию в самом MCP-сервисе даже для короткого теста и ограничивайте тестовые учётные данные одноразовыми данными.

Привяжите сервер разработки к 127.0.0.1, затем направьте туннель на этот слушатель. Спецификация транспорта MCP предписывает локальным HTTP-серверам слушать localhost и проверять заголовок Origin, чтобы снизить риск атаки с подменой DNS. Проверка Origin не заменяет аутентификацию. Небраузерные клиенты могут не отправлять Origin, а разрешённый веб-источник ничего не говорит о том, какой сотрудник или клиент вызвал инструмент.

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

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

Холодный старт расходует бюджет тайм-аута клиента

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

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

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

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

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

Настройте тайм-ауты с уменьшением от клиента вглубь системы. Клиент должен ждать дольше шлюза, шлюз дольше крайнего срока приложения, а приложение дольше тайм-аута своей зависимости. Такой порядок даёт серверу шанс вернуть точную ошибку до того, как внешний слой оборвёт соединение. Он также оставляет время записать, завершился ли побочный эффект.

Защита следует за полномочиями инструмента

Частная сеть снижает открытость, но не устанавливает личность вызывающей стороны. Идентификация нагрузки на шлюзе может определить клиентский сервис, а делегированная личность пользователя сообщает обработчику, чьи данные и права применяются. Во многих внутренних установках есть только первое. Тогда каждый сотрудник действует через одну общую сервисную учётную запись, поэтому невозможно отозвать доступ у одного человека или объяснить один разрушительный вызов. Передавайте обе личности, когда сервис действует от имени пользователя, и отклоняйте запрос без полной цепочки делегирования.

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

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

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

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

Для удалённого HTTP используйте TLS и краткосрочные bearer-токены, полученные через модель авторизации MCP или равноценный механизм под контролем организации. Актуальная спецификация опирается на соглашения OAuth и метаданные защищённого ресурса. К bearer-токенам применимо предупреждение RFC 6750: для их использования достаточно владения. Никогда не помещайте их в URL, аргументы инструмента или журналы. Проверяйте издателя, аудиторию, срок действия, подпись и области прав в сервисе, который на них полагается.

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

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

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

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

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

Совместимость нужно проверять как матрицу

Удалённый MCP-сервер может пройти модульные тесты и всё равно сломаться, потому что клиент, прокси и сервер по-разному понимают версию протокола или потоковую передачу. Опубликуйте поддерживаемые версии и транспорты, а затем проверяйте именно эти сочетания. Случайная совместимость исчезнет при следующем обновлении SDK.

Включите в тесты актуальный клиент без состояния, самый старый поддерживаемый клиент с сессиями и любой устаревший клиент HTTP+SSE, который вы обещали сохранить. Пропустите каждого через тот же вход, что используется в продакшене. Прямые тесты на localhost не обнаружат буферизацию прокси, удаление заголовков, пределы простоя соединения или переписывание пути.

Для допуска релиза полезно проверить такие случаи:

1. Выполните обнаружение или инициализацию по согласованной версии клиента, затем получите список инструментов и вызовите один инструмент чтения.
2. Запустите длинный ответ, перезапустите один экземпляр сервера и убедитесь, что клиент получает определённую ошибку или возобновляет работу только там, где это разрешает версия.
3. Отправьте несовпадающие заголовки Mcp-Method или Mcp-Name и убедитесь, что запрос отклонён до выполнения.
4. Дождитесь истечения или отзовите учётные данные, затем проверьте, что и текущие, и новые запросы теряют доступ согласно проекту.
5. Повторите один изменяющий вызов с тем же идентификатором операции и убедитесь, что побочный эффект случился один раз.

Для каждого сбоя сохраняйте код состояния, ошибку JSON-RPC и запись сервера. Созданный прокси ответ 502, ответ приложения 401 и ошибка инструмента JSON-RPC требуют разных исправлений. Если мониторинг сводит все три к tool_failed, дежурный инженер потратит первые полчаса на воспроизведение того, что телеметрия уже должна была показать.

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

Продакшен должен быть предсказуемым в эксплуатации

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

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

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

При Team & AI Audit я отношу хостинг MCP к операционной модели инженерной команды, потому что умный инструмент, который умеет развёртывать или защищать лишь один разработчик, не снижает расходы команды. Стоит выяснить, устраняет ли сервис повторяющуюся работу и оставляет ли путь поддержки, которым действительно могут владеть один или два инженера.

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