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

Обновление, превосходящее простое улучшение версии

Согласно объявлению о выпуске проекта, Model Context Protocol получил самое крупное обновление с момента своего запуска 28 июля 2026 года. В новой спецификации устраняются сессии протокола, формализуются расширения, добавляется возможность выполнения асинхронных операций с сохранением результатов, ужесточаются механизмы авторизации, а также предоставляется четкая политика по постепенному устареванию функций. Кандидатская версия выпуска была заморожена с 21 мая, что дало разработчикам SDK, клиентского программного обеспечения и операторам серверов примерно десять недель на тестирование новой структуры.

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

«Безсостоянийный MCP» — хороший заголовок, но список изменений гораздо обширнее. Под ним скрывается ряд серьезных изменений. Результаты теперь содержат поле resultType. Удален поток HTTP GET. Функция subscriptions/listen заменяет более старые способы подписки. Потоки SSE теряют возможность возобновления работы благодаря полю Last-Event-ID. Результаты списков и ресурсов обязаны включать указатели кэша. Схемы инструментов могут использовать всю спецификацию JSON Schema 2020-12. Наконец, отсутствие ресурса теперь возвращает стандартный код JSON-RPC -32602, в то время как раньше возвращался код -32002.

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

1. Безсостоянийный протокол не делает приложение безсостоянийным

В более ранних версиях контекст устанавливался с помощью процедуры обмена сообщениями initialize/initialized. Для удаленных HTTP-серверов сервер также мог передавать значение Mcp-Session-Id, которое клиент воспроизводил в последующих запросах. Это связывало клиента с определенной сессией сервера, и в реальных реализациях часто использовалась технология «липкого маршрутизирования» на балансировщике нагрузки, общий хранилище сессий или их комбинация.

В дате 2026-07-28 процедура обмена сообщениями и сессия протокола исчезают. Каждый запрос содержит информацию о версии протокола, возможностях клиента и необязательные данные об идентификаторе клиента в разделе _meta. Серверы должны реализовывать функцию server/discover, хотя клиентам не обязательно вызывать ее перед каждой операцией. Вместо этого клиент может отправить свою предпочтительную версию протокола и попытаться снова, если поступит ошибка UnsupportedProtocolVersionError.

Через Streamable HTTP текущий запрос передаёт метаданные в следующем виде:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

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

«Без состояния» не означает «ничего не хранить»

Спецификация не устраняет необходимость в состоянии приложения; она лишь прекращает его скрытие. Когда серверу требуется преемственность между вызовами, он должен создать уникальный идентификатор, например workspace_id, browser_id, basket_id, analysis_run_id или deployment_id. Затем клиент или модель передают этот идентификатор в качестве обычного аргумента в последующих вызовах:

create_workspace()
→ { "workspace_id": "ws_7f3..." }

add_file(workspace_id="ws_7f3...", ...)
→ ...

run_analysis(workspace_id="ws_7f3...")
→ ...

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

2. Где безсостоянийность действительно полезна

Простое горизонтальное масштабирование

Когда запрос содержит всю необходимую собственную информацию о контексте, сервер может работать за стандартным балансиром нагрузки типа round-robin. В Kubernetes обычно достаточно стандартных объектов Deployment и Service — без аннотаций, связанных с сессиями, и без объектов типа StatefulSet, предназначенных исключительно для управления сессиями MCP. Особенно полезна возможность автомасштабирования: новый под не обязан пересоздавать протокольные сессии перед тем, как начать обрабатывать трафик, а под, заменённый во время постепенной замены, не оставляет клиентов в «мертвых» сессиях.

Есть один недостаток: если сервер обрабатывает приложения или задачи, эти объекты всё равно хранятся во внешнем надёжном хранилище, чтобы выжить в случае сбоя процесса или пода.

Маршрутизация и политики на шлюзе

