Спецификация MCP от 28 июля 2026 года исключает из протокольного взаимодействия начальный обмен initialize / initialized и заголовок Mcp-Session-Id — это зафиксировано в официальном описании изменений. Рекомендация на сейчас: если инструмент нужен нескольким людям или приложениям, планируйте общий сервис через Streamable HTTP; для локальной разработки и доступа к файлам на компьютере оставляйте stdio. На этой неделе проверьте транспорт и версию SDK у каждого клиента до переключения: новая модель без протокольной сессии не отменяет бизнес-состояние, авторизацию и хранение данных.
Кому пригодится этот разбор:
Индивидуальным разработчикам, которые решают, есть ли причина переносить локальный MCP-процесс на сервер.
Небольшим командам, которым нужно предоставить общий доступ к инструментам, не смешивая его с публикацией сервиса в открытом интернете.
Техническим руководителям, планирующим обновление протокола и проверку совместимости.
Развёртывание MCP-сервера самостоятельно в 2026 году: выбор транспорта
Начните не с аренды сервера и не с обновления SDK, а с вопроса, где должен работать инструмент. Если клиенту нужны файлы или процессы на вашем рабочем компьютере, удалённое размещение добавит сетевой маршрут, но не даст автоматической пользы. Если же один и тот же инструмент должен обслуживать несколько клиентских приложений, отдельный удалённый сервис проще централизованно обновлять и контролировать.
Официальная документация различает локальный stdio и удалённый Streamable HTTP. При этом удалённый транспорт — характеристика способа связи клиента с сервером, а не требование сделать endpoint общедоступным: доступ можно организовать в подходящей для команды сетевой среде и ограничить средствами вашей инфраструктуры. Перед реализацией проверьте рекомендации документации MCP по транспортам и актуальные инструкции SDK по обслуживанию через HTTP.
| Критерий | Локальный stdio | Удалённый Streamable HTTP |
|---|---|---|
| Где запускается сервер | Как правило, рядом с клиентом, на той же машине | На отдельном сервере или в доступной команде среде |
| Доступ к локальным ресурсам | Удобен, если инструменту нужны файлы и окружение пользователя | Требует продуманного доступа к нужным данным; локальная файловая система пользователя автоматически не доступна |
| Общая эксплуатация | Каждый пользователь может запускать и обновлять собственный процесс | Один сервис можно обслуживать и обновлять централизованно |
| Сетевой доступ | Сетевой endpoint не является обязательной частью схемы | Нужен доступ клиента к удалённому сервису, но это не означает обязательную публикацию для всех |
| Что проверить до выбора | Команда запуска процесса, доступы и локальные зависимости | Поддержку транспорта клиентом, сетевую доступность, авторизацию и обработку ошибок |
Если локальный процесс зависит от пути к файлам, переменных окружения или инструментов разработки, перенесите эти зависимости в явный перечень до миграции. Иначе после переноса может выясниться, что сервер доступен, но не видит ресурсы, на которых держится работа инструмента.
Изменения протокола и границы состояния
В новой редакции, опубликованной 28 июля 2026 года, удалены протокольные шаги initialize / initialized и механизм Mcp-Session-Id; это можно сверить с заметкой о выпуске спецификации и разделом описания транспортов. Практический смысл для разработчика — не нужно проектировать серверную маршрутизацию вокруг именно этого механизма идентификации сессии. Однако из этого не следует, что любой старый клиент, любой SDK и вся логика приложения работают одинаково.
Разделяйте два уровня:
| Уровень | Что изменилось или остаётся | Что проектировать |
|---|---|---|
| Протокол | В указанной редакции отсутствуют начальное рукопожатие и Mcp-Session-Id |
Проверить реализацию транспорта и не опираться на удалённый механизм сессии |
| Приложение | Пользовательские права, бизнес-данные и прогресс операций не исчезают из-за изменения протокола | Хранение данных, авторизацию и правила доступа |
| Выполнение инструмента | Запись в базу или длительная задача может завершиться ошибкой независимо от способа связи | Идемпотентность, повторный вызов и восстановление результата |
Таким образом, «без состояния» здесь означает ограниченное утверждение о протокольной модели, а не обещание, что серверу больше не нужны база данных, пользовательский контекст или состояние длительной операции. Если инструмент создаёт запись, запускает обработку или возвращает результат не сразу, определите, где сохраняются её идентификатор и итоговый статус. При повторном запросе нужно понимать, будет ли операция безопасно продолжена, выполнена заново или отклонена.
Новый формат также не является заявлением о приросте производительности. Спецификация описывает протокольное поведение, а не измерения вашего сервиса. Не делайте выводы о задержках, пропускной способности или числе одновременных пользователей без проверки конкретной реализации и рабочей нагрузки.
Проверка существующих клиентов до миграции
Совместимость определяется не только серверной спецификацией. Имеют значение транспорт, клиентское приложение, используемый SDK и то, на какую редакцию протокола рассчитан каждый компонент. Поэтому на вопрос «подключится ли старый клиент» нельзя отвечать без проверки конкретной связки.
| Сочетание | Что выяснить | Решение до переключения |
|---|---|---|
| Новый сервер и клиент с поддержкой актуального транспорта | Совпадает ли выбранный транспорт и корректно ли проходит реальный вызов инструмента | Испытать на тестовом маршруте и проверить логи обеих сторон |
| Обновлённый сервер и старый клиент | Ожидает ли клиент прежний обмен и прежнее поведение сессии | Сверить версию протокола и SDK; не считать совместимость подразумеваемой |
| Клиенты с разными версиями | Поддерживают ли они одинаковую конфигурацию сервера | Составить список клиентских реализаций и тестировать каждую отдельно |
| Длительная операция через удалённый сервис | Где хранятся прогресс и результат после ошибки или перезапуска | Проверить прикладное восстановление, повторный вызов и защиту от дублирования записи |
Перед обновлением сверяйтесь с официальной документацией именно тех SDK, которые вы используете. В частности, описание миграции TypeScript SDK относится к поддержке изменений указанной даты, но не доказывает совместимость сторонних клиентов или SDK на других языках. Для HTTP-реализации сравните рабочий пример с текущим руководством SDK, не перенося настройки из старого проекта без проверки.
Частые вопросы перед выбором схемы
Как дать нескольким участникам общий MCP-инструмент?
Если клиентские приложения поддерживают Streamable HTTP, разместите инструмент как удалённый сервис в среде, к которой участникам разрешён доступ. Начните с ограниченного тестового маршрута и проверьте каждый тип клиента, а затем определите, где будут храниться секреты, данные и журналы. Общий endpoint не обязан быть открытым публичным адресом: сетевой доступ и права вызывающих пользователей нужно задать отдельно.
Нужно ли сохранять состояние после обновления спецификации?
Сохраняйте состояние, если оно нужно бизнес-операции: например, для продолжения длительной задачи, проверки права пользователя, аудита записи или выдачи результата после сбоя. Удаление Mcp-Session-Id не отвечает на вопрос, как именно приложение хранит прогресс. Для вызова без продолжения может быть достаточно обработки в рамках запроса; для процесса с восстановлением определите прикладное хранилище и поведение повторного вызова.
Как выбрать между stdio и Streamable HTTP?
Используйте stdio, если клиент запускает процесс локально и ему требуется доступ к файлам или среде разработки на этой машине. Рассматривайте Streamable HTTP, когда несколько клиентов должны обращаться к централизованно обслуживаемому инструменту. Затем проверьте поддержку транспорта в каждом клиенте, наличие требуемых ресурсов на серверной стороне и способ ограничения доступа. Выбор обусловлен топологией и совместимостью, а не одним лишь обновлением протокола.
Можно ли подключить старого клиента к новому серверу?
Это нужно подтвердить на вашей паре клиента и сервера: одинаковое название протокола не гарантирует совпадения ожидаемого поведения. Сверьте поддерживаемые редакции и инструкции миграции SDK, испытайте соединение, вызов инструмента и обработку ошибки. Если старый клиент зависит от прежнего рукопожатия или поведения сессии, не отключайте прежний рабочий маршрут, пока альтернативная конфигурация не пройдёт проверку.
Порядок миграции и эксплуатационная проверка
Проведите миграцию как контролируемое изменение, сохранив возможность вернуться к прежней конфигурации. Следующие действия не требуют предполагать определённую версию SDK: конкретные параметры запуска и примеры кода следует брать из официальной документации для выбранного языка и версии.
Определите сценарий. Запишите, кто вызывает инструмент, где должен работать процесс и нужны ли ему локальные файлы. Если инструмент нужен одному разработчику только на его рабочей машине, оставьте stdio, пока не появится конкретная потребность в общем доступе.
Составьте перечень клиентов. Укажите клиентские приложения, языки и SDK, используемые в рабочем процессе, а также транспорт, которым каждый из них подключается. Не объединяйте клиентов в одну условную категорию: разные реализации могут иметь разные ограничения.
Разделите состояние по слоям. Отметьте отдельно протокольное взаимодействие и состояние бизнес-операций. Для каждого инструмента, который записывает данные или выполняет длительную работу, определите хранение результата, права на действие и ожидаемое поведение при повторном вызове.
Поднимите тестовую реализацию. Выберите транспорт, подходящий выбранным клиентам, и используйте актуальные официальные примеры для вашей версии SDK. Не переносите старые параметры и код без сверки с документацией. Проверьте доступ к зависимостям, которые прежде находились на машине разработчика.
Проведите тесты клиент за клиентом. Проверьте подключение, вызов обычного инструмента, ожидаемую ошибку и недоступность запрещённой операции. Для старого клиента отдельно подтвердите, не ожидает ли он прежнее начальное взаимодействие или прежний порядок работы с сессией.
Проверьте длительную операцию. Прервите тестовый вызов или смоделируйте предусмотренную ошибку безопасным способом. Убедитесь, что приложение регистрирует результат, не создаёт непреднамеренную повторную запись и позволяет понять, нужно ли продолжить, повторить или отменить работу.
Переключайте после проверки и сохраните откат. Переносите рабочие вызовы только после успешного прохождения тестов для всех необходимых клиентов. Оставьте доступной проверенную прежнюю конфигурацию на период контролируемого перехода и зафиксируйте, по каким наблюдаемым ошибкам вы вернётесь к ней.
При анализе логов ищите не только сетевые ошибки. Важно различать отказ транспорта, неподдерживаемую операцию, ошибку авторизации и сбой бизнес-обработки. Такая классификация помогает установить, требуется ли менять клиент, серверный маршрут, политику доступа или слой хранения данных.
Выбор серверной схемы по нагрузке команды
Серверная аренда оправдана не самим фактом появления новой редакции MCP, а эксплуатационной потребностью: инструментом пользуются разные сотрудники, его нужно обслуживать независимо от рабочих компьютеров или рядом с ним работают другие контейнеры. Перед переносом опишите реальные процессы: какие MCP-сервисы будут запущены, какие данные они хранят, кому нужен доступ и как вы будете обновлять приложения.
Если требования к хранению и авторизации пока не определены, не начинайте с переноса всех инструментов на одну машину. Сначала выберите один сервис с понятными зависимостями, проверьте клиентские реализации и измерьте фактическую нагрузку своей системы. Для приложений, чувствительных к конфиденциальности, отдельно зафиксируйте, какие данные остаются в вашей среде и какие операции могут передаваться внешним системам.
При оценке размещения учитывайте не только MCP-процесс, но и соседние контейнеры, их дисковые данные и обслуживание. Для постоянно работающего набора сервисов проверьте требования к памяти и накопителям по документации самих приложений и по результатам собственного теста; не переносите оценку для одного сценария на другой и не принимайте универсальную цифру за минимальное требование. Для подключения к серверу изучите доступные способы входа и системные ограничения в руководстве OVN Cloud по SSH и RDP.
Отдельно оцените, нужна ли вам именно аренда независимого физического сервера. Она может подойти для устойчивого набора совместно используемых сервисов, когда важны выделенная машина и контроль над установленной системой. Для кратковременных экспериментов, небольшой нагрузки или редких запусков локальный процесс либо другой подход могут оказаться проще. Сопоставьте текущие ограничения — зависимость от компьютера конкретного разработчика, разрозненные обновления и недостаточный контроль над средой — с затратами на собственное развёртывание и поддержку.
Актуальность протокольных выводов сверена 25 октября 2026 года с публикацией MCP от 28 июля 2026 года, спецификацией транспортов, документацией SDK по HTTP и руководством по миграции. Перед выпуском конфигурации повторно проверьте эти источники: поддержка клиентов и стабильное поведение SDK зависят от конкретных реализаций и могут меняться.
Если локальный MCP уже мешает совместному использованию, а инструменты должны постоянно работать вместе с другими контейнерами, сравните собственную схему с арендуемым выделенным AMD-сервером. Общие VPS могут ограничивать контроль над средой, делить вычислительные ресурсы с соседними нагрузками и затруднять предсказуемое размещение данных; при этом физический сервер не нужен для единичного теста или малой временной задачи. Когда вы подтвердили требования к системе и постоянной нагрузке, проверьте доступные конфигурации серверов OVN Cloud и выбирайте размещение по фактическому составу сервисов, а не по одному лишь названию протокола.
Частые вопросы
- Как предоставить один MCP-инструмент нескольким участникам команды? Разверните серверную часть как удалённый сервис с транспортом Streamable HTTP, если выбранные клиентские приложения и SDK его поддерживают. Сначала ограничьте доступ внутри нужной сетевой зоны или через принятый у вас механизм авторизации: удалённый транспорт не требует автоматически публиковать сервис всему интернету. Затем проверьте подключение каждого типа клиента, обработку ошибок и доступность требуемых данных.
- Нужна ли сессия приложению после изменений MCP? Отсутствие идентификатора сессии на уровне протокола не отменяет состояния самого приложения. Если инструмент хранит прогресс задачи, права доступа, результаты записи или данные для восстановления, их нужно проектировать и сохранять в прикладном слое. Для простого запроса без продолжения достаточно обработать его в рамках вызова; для длительного процесса заранее определите хранение и повторное выполнение.
- Когда оставить локальный запуск через stdio, а когда выбрать HTTP? Оставьте stdio, когда клиент запускает MCP-процесс на той же машине и инструменту нужны локальные файлы либо среда разработки. Выбирайте Streamable HTTP для общего удалённого сервиса, к которому обращаются разные клиенты, если их реализации поддерживают этот транспорт. Решение зависит от места выполнения инструмента, модели доступа и поддержки клиентом, а не только от даты выпуска спецификации.
- Сможет ли старый MCP-клиент работать с сервером на новой спецификации? Не считайте совместимость гарантированной только потому, что клиент и сервер называются MCP-совместимыми. Сверьте версии протокола и SDK, затем проверьте конкретный клиент на тестовом сервере: транспорт, начальное взаимодействие, обработку сессии и ошибки. Если старый клиент зависит от прежнего поведения, сохраните отдельную проверенную конфигурацию и не переключайте рабочий маршрут до завершения теста.
Разверните MCP-сервер на выделенной машине OVN Cloud
Если MCP-сервис должен быть доступен команде удалённо, разместите его на выделенном сервере OVN Cloud в Токио.
От $454.8 / месяц