http mcp в редакции протокола 2026-07-28 означает обращение клиента к одному HTTP endpoint: каждый JSON-RPC запрос уходит отдельным POST, а ответ приходит как JSON либо поток SSE в рамках этого запроса. Для внутреннего сервера рабочее подключение начинается с адреса endpoint, согласованной версии, авторизации и разрешённого метода. Затем команда проверяет ответ и фиксирует границы доступа. Ниже — маршрут проверки именно сетевого транспорта. Общую схему инструментов компании разбирает статья о собственном MCP-сервере; здесь важны заголовки, версия и поведение HTTP клиента.
Схема транспорта
Для нового подключения зафиксируйте редакцию 2026-07-28, единый URL с POST, метаданные каждого запроса и серверную проверку прав. Сначала вызовите чтение списка доступных инструментов, затем разрешённый тестовый метод. Ответ сверяйте по коду HTTP и телу JSON-RPC.
Название Streamable HTTP описывает способ обмена сообщениями между клиентом и сервером. Это транспорт, а состав инструментов задаёт конкретный сервер. Сервер принимает каждый JSON-RPC запрос отдельным POST по одному адресу, например внутреннему пути /mcp. На запрос он возвращает одиночный JSON объект либо SSE поток с сообщениями, связанными с исходным вызовом. Клиент должен уметь обработать оба вида ответа. Отдельный GET поток для нового клиента текущая редакция протокола уже исключает.
Для проверки соединения заранее запишите точный URL, среду, владельца сервера, поддерживаемую версию и ожидаемый набор методов. Разработчик получает эти сведения из конфигурации своего сервиса и его документации, затем сверяет их с фактическим ответом. Публичный URL из примера спецификации служит иллюстрацией формата; реальный адрес берут у владельца внутреннего сервера. При переносе между стендом и рабочей средой отдельно сверяют адрес и полномочия, чтобы тестовый токен остался в пределах стенда.
Официальное описание Streamable HTTP задаёт транспортные правила. Доступность инструментов именно вашего сервера выясняют отдельной проверкой. Для этого нужен просмотр его каталога и проверка допуска на стороне приложения. Разделение полезно при диагностике: успешный сетевой ответ подтверждает достижимость endpoint, а разрешённая операция подтверждает ещё и право на конкретное действие.
Версия и заголовки
В редакции 2026-07-28 клиент указывает версию в поле _meta.io.modelcontextprotocol/protocolVersion тела каждого запроса и повторяет её в заголовке MCP-Protocol-Version. Туда же, в _meta, входят сведения о клиенте и его возможностях. Заголовок Mcp-Method повторяет имя вызываемого метода; для tools/call обязателен также Mcp-Name с именем инструмента. Поля заголовков должны совпадать с телом. Сервер проверяет соответствие, а расхождение отклоняет как ошибку заголовков. Поэтому в журнале полезно хранить безопасные технические признаки обеих частей запроса без секретов.
Для POST клиент объявляет в Accept поддержку application/json и text/event-stream. Тело содержит один JSON-RPC запрос; пакет вызовов здесь исключён. Пример проверки списка инструментов строится вокруг метода tools/list с его метаданными; затем команда выбирает безопасный инструмент из ответа. При вызове tools/call клиент передаёт аргументы по схеме инструмента и сверяет Mcp-Name с именем в теле. Перед вызовом инструмента изучите его схему: она задаёт допустимые аргументы и смысл параметров.
Предварительное обнаружение через server/discover возможно, хотя клиент вправе отправить рабочий запрос сразу. Если сервер отклоняет версию, его ошибка UnsupportedProtocolVersionError перечисляет поддерживаемые редакции. Клиент выбирает общую редакцию либо сообщает о несовместимости. В разделе о согласовании версий этот маршрут описан отдельно от старого обмена initialize. Подмена редакции наугад затрудняет разбор, поскольку одинаковое название транспорта встречается и в старых реализациях.
Маршрут проверки
Для пробного подключения предложите команде изолированный стенд и учётную запись с правом чтения. Владелец сервера заранее подтверждает доступный endpoint и называет безопасный инструмент. Проверяющий сохраняет образец запроса без токена, ответ сервера и ожидаемое действие. Такой маршрут помогает отличить ошибку адреса, несовпадение версии и отказ в правах от ошибки прикладного метода. Пилот остаётся предложением для команды: реальные результаты появятся только после её собственных вызовов и сверки журнала.
- Адрес. Сверьте схему HTTPS, хост и путь endpoint с конфигурацией сервера; проверьте доступ из разрешённой сети.
- Версия. Укажите 2026-07-28 в _meta и MCP-Protocol-Version; при отказе прочитайте поддерживаемые редакции в JSON-RPC ошибке.
- Заголовки. Передайте Accept с JSON и SSE, Mcp-Method и нужный Mcp-Name; сопоставьте их значения с телом.
- Чтение. Запросите tools/list под тестовой ролью и сравните ответ с перечнем, утверждённым владельцем сервера.
- Вызов. Выберите разрешённый инструмент, отправьте tools/call с допустимыми аргументами и проверьте результат по данным источника.
- Отказ. Повторите попытку под ролью без доступа и убедитесь, что сервер отклоняет действие, а журнал фиксирует причину без секретов.
Проверка должна учитывать формат ответа. Одиночный JSON объект удобно сверять как завершённый результат. Для SSE клиент читает сообщения в рамках текущего POST до итогового ответа и закрывает поток при отмене запроса. Закрытие такого потока служит сигналом отмены; повтор после сомнительного обрыва требует отдельного решения по идемпотентности действия. Особенно важно это для записи: перед новым вызовом оператор сверяет состояние источника, чтобы избежать дублирования. Для теста прав отказ сервера значимее убедительного текста модели.
Границы доступа
Сетевой транспорт доставляет запрос, а решение о допуске остаётся у сервера. Авторизация должна связывать вызов с учётной записью и её разрешениями. Сервер проверяет право на конкретный метод, ресурс и действие перед исполнением. Подтверждение операции записи тоже закрепляют в серверной логике приложения; промпт лишь поясняет действие оператору. Для внутреннего контура заранее определяют владельца токена, порядок его хранения и перечень доступных инструментов для каждой роли.
Спецификация требует проверки заголовка Origin при его наличии: недопустимое значение приводит к HTTP 403. Для локального сервера она рекомендует привязку к localhost и корректную аутентификацию подключений. Эти меры защищают границу сервера, однако сетевой шлюз и само приложение всё равно должны проверять полномочия по своей модели доступа. Отдельно проверьте поведение при истёкшем токене и запросе к чужому ресурсу. В журнал добавляйте метод, идентификатор запроса и результат проверки, исключая содержимое секретов.
Нужна схема прав для внутреннего агента?
Если команда проектирует агента поверх нескольких внутренних инструментов, маршрут прав и подтверждений удобно оформить до подключения клиентов. На странице разработки ИИ-агентов можно обсудить границы инструментов, серверные проверки и приёмку. Для самостоятельной проверки полезен отдельный список: кто владеет endpoint, какие роли вызывают инструменты, где сохраняется журнал и кто подтверждает изменения. Текст ответа модели оставляют пояснением для оператора, а источник истины выбирают среди данных сервера.
Совместимость и приёмка
Название Streamable HTTP присутствует и в редакциях 2025 года, поэтому версия здесь принципиальна. Схема 2026-07-28 отказалась от протокольных сессий: клиент нового подключения обходится без Mcp-Session-Id, отдельного GET потока и возобновления SSE через Last-Event-ID. Старый сервер может требовать initialize и иную последовательность обмена. После обнаружения старой редакции клиент переключается в отдельный режим совместимости с её правилами.
По одному ответу 400 делать вывод о старой версии рано. В современной схеме сервер так сообщает, в частности, о неподдерживаемой редакции или несовпадении заголовков с телом. Сначала прочитайте JSON-RPC ошибку: распознанная современная ошибка ведёт к исправлению запроса либо выбору общей версии. Ответ без распознанной современной ошибки даёт основание проверять путь совместимости. Приёмка фиксирует этот выбор явно, чтобы следующий клиент повторял согласованную схему и избежал случайного обхода.
Завершите проверку короткой матрицей результата: адрес достижим, версия согласована, каталог виден под нужной ролью, разрешённый вызов проходит, запрещённый вызов отклоняется, JSON и SSE обрабатываются клиентом. Для операций записи добавьте проверку фактического состояния в источнике и серверного подтверждения. Если данные расчётные, полный экспорт и формулы сверяет парсер или скрипт; языковая модель помогает объяснить расхождение и предложить гипотезу, а специалист проверяет её по первичным данным. Такой протокол приёмки отделяет транспортную совместимость от качества ответа инструмента.