Поскольку Mcp-Method и Mcp-Name являются обычными заголовками, шлюз может направлять трафик, отслеживать его объем и применять правила без необходимости парсинга тела JSON. В многоклиентском сервисе это позволяет устанавливать отдельные квоты для tools/list, дорогостоящих инструментов поиска, инструментов развертывания и любых инструментов, способных нанести ущерб:

tools/list                  → high request allowance
tools/call + search         → standard allowance
tools/call + deploy_prod    → lower rate limit and stronger policy
resources/read              → data-volume quota

Шлюз также никогда не должен считать значение clientInfo доказательством того, кто осуществляет вызов. Это поле является самоопределяемым и предназначено для отображения, отладки и логирования. Идентификация арендатора должна определяться на основе проверенного токена или какого-либо другого надежного источника.

Кэширование

Ответы на запросы resources/read, resources/templates/list, resources/list, prompts/list, tools/list и server/discover содержат два новых поля — ttlMs и cacheScope. Первое указывает на срок действия данных, а не на интервал опроса. Второе определяет, являются ли результаты общедоступными или приватными. Любые данные, которые меняются в зависимости от пользователя, арендатора, диапазона или уровня авторизации, не должны рассматриваться как общедоступные данные, и уведомления о изменениях могут сделать недействительными результаты, которые в противном случае были бы актуальными.

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

Наблюдаемость

В спецификациях W3C описано распространение контекста трейсинга с помощью ключей _meta traceparent, tracestate и baggage. Таким образом хост, клиент MCP, шлюз, сервер и последующие сервисы имеют единый способ связывать вызовы инструментов на протяжении всего пути выполнения. Контекст трейсинга способствует такой связке, но не является механизмом авторизации или гарантией целостности; чувствительные данные, токены, необработанные запросы и личная информация не должны находиться в поле baggage.

3. Расширения становятся концепцией первого класса

Теперь у каждого расширения есть идентификатор, правила взаимодействия, назначенные администраторы, собственный репозиторий и собственный цикл выпусков. Клиенты указывают расширения, которыми они управляют, в характеристиках, отправляемых с каждым запросом, в то время как серверы объявляют о своих расширениях с помощью server/discover. Расширение вступает в силу только тогда, когда обе стороны его поддерживают; если у партнера он отсутствует, реализация должна вернуться к базовому поведению или ответить соответствующей ошибкой.

Это значительный шаг в развитии протокола, поскольку новые функции больше не ждут полного выпуска основной версии. Это также позволяет создавать матрицу совместимости. Сервер не может предполагать, что каждый хост поддерживает Tasks, MCP Apps, Enterprise-Managed Authorization или любое будущее расширение, поэтому в производственном коде необходимы явные механизмы обхода недостатков:

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

Расширения снижают степень связанности с основными спецификациями, но увеличивают риск фрагментации экосистемы.

4. Задачи делают долгосрочно работающие инструменты более надежными

Задачи переходят из экспериментальной части в официальное расширение io.modelcontextprotocol/tasks. Если клиент заявляет, что поддерживает задачи, сервер может ответить обычной операцией с идентификатором задачи вместо окончательного результата. Затем клиент использует tasks/get для получения текущего состояния, tasks/update для передачи необходимых данных и tasks/cancel для запроса отмены.

Задача проходит через состояния working, input_required, completed, failed и cancelled. Сервер обязан сохранить задачу до того, как вернёт её идентификатор. Отмена является взаимной процедурой, поэтому подтверждение запроса не гарантирует немедленной остановки выполнения задачи.

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

Что должен добавить производственный сервер

Для выполнения заданий требуется гораздо больше, чем просто фоновая нить:

• надёжный хранилище заданий
• проверка авторизации каждый раз при вызове методов tasks/get, tasks/update или tasks/cancel
• изоляция владельцев и пользователей
• проверка корректности смены статусов заданий
• хранение результатов и ошибок
• обеспечение соблюдения сроков действия и очистка данных
• ограничения на частоту опросов
• передача информации о отмене задания
• восстановление после сбоя рабочего процесса
• создание идемпотентных заданий
• защита от дублирующихся обновлений
• метрики по возрасту очереди и застрявшим задачам

