Расширения MCP

Расширение MCP (MCP extension) - необязательное дополнение к спецификации Model Context Protocol, которое определяет возможности (capabilities) за пределами ядра протокола. У расширения есть уникальный идентификатор и собственный документ, а работает оно, только если поддержку объявили и клиент, и сервер. Спецификация называет три назначения расширений: модульные функции, например аутентификация, специализированные, например логика отдельной отрасли, и экспериментальные, которые обкатывают перед возможным включением в ядро.

Механизм расширений определил SEP-2133, а поле extensions в возможностях стало частью схемы протокола в версии спецификации 2026-07-28. Первое официальное расширение, MCP Apps, объявлено 26 января 2026 года. Официальные расширения разрабатываются в репозиториях организации Model Context Protocol на GitHub. Общее устройство протокола описано в статье Что такое MCP, а модель возможностей в каждом запросе, на которую опираются расширения, - в статье MCP без состояния.

Кратко

Какую задачу решают расширения

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

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

Экспериментальные задачи версии 2025-11-25 находились в ядре, и опыт реализации выявил проблемы с их рукопожатием (handshake), блокирующим методом tasks/result и областью видимости tasks/list. SEP-2663 вынес их в расширение, чтобы дать функции время развиваться независимо от ядра. MCP Apps прошли обратный путь: MCP-UI и OpenAI Apps SDK выработали разные подходы к интерактивным результатам, а расширение объединило их.

История

В таблице - события, которые сформировали механизм расширений и официальные расширения.

Идентификаторы расширений

Расширение обозначается строкой вида {vendor-prefix}/{extension-name}. Идентификатор подчиняется правилам для ключей _meta, но префикс в нём обязателен. Префикс - последовательность меток через точку; это должно быть перевёрнутое доменное имя, которым владеет автор: компания с доменом example.com использует com.example/my-extension. Любой префикс, у которого вторая метка - modelcontextprotocol или mcp, зарезервирован за MCP.

В таблице - идентификаторы официальных расширений.

Идентификатор не меняется, когда расширение переходит на другую стадию. Несовместимое изменение тоже сохраняет идентификатор. Новый идентификатор, например io.modelcontextprotocol/my-extension-v2, вводят, только если старое и новое поведение должны сосуществовать в одной версии протокола. Изначально SEP-2133 требовал нового идентификатора для каждого несовместимого изменения; SEP-3392 заменил это правило.

Согласование

Объявление поддержки

Поддержка объявляется в поле extensions возможностей: это словарь, где ключ - идентификатор, а значение - объект настроек. Пустой объект означает поддержку без настроек. Схему своих настроек определяет каждое расширение. В протоколе без состояния клиент объявляет расширения в каждом запросе, внутри _meta["io.modelcontextprotocol/clientCapabilities"]:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "New York" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/ui": { "mimeTypes": ["text/html;profile=mcp-app"] },
          "io.modelcontextprotocol/tasks": {}
        }
      }
    }
  }
}

Сервер объявляет свои расширения в возможностях, которые возвращает server/discover:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {},
      "resources": {},
      "extensions": {
        "io.modelcontextprotocol/ui": {},
        "io.modelcontextprotocol/skills": { "directoryRead": true }
      }
    },
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

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

Версии с рукопожатием

До версии 2026-07-28 многие SDK уже передавали расширения в capabilities.extensions запроса и ответа initialize. В опубликованных схемах этих версий такого поля нет; если другая сторона его не прислала, расширение считается неподдерживаемым.

Что могут добавлять расширения

Расширение может добавлять методы, уведомления, ключи _meta, настройки и значения resultType. Набор значений resultType, которые принимает клиент, - это значения ядра плюс значения расширений, объявленных в возможностях. Например, Tasks резервирует префикс методов tasks/, префикс уведомлений notifications/tasks/ и значение resultType "task".

Официальные, экспериментальные и сторонние расширения

Официальные расширения находятся в репозиториях организации modelcontextprotocol на GitHub с префиксом ext- и используют префикс io.modelcontextprotocol. В каждом репозитории файл MAINTAINERS.md перечисляет мейнтейнеров расширений (Extension Maintainers), а каждое расширение связано с рабочей группой (Working Group) или группой по интересам (Interest Group). За основными мейнтейнерами (Core Maintainers) остаётся право изменить, объявить устаревшим или удалить любое официальное расширение.

