Model Context Protocol, несмотря на агрессивное его внедрение (а возможно, и благодаря), продолжает развиваться. Недавно Anthropic обновил спецификацию MCP, и ниже мы рассмотрим основные изменения.

Усиление безопасности

MCP-сервер теперь всегда классифицируется как OAuth Resource Server, а клиенты обязаны реализовывать Resource Indicators (RFC 8707). Нужно это для защиты от атак типа Confused Deputy. Раньше токены, запрашиваемые клиентом у сервера авторизации были “обезличены”, то есть могли использоваться кем угодно. Это дает возможность злоумышленнику создать фишинговый MCP-сервер, обмануть клиента, украсть токен, и с помощью этого токена получить доступ к настоящему MCP-серверу.

  sequenceDiagram
    participant Клиент
    participant Сервер Авторизации (АС)
    participant Вредоносный MCP-сервер
    participant Legit as Легитимный MCP-сервер


    Клиент->>Сервер Авторизации (АС): Запрос на авторизацию для доступа к календарю
    note right of Клиент: Клиент думает, что будет общаться с calendar-mcp.com

    Сервер Авторизации (АС)-->>Клиент: Выдает токен доступа (без указания получателя)
    note left of Вредоносный MCP-сервер: Токен дает право `calendar:read`

    Клиент->>Вредоносный MCP-сервер: Соединяется (его обманули фишингом) и отправляет токен
    note right of Клиент: Ошибка! Клиент — "запутавшийся заместитель"
    
    Вредоносный MCP-сервер->>Legit: Использует украденный обезличенный токен
    Legit-->>Вредоносный MCP-сервер: Отдает данные (т.к. токен валиден)
    note over Вредоносный MCP-сервер, Legit: **УСПЕХ АТАКИ**

В новой реализации эту штуку закрыли. Клиент при запросе токена теперь обязан указать точный resource (адрес MCP-сервера). В ответ Сервер Авторизации вшивает этот адрес в поле aud (аудитория) самого токена. Благодаря этому MCP-сервер может убедиться, что токен предназначен именно для него, делая бесполезным токен, полученный для другого ресурса.

  sequenceDiagram
    participant Клиент
    participant Сервер Авторизации (АС)
        participant Zlo as Вредоносный MCP-сервер
    participant Legit as Легитимный MCP-сервер


    Клиент->>Сервер Авторизации (АС): Запрос токена с параметром:<br/>`resource=https://evil-mcp.com`
    note right of Клиент: Клиента обманули, он думает, что<br/>evil-mcp.com - это легитимный сервис.

    Сервер Авторизации (АС)-->>Клиент: Выдает токен с полем:<br/>`"aud": "https://evil-mcp.com"`
    note left of Legit: Токен теперь "именной", но для злоумышленника.

    Клиент->>Zlo: Отправляет токен на evil-mcp.com

    Zlo->>Legit: Пытается использовать этот токен для доступа к настоящему календарю.

    Legit-->>Legit: Проверка токена: смотрю поле `aud`.<br>В нем `"https://evil-mcp.com"`.<br>А мой адрес `"https://calendar-mcp.com"`.<br>Аудитория не совпадает!
    
    Legit-->>Zlo: **ОТКАЗ В ДОСТУПЕ (401/403)**
    note over Legit, Zlo: **АТАКА ПРОВАЛЕНА**

Помимо этого, добавлена страничка с security best practices. Она затрагивает практики, применимые на уровне самого протокола, но не на уровне атак на LLM, возможность которых создает его применение. Эти уязвимости описаны на главной странице спецификации, но о том, чтобы обеспечить их митигацию, обязана позаботиться сторона, реализующая хост (приложение, использующее MCP).

Удаление JSON-RPC batching

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

Как альтернативу для повышения эффективности коммуникации, инженеры могут применять HTTP/2 Multiplexing и параллельные асинхронные запросы к серверу.

Поддержка структурированного вывода

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

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

Механизм Elicitation

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

Я вижу здесь несколько применений, например:

  1. Упрощение взаимодействия с пользователем. Раньше для вызова инструмента, которому было необходимо собрать большой массив информации, требовалось запрашивать ее у пользователя одномоментно в виде огромной формы. Это сложно было назвать хорошим UI. С помощью Elicitation можно опрашивать пользователя пошагово с промежуточной валидацией.
  2. Реализация “ветвящихся” потоков обработки, где для разных веток нужны разные данные.
  3. Разрешение неоднозначности, к примеру, если пользователь просит написать письмо Джону, сервер может уточнить, какому именно.
  4. Подтверждение опасных действий. Хотя вызовы инструментов и требуется подтверждать, многие хосты предоставляют пользователю возможность нажать кнопку Allow all. В любом случае, приложения, использующие MCP, часто подвержены проблеме Confirmation Fatigue, когда оператору приходит такое количество подтверждений, что он одобряет их неглядя. Реализация Elicitation через отдельный интерфейс может дать понять пользователю, что на это подтверждение действительно стоит обратить внимание.

Прочие изменения и нововведения

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

Заключение

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

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

Впрочем, поживем — увидим.