Рассматривайте идентификатор задачи как идентификатор ресурса, а не как секрет. Наличие этого идентификатора никогда не должно служить основанием для предоставления каких-либо прав.

5. Многократные запросы заменяют запросы, инициируемые сервером

Безсостоянийный сервер не может рассчитывать на постоянное двунаправленное соединение для задания вопроса клиенту в любое время. В таких случаях используются многократные запросы (MRTR). Когда серверу нужна подтверждение, информация, примеры или другие данные от клиента, он возвращает объект InputRequiredResult. Клиент собирает необходимые данные и повторяет первоначальную операцию, передавая inputResponses и, при наличии, requestState.

Возьмем пример разрушительного инструмента:

delete_resources(resource_ids=[...])

Вместо того чтобы отправлять обратный запрос к существующему потоку, сервер отвечает:

input_required:
  "Confirm deletion of 53 resources"

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

Правила для производственного MRTR

• Не выполняйте необратимые действия, пока не будут получены все необходимые входные данные.
• Сделайте повторные попытки идемпотентными.
• Свяжите requestState с конкретной операцией и тем, кто её запустил.
• Аннулируйте устаревшие состояния запросов.
• Отклоняйте ответы, содержащие ключи, которые сервер никогда не запрашивал или уже получил.
• Установите лимит на количество разрешённых попыток, чтобы не возникало циклов.
• Снова авторизируйте операцию при каждой повторной попытке.
• Никогда не предполагайте, что повторная попытка будет выполнена в той же инстансе.

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

6. Приложения MCP меняют продукт, а не только протокол

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

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

7. Процедуры авторизации становятся более строгими и сложными

Согласно правилам авторизации HTTP, защищенный сервер MCP выступает в роли сервера ресурсов OAuth, а клиент MCP — в роли клиента OAuth. В этой версии используются отдельные элементы стандарта OAuth 2.1 и смежных стандартов. Серверы обязаны публиковать метаданные защищенных ресурсов, чтобы клиенты могли их найти; принимаются как метаданные серверов авторизации OAuth, так и OpenID Connect. PKCE является обязательным, как и указатели ресурсов в запросах на авторизацию и получение токенов; проверки эмитента становятся более строгими. Основные правила:

• Клиенты отправляют параметр resource с указанием целевого сервера MCP.
• Сервер проверяет, что полученный им токен был выдан для его собственной аудитории.
• Серверы авторизации должны включать поле iss, и клиенты проверяют значение этого поля перед использованием кода авторизации.

Учетные данные связаны с сервером авторизации, который их выдал.

Токены доступа должны находиться в заголовке Authorization, а не в строке запроса.

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

Клиенты используют PKCE, предпочтительно вариант S256.

Расширение диапазона полномочий ограничено количеством попыток.

Динамическая регистрация клиентов устарела; вместо нее используются документы метаданных ID клиента.

Индикаторы ресурсов ограничивают круг пользователей токена. Их не следует рассматривать как механизм привязки криптографического токена.

Корпоративная идентичность — отдельный вопрос

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

Core authorization
  OAuth flow
  issuer validation
  resource/audience validation
  scopes and step-up
  Protected Resource Metadata

Optional enterprise extension
  corporate IdP policy
  SSO
  centralized approval and revocation
  identity-assertion exchange

В спецификации четко описана архитектура, но это не делает процесс работы с OAuth проще на практике. Получение метаданных клиента вызывает проблемы, связанные с SSRF и политикой доверия. Токены и учетные данные для обновления должны храниться в защищенном формате. При использовании нескольких источников выдачи токенов требуется отдельная процедура регистрации и управление состоянием токенов. Метаданные, URI-адреса перенаправлений, диапазоны доступа и канонические идентификаторы ресурсов должны оставаться согласованными.

8. Реальная политика устаревания

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

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

