Python SDK

сверено с выпуском 2.3.0 4 октября 2026

Это SDK из репозитория modelcontextprotocol/python-sdk. В списке официальных SDK он отнесён к первому уровню (Tier 1).

Обе ветки публикуются в одном проекте mcp на PyPI:

Главный класс сервера в 2.x называется MCPServer, главный класс клиента - Client.

uv add "mcp[cli]"      # or: pip install "mcp[cli]"

Нужен Python 3.10 или новее. По README выпуска, дополнение cli добавляет команду mcp с подкомандами mcp dev, mcp run и mcp install. Если она не нужна, достаточно пакета mcp без дополнения.

Списки версий лежат в mcp_types/version.py:

• через рукопожатие initialize: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25;
• новая эпоха: 2026-07-28.

Константа LATEST_PROTOCOL_VERSION в этом выпуске указывает на 2026-07-28, а самая новая версия для рукопожатия вынесена в LATEST_HANDSHAKE_VERSION.

Для вас это значит: один и тот же код клиента и сервера работает с собеседником любой эпохи. Чем эпохи различаются, описано на странице о версиях протокола.

Поведением управляет аргумент mode конструктора Client. По документу о версиях:

Значение по умолчанию - "auto". Какая версия выбрана, показывает client.protocol_version.

Закреплённая версия - это ваше обещание, что сервер её понимает: клиент ничего не проверяет. Закрепить можно только версию новой эпохи. Строка старой эпохи отклоняется ещё в конструкторе с ошибкой ValueError.

Режим mode="legacy" нужен, когда клиенту требуются запросы от сервера: Sampling, Elicitation в виде запроса, обработчик сообщений. В редакции 2026-07-28 такого канала нет: сервер возвращает вопросы в ответе, а клиент повторяет вызов. Подробнее - на странице о MRTR.

import asyncio

from mcp import Client


async def main() -> None:
    async with Client("http://localhost:8000/mcp") as client:
        result = await client.call_tool("add", {"a": 1, "b": 2})
        print(result.structured_content)  # {'result': 3}


asyncio.run(main())

Пример взят из документации выпуска 2.3.0 и здесь не запускался.

По документу о версиях, MCPServer отвечает на server/discover на каждом транспорте: Streamable HTTP, stdio и на соединении внутри процесса, которое используют тесты.

Для HTTP документ о старых клиентах описывает правило так: приложение streamable_http_app() обслуживает обе эпохи. Запрос с заголовком MCP-Protocol-Version: 2026-07-28 идёт в новый обработчик. Запрос с версией старой эпохи или без заголовка идёт в старый транспорт с рукопожатием и сеансами.

Старый клиент получает Mcp-Session-Id, а запись о сеансе хранится в обычном словаре внутри процесса. Подключить внешнее хранилище сеансов нельзя. Если рабочих процессов больше одного, старым клиентам нужна привязка к процессу, иначе запрос с чужим идентификатором получит 404. С stateless_http=True сеанс для старого клиента создаётся на один запрос, и привязка не нужна, но сервер уже не может обратиться к клиенту во время вызова.

from mcp.server import MCPServer

mcp = MCPServer("Demo")


@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b


@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

Пример взят из документации выпуска 2.3.0 и здесь не запускался.

README запускает этот файл двумя способами: uv run mcp dev server.py открывает его в MCP Inspector, а uv run mcp run server.py --transport streamable-http поднимает сервер по HTTP для клиента из примера выше. Про Inspector есть отдельная страница.

По README ветки, 1.x - ветка сопровождения: она получает исправления критичных ошибок и обновления безопасности. Команда pip install mcp без ограничения ставит уже 2.x, поэтому для 1.x нужна верхняя граница:

pip install "mcp[cli]<2"

Список версий выпуска 1.30.0 в shared/version.py заканчивается на 2025-11-25. Редакции 2026-07-28 в нём нет, поэтому 1.x - только Legacy.

Tasks. В выпуске 2.3.0 расширение не реализовано. Руководство по переходу говорит прямо: опытная поддержка задач из 1.x удалена вместе с модулями mcp.*.experimental, а новое расширение io.modelcontextprotocol/tasks SDK пока не реализует. Готовой замены нет. В 1.30.0 остаются опытные задачи в форме редакции 2025-11-25; с расширением новой редакции они несовместимы.

MCP Apps. Серверная часть есть: по документу об Apps, SDK поставляет встроенное расширение Apps (io.modelcontextprotocol/ui). Оно связывает инструмент с ресурсом ui://, в котором лежит страница HTML. Сообщения ui/* сервер не отправляет и не получает: они идут между программой-хостом и встроенной страницей. Есть ли в SDK средства для стороны хоста, неизвестно.

Что такое расширения и как о них договариваются стороны - на странице о расширениях.

По документу об устаревшем, SDK по-прежнему реализует всё перечисленное ниже и при первом вызове показывает предупреждение MCPDeprecationWarning:

• Roots, Sampling по запросу сервера, Logging протокола. Работают на соединении, которое согласовало 2025-11-25 или более раннюю версию.
• ping. В редакции 2026-07-28 метод удалён. client.send_ping() работает только на соединении mode="legacy".
• Уведомления о ходе работы от клиента к серверу. В новой редакции ход работы сообщает только сервер.

Отдельно от этого списка:

• HTTP+SSE. По документу о запуске, mcp.run(transport="sse") ещё работает, но оставлен для клиентов, которые не перешли на Streamable HTTP. Строить на нём новое документ не советует.
• Динамическая регистрация клиента. OAuth-клиент SDK умеет и её, и Client ID Metadata Documents. Помечена ли динамическая регистрация как устаревшая в самом коде выпуска, неизвестно.
• Сеансы и initialize. Сохранены для старых клиентов, как описано выше.

Общий список - на странице об устаревших возможностях.

На 4 октября 2026 ветка main указывает на то же изменение, что и метка v2.3.0: расхождений нет. Пробных выпусков новее 2.3.0 на PyPI нет.

• Есть ли в выпуске 2.3.0 программный интерфейс для стороны хоста MCP Apps: документ об Apps описывает только сервер.
• Несёт ли динамическая регистрация клиента пометку об устаревании в коде выпуска: в документации выпуска такой пометки не найдено.
• Есть ли MCP Apps в ветке 1.x: не проверялось.
• Содержимое опубликованных архивов PyPI отдельно не распаковывалось: сверялись исходники по метке выпуска и данные реестра.

• Все официальные SDK
• Версии протокола и эпохи
• Запрос server/discover
• Сервер двух эпох