Экспериментальные расширения - путь обкатки идей для рабочих групп и групп по интересам. Они находятся в каталоге specification/experimental/ репозитория ext- или в репозитории с префиксом experimental-ext-. Опубликованные пакеты обязаны показывать экспериментальный статус, а реализациям следует фиксировать тег или коммит, потому что две редакции не обязаны быть совместимыми.

Расширения, разработанные вне организации MCP, управление проекта MCP не признаёт; SEP-2133 называет их неофициальными. Им следует использовать как префикс перевёрнутый домен автора, а согласуются они по тем же правилам.

Жизненный цикл и управление

Стадии

SEP-3392 определяет стадии расширения. Стадию показывает каталог, в котором лежит его спецификация: specification/experimental/, specification/beta/ или specification/stable/.

Изменения одобряют мейнтейнеры расширения без проверки основными мейнтейнерами. Расширению на стадии Beta, которое вносит несовместимое изменение, следует добавить или увеличить строку revision в объекте настроек, чтобы другая сторона могла заметить расхождение. Расширение на стадии Stable публикуется неизменяемыми редакциями, привязанными к версиям ядра протокола, например specification/stable/<name>/2026-07-28/.

Создание и перенос в ядро

Расширение начинается со стадии Experimental. Для перехода в Beta авторы подают SEP типа Extensions Track и указывают, должно ли расширение стать Stable или войти в ядро. До рассмотрения нужна хотя бы одна эталонная реализация в официальном SDK, а решение о принятии принимают основные мейнтейнеры. Для перехода в Stable второму SEP нужны две независимые совместимые реализации, одна на стороне клиента и одна на стороне сервера, и сценарий проверки соответствия.

SEP типа Standards Track может перенести расширение в ядро в версии протокола R. Для запросов с версией R и новее функция становится поведением ядра; для более ранних версий продолжает действовать расширение.

Поддержка в SDK

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

Текущие стадии

В таблице - стадии официальных расширений по странице обзора расширений.

Tasks

Назначение

Расширение Tasks позволяет серверу ответить на tools/call идентификатором задачи вместо итогового результата. Задача (task) - долговременный конечный автомат, который хранит состояние выполнения запроса и обозначается идентификатором taskId, созданным сервером. Клиент опрашивает задачу и забирает результат позже, в том числе после переподключения. В текущей редакции задачу может создать только tools/call.

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

Создание и опрос задачи

В примерах _meta опущено для краткости. Длительный вызов возвращает результат с resultType: "task":

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "task",
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "status": "working",
    "statusMessage": "Build started.",
    "createdAt": "2026-08-10T10:30:00Z",
    "lastUpdatedAt": "2026-08-10T10:30:00Z",
    "ttlMs": 3600000,
    "pollIntervalMs": 5000
  }
}

Сервер не должен отправлять этот результат, пока задача не создана надёжно, то есть пока tasks/get с возвращённым идентификатором не начнёт выполняться успешно. ttlMs - срок жизни от создания или null, если срок не ограничен. pollIntervalMs - рекомендуемый интервал опроса; серверы могут ограничивать клиентов, которые опрашивают чаще. Клиент опрашивает задачу через tasks/get:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tasks/get",
  "params": { "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840" }
}

В Streamable HTTP клиент ставит в заголовок Mcp-Name запросов tasks/get, tasks/update и tasks/cancel идентификатор задачи, чтобы промежуточные узлы могли направить запрос на экземпляр, который хранит задачу.

Статусы

В таблице - статусы задачи.

Результат инструмента (tool) с isError: true - это задача в статусе completed с ошибкой внутри result. Статус failed предназначен только для ошибок протокола.

Ввод во время выполнения

Когда задаче нужны данные, tasks/get возвращает status: "input_required" и словарь inputRequests в формате Multi Round-Trip Requests. Клиент отвечает запросом tasks/update:

{
  "jsonrpc": "2.0",
  "id": 6,
  "method": "tasks/update",
  "params": {
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "inputResponses": {
      "approve_deploy": { "action": "accept", "content": { "approved": true } }
    }
  }
}

Сервер подтверждает его пустым результатом с resultType: "complete". Подтверждение согласовано в конечном счёте: статус, который видит tasks/get, может измениться позже. Каждый ключ inputRequests уникален на всё время жизни задачи, а ответы на неизвестные или уже отвеченные ключи сервер игнорирует. Завершённая задача возвращает тот результат, который вернул бы исходный запрос:

{
  "jsonrpc": "2.0",
  "id": 9,
  "result": {
    "resultType": "complete",
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "status": "completed",
    "createdAt": "2026-08-10T10:30:00Z",
    "lastUpdatedAt": "2026-08-10T10:52:00Z",
    "ttlMs": 3600000,
    "pollIntervalMs": 5000,
    "result": {
      "content": [{ "type": "text", "text": "Deployed build 1842 to staging." }],
      "isError": false
    }
  }
}

Отмена и уведомления

tasks/cancel сообщает о намерении отменить задачу. Сервер обязан подтвердить запрос, но не обязан останавливать работу, и задача ещё может дойти до completed. Вместо опроса клиент может открыть subscriptions/listen с фильтром taskIds и получать notifications/tasks с полным состоянием задачи.

Отличия от 2025-11-25

Экспериментальные задачи версии 2025-11-25 несовместимы с расширением на уровне сообщений. Блокирующий метод tasks/result и tasks/list удалены, параметр task в tools/call игнорируется, а объявления возможностей tasks.requests.*, tasks.cancel и tasks.list заменены идентификатором расширения. Идентификаторы задач должны быть трудно угадываемыми, а каждый запрос к задаче проходит проверку авторизации.

MCP Apps

Составные части

MCP Apps (io.modelcontextprotocol/ui) позволяют серверу передать интерактивный HTML-интерфейс, который хост (host) отображает прямо в диалоге. Расширение соединяет два примитива: UI-ресурс (resource) со схемой URI ui:// и MIME-типом text/html;profile=mcp-app и инструмент, который ссылается на этот ресурс в _meta.ui.resourceUri:

{
  "name": "get_weather",
  "description": "Get current weather for a location",
  "inputSchema": {
    "type": "object",
    "properties": { "location": { "type": "string" } }
  },
  "_meta": {
    "ui": {
      "resourceUri": "ui://weather-server/dashboard",
      "visibility": ["model", "app"]
    }
  }
}

Хост получает интерфейс через resources/read, возможно ещё до вызова инструмента. Содержимое ресурса может включать _meta.ui.csp с внешними источниками, к которым интерфейсу разрешено обращаться:

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "resultType": "complete",
    "contents": [
      {
        "uri": "ui://weather-server/dashboard",
        "mimeType": "text/html;profile=mcp-app",
        "text": "<!DOCTYPE html><html><body>...</body></html>",
        "_meta": { "ui": { "csp": { "connectDomains": ["https://api.example.com"] } } }
      }
    ],
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

visibility определяет, кто может вызывать инструмент. Значение "model" делает его доступным модели, "app" - интерфейсу того же сервера. Инструмент только с ["app"] исключается из списка инструментов модели. Ресурсы и инструменты разобраны в статьях Ресурсы MCP и Инструменты MCP.

Песочница

Интерфейс работает в изолированном iframe без доступа к DOM, cookie и хранилищу хоста. Веб-хост помещает его за промежуточный прокси-фрейм песочницы на другом источнике (origin). Если ресурс не объявил CSP, хост применяет строгие правила по умолчанию, которые запрещают внешние соединения, и не должен разрешать необъявленные домены.

Обмен между интерфейсом и хостом

Интерфейс и хост обмениваются сообщениями JSON-RPC 2.0 через postMessage. Спецификация описывает это как диалект MCP, в котором интерфейс выступает клиентом хоста.

Host (AI application)
 |
 +-- MCP client ------ tools/call, resources/read ------ MCP server
 |
 +-- sandbox proxy (separate origin)
       |
       +-- iframe with the interface --- postMessage, JSON-RPC

Обмен начинается с ui/initialize и ui/notifications/initialized. Хост передаёт аргументы инструмента в ui/notifications/tool-input, а результат - в ui/notifications/tool-result. Интерфейс может вызывать инструменты своего сервера через tools/call; хост пересылает такие вызовы и может запросить подтверждение пользователя. Ещё интерфейс может отправить сообщение в чат через ui/message, добавить данные в контекст модели через ui/update-model-context и попросить хост открыть ссылку через ui/open-link. Перед удалением интерфейса хост отправляет ui/resource-teardown.

Резервное поведение

Хост без поддержки MCP Apps считает инструмент обычным и показывает его текстовый результат. Поэтому инструмент обязан возвращать осмысленный content, даже когда у него есть интерфейс, а серверам следует предусматривать текстовое поведение для каждого инструмента с интерфейсом.