Как это проявляется в реальных приложениях

Внутренние инструменты предприятий

Представьте компанию, которая публикует внутренние знания, данные из Jira и Confluence, каталоги услуг и руководства с помощью MCP. При использовании старой модели удалённая развертка могла зависеть от принципа сессионной привязки, благодаря которому один сотрудник постоянно попадал на ту же инстанцию. С датой 2026-07-28 уровень MCP может представлять собой набор безсостоянийных контейнеров, расположенных за обычным Kubernetes Service и балансиром нагрузки:

MCP host
  ↓
API gateway / authorization
  ↓
Stateless MCP Deployment
  ├─ Knowledge connector
  ├─ Jira connector
  ├─ Confluence connector
  └─ Service catalog connector
  ↓
OpenTelemetry backend

Ежедневная авторизация может осуществляться в соответствии с основными принципами OAuth, а расширение Enterprise-Managed Authorization применяется тогда, когда требуется централизованная политика IdP. Основным ограничением является количество клиентов, которые фактически поддерживают это расширение.

Multi-tenant SaaS

Предположим, поставщик инструментов для разработчиков продаёт MCP в качестве платного API сотням или тысячам арендаторов. Отсутствие состояния позволяет использовать простую маршрутизацию между зонами, а шлюз может учитывать показатели по параметрам Mcp-Method и Mcp-Name, беря информацию об арендаторе из проверенных данных авторизации, а не из имён или заголовков, отправляемых клиентом. Качественная реализация должна разделять обработчики и задачи по арендаторам, помечать каталоги, специфичные для арендатора, как cacheScope: „private“, сравнивать каждый заголовок с содержимым, ограничивать использование дорогостоящих инструментов их собственными лимитами, блокировать поиск задач между арендаторами и не хранить решения об авторизации во внутренней памяти процесса. Маршрутизация, учитывающая сессию, отсутствует; изоляция арендаторов по-прежнему является вашей задачей.

Помощники по программированию на основе ИИ

Сервер для кодирования может предоставлять функции run_tests, build_project, generate_patch или deploy_preview в качестве задач. Он сразу возвращает идентификатор задачи, помещает работу в очередь и позволяет агенту продолжать читать код или рассматривать другие проблемы. Клиент запрашивает статус задачи с интервалом, указанным сервером, и когда для выполнения какого-либо шага требуется одобрение, задача переходит в состояние input_required, после чего клиент отправляет ответ с командой tasks/update. Преимущество такого подхода — устойчивость к сбоям при перезапуске редактора или потере соединения. Цена же — наличие настоящей системы обработки задач: надежная очередь, система аренды рабочих процессов, хранение результатов, возможность отмены задач, изолированные рабочие пространства и политика хранения данных.

Здравоохранение и финансовые услуги

Показатели ресурсов и проверка аудитории снижают вероятность повторного использования токена, выданного для одного сервера MCP, в другом, а верификация эмитента уменьшает риски атак типа путаницы OAuth. Механизм W3C Trace Context позволяет отслеживать запросы по всему пути MCP и связанным с ним сервисам. В совокупности они предоставляют командам по безопасности и соблюдению стандартов более четкий набор инструментов контроля, хотя и не являются полным решением для соблюдения требований. В приложении по-прежнему необходимы механизмы авторизации, неизменяемые записи аудита, правила хранения и удаления данных, классификация информации, обработка согласий, управление ключами, журналы административного доступа, процедуры реагирования на инциденты и минимальный объем данных для отслеживания. Отслеживание помогает в диагностике, но не должно заменять собой единственный источник аудиторских записей.

Стартап, ориентированный на ИИ

Рассмотрим небольшую команду, разрабатывающую инструмент для управления инфраструктурой. С помощью MCP Apps она может предоставить форму для планирования развертывания, панель управления с оценкой затрат, диалог для утверждения, инструмент мониторинга процесса развертывания и механизм отката. Хост обеспечивает контекст для общения, сервер — инструменты и ресурсы интерфейса, а приложение использует эти инструменты через мост, контролируемый хостом. Вначале отдельный продукт в виде панели управления может показаться ненужным, однако задачи по проектированию API, авторизации, тестированию интерфейса, обеспечению доступности, настройке правил CSP и реализации альтернатив для совместимости остаются актуальными.

