Устаревшие возможности

Спецификация 2026-07-28 выводит из обращения пять возможностей. SDK по-прежнему реализует каждую из них, и каждая теперь выдаёт предупреждение об устаревании. Один вспомогательный метод SDK объявлен устаревшим по собственным причинам и описан в конце страницы.

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

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

Из этой таблицы следуют три вывода:

• Корневые каталоги, сэмплирование и логирование идут вместе. Одно предложение, SEP-2577, объявляет устаревшими все три возможности разом.
• У сэмплирования и корневых каталогов есть общая, более глубокая проблема: это места, где сервер отправляет запрос клиенту. Именно это направление целиком спецификация 2026-07-28 заменяет многораундовыми запросами. Исчезли самостоятельные RPC-методы (sampling/createMessage, roots/list и push-вариант elicitation/create); типы полезной нагрузки CreateMessageRequest / ListRootsRequest / ElicitRequest сохранились — они встраиваются в InputRequiredResult.input_requests, а на клиенте попадают в те же колбэки.
• ping стоит особняком. Протокол не объявляет его устаревшим, а удаляет. Метод SDK всё равно выдаёт предупреждение (в его тексте сказано removed, а не deprecated), а вызов на современном подключении возвращает «Method not found».

Устаревание носит рекомендательный характер

Сегодня ничего не ломается.

Все перечисленные методы продолжают работать в любой сессии, согласованной на версии 2025-11-25 или более ранней. Зафиксируйте на клиенте mode="legacy" — и получите в точности поведение до 2026 года. В передаваемых данных ничего не меняется, согласование возможностей остаётся прежним.

Меняется одно: при первом запуске каждого из них появляется заметное предупреждение:

MCPDeprecationWarning: The logging capability is deprecated as of 2026-07-28 (SEP-2577).

MCPDeprecationWarning наследуется от UserWarning, а не от DeprecationWarning. Это сделано намеренно: фильтр Python по умолчанию показывает DeprecationWarning только в коде, запущенном напрямую как __main__, — именно так библиотеки объявляют что-то устаревшим, и два года этого никто не замечает. Это предупреждение видно везде, без всякого флага -W.

Cannot send 'sampling/createMessage': this transport context has no back-channel
for server-initiated requests.

ping в сессии старого поколения

Ping — это пустой запрос, который любая из сторон может отправить, чтобы проверить, что другая всё ещё отвечает. Спецификация 2026-07-28 его удаляет (SEP-2575): каждый запрос современного клиента и так доказывает, что сервер на месте, а у современного сервера нет канала, чтобы отправить свой. Оба метода SDK по-прежнему работают в сессии поколения с рукопожатием. Со стороны клиента:

async def main() -> None:
    async with Client("http://localhost:8000/mcp", mode="legacy") as client:
        await client.send_ping()  # warns; returns an EmptyResult

А со стороны сервера, внутри любого обработчика:

@mcp.tool()
async def check_client(ctx: Context) -> str:
    """A tool that still pings the client mid-call."""
    await ctx.session.send_ping()  # no warning; an EmptyResult while the client is connected
    return "client answered"

• client.send_ping() при каждом вызове выдаёт MCPDeprecationWarning. На подключении по умолчанию (2026-07-28) сервер вместо этого отвечает MCPError: Method not found.
• ctx.session.send_ping() предупреждения не выдаёт. На современном подключении он выбрасывает ту же ошибку об отсутствии обратного канала (back-channel), что и любой другой запрос по инициативе сервера.
• Чтобы отвечать на ping, ни одной из сторон ничего регистрировать не нужно.

Уведомления об изменении корневых каталогов

Клиент поколения 2025, объявивший возможность корневых каталогов, может сообщить серверу, что папки его рабочей области изменились, отправив notifications/roots/list_changed; в ответ сервер заново запрашивает roots/list. Спецификация 2026-07-28 удаляет это уведомление вместе со всей остальной push-схемой работы с корневыми каталогами. На клиенте именно передача list_roots_callback= (Колбэки клиента) объявляет "roots": {"listChanged": true}, а выполняет это обещание один вызов:

async def open_folder(client: Client, uri: str, name: str) -> None:
    """The user opened another folder: expose it through the roots callback, then tell the server."""
    workspace.append(Root(uri=FileUrl(uri), name=name))
    await client.send_roots_list_changed()

На стороне сервера принимающий обработчик регистрируется в низкоуровневом классе Server:

async def roots_changed(ctx: ServerRequestContext, params: NotificationParams | None) -> None:
    """The client's roots changed: ask for the new list."""
    roots = (await ctx.session.list_roots()).roots


server = Server("Bookshop", on_roots_list_changed=roots_changed)

• workspace — это список, который возвращает ваш list_roots_callback. client.send_roots_list_changed() выдаёт предупреждение, и ему нужен клиент с mode="legacy": на современном подключении уведомление молча отбрасывается. После этого держите сессию открытой: последующий запрос roots/list от сервера придёт именно по ней.
• У MCPServer нет точки подключения для этого уведомления. В низкоуровневом Server обработчик регистрируется параметром on_roots_list_changed= (он тоже устаревший и предупреждает при создании объекта). Полезной нагрузки уведомление не несёт, поэтому за новым списком обработчик вызывает ctx.session.list_roots().

Отключение предупреждения

В новом коде — не отключайте.

Но сервер, который вы поддерживаете и который действительно обслуживает клиентов до 2026 года, имеет полное право на тихий лог. Отфильтруйте категорию до того, как выполнится первый устаревший вызов:

import warnings

from mcp import MCPDeprecationWarning

warnings.filterwarnings("ignore", category=MCPDeprecationWarning)

Вот и весь API. Переключателя для отдельных методов нет, и он не нужен: смысл единой категории в том, что одна строка её заглушает и одна строка возвращает.

mcp.shared.exceptions.MCPDeprecationWarning: The logging capability is deprecated as of 2026-07-28 (SEP-2577).

Устаревшие вспомогательные методы SDK

Это не изменения спецификации, а лишь внутренние детали SDK, у которых появилась лучшая замена. Они выдают то же предупреждение MCPDeprecationWarning и будут удалены в версии 3.0.

Итоги

• Спецификация 2026-07-28 объявляет устаревшими корневые каталоги, сэмплирование по инициативе сервера и протокольное логирование (всё — SEP-2577), ограничивает прогресс направлением от сервера к клиенту и удаляет ping.
• Столбец с заменами указывает, куда идти дальше: Многораундовые запросы — для сэмплирования и корневых каталогов, Логирование — для логирования, Прогресс — для прогресса. ping не требует вообще ничего.
• Устаревание носит рекомендательный характер: в передаваемых данных ничего не меняется, всё продолжает работать в сессиях до 2026 года, и появляется заметное предупреждение MCPDeprecationWarning (это UserWarning, поэтому оно включено по умолчанию).
• Сэмплированию и корневым каталогам дополнительно нужен обратный канал, которого в сессии 2026-07-28 нет. На современном подключении они выдают предупреждение, а затем выбрасывают исключение.
• warnings.filterwarnings("ignore", category=MCPDeprecationWarning) заглушает всю категорию; "error::mcp.MCPDeprecationWarning" в pytest превращает её в провал теста.
• Один вспомогательный метод SDK, FuncMetadata.call_fn_with_arg_validation(), объявлен устаревшим отдельно и будет удалён в версии 3.0.
• Новый код не следует строить ни на одной из этих возможностей.

Все остальные страницы этой документации описывают актуальный API.