Enterprise-Managed Authorization

Расширение Enterprise-Managed Authorization (io.modelcontextprotocol/enterprise-managed-authorization) делает корпоративного провайдера учётных записей (identity provider, IdP) местом, где решается доступ к MCP-серверам. Без расширения каждый пользователь авторизует каждый клиент на каждом сервере отдельно. С расширением администраторы задают в IdP, какие пользователи могут работать с какими клиентами, серверами и правами (scopes). Основы авторизации в MCP через OAuth описаны в статье Авторизация в MCP.

Расширение - профиль черновика IETF Identity Assertion JWT Authorization Grant. Процесс состоит из трёх шагов:

1. Пользователь входит в MCP-клиент через корпоративный IdP по OpenID Connect или SAML, и клиент сохраняет подтверждение личности (identity assertion).
2. Клиент отправляет в IdP запрос обмена токенов (RFC 8693) с requested_token_type, равным urn:ietf:params:oauth:token-type:id-jag. IdP проверяет свои политики и возвращает Identity Assertion JWT Authorization Grant (ID-JAG).
3. Клиент предъявляет ID-JAG серверу авторизации MCP-сервера как грант JWT bearer (RFC 7523) и получает токен доступа.

Клиент не перенаправляет пользователя на сервер авторизации MCP-сервера. О поддержке профиля он узнаёт по значению urn:ietf:params:oauth:grant-profile:id-jag в поле authorization_grant_profiles_supported метаданных сервера авторизации. IdP видит только выдачу токена, но не сам трафик MCP.

В том же репозитории находится OAuth Client Credentials (io.modelcontextprotocol/oauth-client-credentials) - расширение для доступа между машинами без участия пользователя, например из конвейеров CI и фоновых сервисов.

Skills over MCP

Skills over MCP (io.modelcontextprotocol/skills) позволяют серверу публиковать Agent Skills - каталоги с файлом SKILL.md и вспомогательными файлами. SEP-2640 имеет статус Final, а страница обзора расширений относит расширение к стадии Beta. Сервер, который его объявляет, обязан также объявить resources и реализовать skills/list и skills/get; файлы читаются через resources/read по URI skill://.

Чтение SKILL.md не активирует скил. Хост загружает его через собственный механизм загрузки скилов, который проверяет содержимое и при необходимости запрашивает подтверждение пользователя. Расширение требует, чтобы хост считал содержимое скилов недоверенными данными; риски инструкций в таком содержимом разобраны в статье Prompt injection.

Поведение без поддержки расширения

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

Единого кода ошибки для всех расширений спецификация не определяет.

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

Необязательное поведение добавляют в MCP три механизма. В таблице они сравниваются.

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

Поле experimental в ClientCapabilities и ServerCapabilities содержит нестандартные возможности в виде словаря имён и объектов. Схема не определяет для них ни процесса, ни префикса, ни документа, тогда как у экспериментального расширения есть рабочая группа, репозиторий и путь к стадии Beta.

Термины

Источники

• Extensions Overview(откроется в новой вкладке) (на английском)
• Versioning and Compatibility: согласование расширений, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Key Changes, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Схема TypeScript, версия 2026-07-28(откроется в новой вкладке) (на английском)
• SEP-2133: Extensions(откроется в новой вкладке) (на английском)
• SEP-3392: Extension Lifecycle(откроется в новой вкладке) (на английском)
• Tasks(откроется в новой вкладке) (на английском)
• SEP-2663: Tasks Extension(откроется в новой вкладке) (на английском)
• Схема расширения MCP Tasks, версия 2026-07-28, GitHub(откроется в новой вкладке) (на английском)
• MCP Apps(откроется в новой вкладке) (на английском)
• Спецификация MCP Apps, редакция 2026-01-26, GitHub(откроется в новой вкладке) (на английском)
• MCP Apps - Bringing UI Capabilities To MCP Clients, блог MCP, 26 января 2026(откроется в новой вкладке) (на английском)
• Enterprise-Managed Authorization(откроется в новой вкладке) (на английском)
• Спецификация Enterprise-Managed Authorization, редакция 2026-07-28, GitHub(откроется в новой вкладке) (на английском)
• Skills(откроется в новой вкладке) (на английском)
• The 2026-07-28 Specification, блог MCP, 28 июля 2026(откроется в новой вкладке) (на английском)