Где новые требования увеличивают сложность

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

Обновление SDK и внедрение протокола — это два отдельных проекта. Пока существовала версия кандидата на выпуск, разработчики SDK призывали команды не связывать обновление основной версии SDK с включением нового протокола передачи данных, и эта рекомендация по-прежнему актуальна. Возьмём, к примеру, SDK TypeScript v2: он разделяет единый пакет на отдельные пакеты для сервера и клиента, поставляется только в формате ESM, работает под Node.js 20+, Bun и Deno, проходит проверку с помощью библиотек, совместимых со стандартной схемой, и включает кодовую модификацию для учёта типичных изменений версии v1. Python v2 также требует значительной переработки, в том числе переименования FastMCP в MCPServer. TypeScript v1 будет получать исправления и обновления безопасности как минимум шесть месяцев после выхода v2, а Python v1 будет получать критические исправления и патчи безопасности. Это осторожный порядок действий:

1. Обновить SDK, сохраняя прежнее поведение протокола там, где это возможно.
2. Исправить изменения в API на уровне приложения.
3. Добавить поддержку протоколов двух поколений.
4. Проверить работу с реальными клиентами и трафиком.
5. Постепенно внедрить современное безсостоянийное поведение.
6. Удалить поддержку устаревших версий только после отслеживания уровня их использования клиентами.

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

Повторные попытки становятся проблемой корректности. Ситуации, требующие повторных попыток, возникают из-за MRTR, переговоров по версии протокола, потери потоков HTTP-ответов, усиления процедур авторизации, опроса данных Tasks и восстановления подписок. Поэтому любая операция с побочными эффектами требует четкого плана обеспечения идемпотентности.

OAuth обеспечивает лучшую взаимодействием, но остается сложным в использовании. В спецификации OAuth 2.1 и документы с метаданными Client ID указаны как черновики, поэтому разработчикам необходимо соблюдать как изменения в MCP, так и основные стандарты.

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

Общая оценка

Версия MCP 2026-07-28 приближает протокол к принципам современного веба: отдельные запросы, четко определенные версии, стандартное маршрутизирование HTTP, реальная семантика кэширования, распределенное отслеживание, стандартная авторизация и дополнительные возможности, развивающиеся отдельно. Настоящей выгодой является не отсутствие состояния, а отсутствие скрытого протокольного состояния.

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

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

Теперь протокол проще в использовании, но только для команд, готовых четко определить состояние приложения, границы безопасности и поведение при сбоях.

Связанные материалы

• Практические заметки: MCP 2026: Протокол вырос — вот что такое производственный ИИ — Подробное руководство по практическим заметкам: MCP 2026: Протокол вырос — вот что такое производственный ИИ: контракты, проверки и блоки кода для команд, использующих эту модель.
• Десять серверов MCP, которые стоит установить в первую очередь, в порядке приоритета для разработчиков — Рейтинг серверов MCP для помощников в программировании с использованием ИИ, от Context7 и GitHub до Postgres и систем памяти, с настройками установки и рекомендациями по разрешениям.

Измерение смещения портфеля с помощью Claude и сервера FMP MCP — Гипотетический портфель семейного офиса стоимостью 1 млн долларов воссоздается на основе цен FMP для измерения абсолютного, относительного и секторального смещения, а также для отметки позиций с целью их анализа специалистами.

[Практические заметки: серверы MCP: от чат-ботов ИИ до операций производственного уровня статья — Подробное руководство по практическим заметкам: серверы MCP: от чат-ботов ИИ до операций производственного уровня [Статья: контракты, проверки и слоты для вставки кода для команд, использующих эту модель].