MCP Course, юнит 1 (часть 1): понятия, архитектура, протокол

Это перевод первой половины юнита 1 курса MCP Course от Hugging Face, сделанного вместе с Anthropic. Вторая половина юнита — SDK, клиенты, сервер Hugging Face и Gradio. Что есть в курсе целиком — в путеводителе.

Как читать вместе с курсом ChinaAI

Этот текст — популярное введение в протокол. Читайте его перед уроком 8.3.2 «Инструменты и MCP»: там те же понятия разобраны строже, с живыми сообщениями протокола и сервером, написанным руками. Курс писался весной 2025 года по ревизиям спецификации 2025-03-26 и 2025-06-18. С тех пор протокол заметно поменялся (в 2026 году он стал работать без состояния), поэтому там, где текст курса устарел или упрощает до неточности, мы добавили примечания переводчика со ссылками на урок 8.3.2. Что такое инструменты и вызов инструментов вообще — в уроке 8.3.1.

1.1. Введение в Model Context Protocol (MCP)

Добро пожаловать в юнит 1 курса по MCP! В этом юните мы разберём основы Model Context Protocol — «протокола контекста модели».

Чему вы научитесь

В этом юните вы:

• поймёте, что такое Model Context Protocol и почему он важен;
• узнаете ключевые понятия и термины MCP;
• разберётесь, какие проблемы интеграции решает MCP;
• пройдёте по главным преимуществам и целям MCP;
• увидите простой пример интеграции через MCP в действии.

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

Почему MCP важен

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

Здесь и появляется Model Context Protocol (MCP). MCP позволяет моделям ИИ подключаться к внешним источникам данных, инструментам и средам, так что информация и возможности свободно передаются между системами ИИ и остальным цифровым миром. Такая совместимость (interoperability) критически важна для роста и распространения по-настоящему полезных приложений ИИ.

Обзор юнита 1

Вот коротко, что мы разберём в этом юните:

1. Что такое Model Context Protocol? — начнём с определения MCP и его роли в экосистеме ИИ.
2. Ключевые понятия — разберём основные идеи и термины MCP.
3. Проблемы интеграции — посмотрим, какие проблемы решает MCP, прежде всего «проблему интеграции M×N».
4. Преимущества и цели — обсудим главные плюсы и цели MCP: стандартизацию, расширение возможностей ИИ и совместимость.
5. Простой пример — в конце пройдём по простому примеру интеграции через MCP, чтобы увидеть, как это работает на практике.

Погрузимся в увлекательный мир Model Context Protocol!

1.2. Ключевые понятия и термины

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

MCP часто называют «USB-C для приложений ИИ». Как USB-C даёт стандартный физический и логический разъём для подключения самых разных устройств к компьютеру, так MCP предлагает единый протокол для подключения моделей ИИ к внешним возможностям. Стандартизация выгодна всей экосистеме:

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

Проблема интеграции

Проблема интеграции M×N — это задача подключить M разных приложений ИИ к N разным внешним инструментам или источникам данных, когда стандартного способа нет.

Без MCP (проблема M×N)

Без протокола вроде MCP разработчикам пришлось бы делать M×N отдельных интеграций — по одной на каждую возможную пару «приложение ИИ — внешняя возможность».

(В оригинале — рисунок: каждое приложение ИИ соединено с каждым инструментом своей линией. Ссылка на рисунок.)

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

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

(В оригинале — рисунок с несколькими моделями и инструментами и паутиной связей между ними. Ссылка на рисунок.)

С MCP (решение M+N)

MCP превращает задачу в M+N, давая стандартный интерфейс: каждое приложение ИИ один раз реализует клиентскую сторону MCP, а каждый инструмент или источник данных один раз реализует серверную сторону. Это резко снижает сложность интеграции и затраты на поддержку.

flowchart LR
subgraph A["M приложений ИИ"]
  A1["Чат"]
  A2["IDE"]
  A3["Свой агент"]
end
P{{"MCP"}}
subgraph T["N инструментов и данных"]
  T1["Файлы"]
  T2["GitHub"]
  T3["База данных"]
  T4["Погода"]
end
A1 --> P
A2 --> P
A3 --> P
P --> T1
P --> T2
P --> T3
P --> T4

С MCP нужно 3 + 4 = 7 реализаций вместо 3 × 4 = 12 попарных интеграций (рисунок переводчика по мотивам оригинала)

(Пример с числами от переводчика: 10 приложений и 50 инструментов без общего стандарта — это до 10 × 50 = 500 отдельных интеграций; с MCP — 10 клиентов и 50 серверов, то есть 60 реализаций.)

Основные термины MCP

Разобравшись, какую проблему решает MCP, перейдём к основным терминам и понятиям протокола.

Совет

MCP — это стандарт, как HTTP или USB-C: протокол для подключения приложений ИИ к внешним инструментам и источникам данных. Поэтому единая терминология критически важна для того, чтобы MCP работал как надо.

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

Компоненты

Как и в клиент-серверных отношениях в HTTP, в MCP есть клиент и сервер.

(В оригинале — схема: хост, внутри него клиенты, каждый клиент связан с одним сервером. Ссылка на рисунок.)

• Хост (Host) — приложение ИИ, с которым напрямую работает пользователь. Например, Claude Desktop от Anthropic, IDE с ИИ вроде Cursor, библиотеки инференса вроде Python SDK Hugging Face или собственные приложения на библиотеках вроде LangChain и smolagents. Хост инициирует подключения к MCP-серверам и управляет всем потоком между запросами пользователя, обработкой в LLM и внешними инструментами.

• Клиент (Client) — компонент внутри хост-приложения, который ведёт обмен данными с конкретным MCP-сервером. Каждый клиент держит соединение один-к-одному с одним сервером, берёт на себя детали протокола MCP и служит посредником между логикой хоста и внешним сервером.

• Сервер (Server) — внешняя программа или сервис, которая предоставляет возможности (инструменты, ресурсы, промпты) по протоколу MCP.

Осторожно

Во многих материалах слова «клиент» и «хост» используют как синонимы. Строго говоря, хост — это приложение, с которым работает пользователь, а клиент — компонент внутри хоста, который ведёт обмен данными с конкретным MCP-сервером.

Возможности

Конечно, ценность приложения — это сумма возможностей, которые оно даёт. Поэтому возможности (capabilities) — самая важная часть вашего приложения. MCP может подключаться к любому программному сервису, но есть несколько типичных возможностей, которые используются во многих приложениях ИИ.

Возможность	Описание	Пример
Инструменты (Tools)	Исполняемые функции, которые модель ИИ может вызвать, чтобы выполнить действие или получить вычисленные данные. Обычно связаны с назначением приложения	Инструмент приложения погоды — функция, которая возвращает погоду в заданном месте
Ресурсы (Resources)	Источники данных только для чтения, которые дают контекст без сложных вычислений	У ассистента исследователя может быть ресурс с научными статьями
Промпты (Prompts)	Заранее заданные шаблоны или сценарии, которые направляют взаимодействие между пользователем, моделью ИИ и доступными возможностями	Промпт для краткого пересказа
Сэмплирование (Sampling)	Запросы, которые инициирует сервер: он просит клиента или хост выполнить обращение к LLM. Это позволяет рекурсивные действия, где LLM проверяет сгенерированное и принимает следующие решения	Приложение для письма проверяет собственный текст и решает доработать его

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

(В оригинале — схема агента кода: LLM в хосте связана с инструментом-интерпретатором, ресурсом с документацией, промптом о стиле кода и сэмплированием для ревью. Ссылка на рисунок.)

Такое приложение может использовать сущности MCP так:

Сущность	Название	Описание
Инструмент	Интерпретатор кода	Инструмент, который выполняет код, написанный LLM
Ресурс	Документация	Ресурс с документацией приложения
Промпт	Стиль кода	Промпт, который подсказывает LLM, как писать код
Сэмплирование	Ревью кода	Сэмплирование, которое позволяет LLM проверить код и принять дальнейшие решения

Примечание переводчика: кто кому что предоставляет

Строго по спецификации инструменты, ресурсы и промпты — возможности сервера, а сэмплирование — возможность клиента, к которой обращается сервер. Позже в спецификацию добавились и другие клиентские возможности: elicitation (сервер просит пользователя уточнить данные) и roots (клиент сообщает, с какими папками серверу можно работать). В ревизии 2026-07-28 сэмплирование и roots объявлены устаревшими. Подробнее — в уроке 8.3.2.

Заключение

Эти ключевые понятия и термины — фундамент для эффективной работы с MCP. В следующих разделах мы будем строить на нём: разберём архитектурные компоненты, протокол обмена данными и возможности, из которых состоит Model Context Protocol.

1.3. Архитектурные компоненты MCP

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

Хост, клиент и сервер

Model Context Protocol построен на клиент-серверной архитектуре, которая обеспечивает структурированный обмен данными между моделями ИИ и внешними системами.

(В оригинале — схема архитектуры: хост с LLM и несколькими клиентами, каждый клиент подключён к своему серверу, серверы — к локальным данным и удалённым сервисам. Ссылка на рисунок.)

flowchart LR
U(["Пользователь"]) --> H
subgraph H["Хост: чат, IDE или ваш агент"]
  LLM["LLM"]
  C1["Клиент 1"]
  C2["Клиент 2"]
end
C1 <-->|"stdio"| S1["Сервер: файлы"]
C2 <-->|"HTTP"| S2["Сервер: погода"]
S1 --- D1[("Локальный диск")]
S2 --- D2[("API погоды")]

Хост, клиенты и серверы (рисунок переводчика)

Архитектура MCP состоит из трёх основных компонентов с чётко определёнными ролями и обязанностями: хост, клиент и сервер. Мы уже касались их в прошлом разделе, а теперь разберём каждый компонент и его обязанности подробнее.

Хост

Хост — приложение ИИ, с которым напрямую работает пользователь.

Примеры:

• чат-приложения ИИ вроде ChatGPT от OpenAI или Claude Desktop от Anthropic;
• IDE с ИИ вроде Cursor или интеграции в инструменты вроде Continue.dev;
• собственные агенты и приложения ИИ на библиотеках вроде LangChain или smolagents.

Обязанности хоста:

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

Чаще всего пользователи выбирают хост-приложение по своим нуждам и вкусам. Например, разработчик может выбрать Cursor за мощные возможности редактирования кода, а специалисты в предметной области — собственные приложения на smolagents.

Клиент

Клиент — компонент внутри хост-приложения, который ведёт обмен данными с конкретным MCP-сервером. Его главные черты:

• каждый клиент держит соединение один-к-одному с одним сервером;
• берёт на себя детали протокола MCP;
• служит посредником между логикой хоста и внешним сервером.

Сервер

Сервер — внешняя программа или сервис, которая предоставляет возможности моделям ИИ по протоколу MCP. Серверы:

• дают доступ к конкретным внешним инструментам, источникам данных или сервисам;
• служат лёгкими обёртками вокруг уже существующей функциональности;
• могут работать локально (на той же машине, что и хост) или удалённо (по сети);
• описывают свои возможности в стандартном формате, который клиенты могут обнаружить и использовать.

Как идёт обмен данными

Посмотрим, как эти компоненты взаимодействуют в типичном сценарии MCP.

Совет

В следующем разделе мы подробнее, на практических примерах, разберём протокол, через который общаются эти компоненты.

1. Действие пользователя. Пользователь работает с хост-приложением и формулирует намерение или вопрос.

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

3. Подключение клиента. Хост поручает своему компоненту-клиенту подключиться к нужному серверу (или серверам).

4. Обнаружение возможностей. Клиент спрашивает сервер, какие возможности (инструменты, ресурсы, промпты) тот предоставляет.

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

6. Выполнение на сервере. Сервер выполняет запрошенное и возвращает результат клиенту.

7. Встраивание результата. Клиент передаёт результат хосту, а тот добавляет его в контекст LLM или показывает напрямую пользователю.

Главное преимущество этой архитектуры — модульность. Один хост может одновременно подключаться ко многим серверам через разных клиентов. Новые серверы можно добавлять в экосистему без изменений в существующих хостах. Возможности разных серверов легко комбинировать.

Совет

Как мы обсуждали в прошлом разделе, такая модульность превращает привычную проблему интеграции M×N (M приложений ИИ подключаются к N инструментам и сервисам) в куда более управляемую задачу M+N: каждому хосту и серверу достаточно один раз реализовать стандарт MCP.

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

Заключение

Эти схемы взаимодействия опираются на несколько ключевых принципов, которые определяют устройство и развитие MCP. Протокол делает упор на стандартизацию, предлагая универсальный протокол для подключения ИИ, и сохраняет простоту: ядро протокола несложное, но позволяет продвинутые возможности. В приоритете безопасность: для чувствительных операций требуется явное согласие пользователя. Обнаруживаемость позволяет находить возможности динамически. Протокол спроектирован с расчётом на расширяемость — он развивается через версии и согласование возможностей — и обеспечивает совместимость между разными реализациями и средами.

В следующем разделе мы разберём протокол обмена данными, благодаря которому эти компоненты работают вместе.

Тест 1: основы MCP

Проверьте, как вы усвоили основные понятия Model Context Protocol.

Тест 1: основы MCP5 вопросов·

1 Какова главная цель Model Context Protocol (MCP)?

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

2 Какую проблему прежде всего решает MCP?

Нехватку моделей ИИВысокую стоимость обучения LLMПроблему интеграции M×NТрудность создания новых алгоритмов ИИ

3 Что из этого — ключевое преимущество MCP?

Снижение точности моделей ИИРост сложности разработки ИИСтандартизация и совместимость в экосистеме ИИИзоляция моделей ИИ от внешних систем

4 Что такое «хост» в терминах MCP?

Внешняя программа, которая предоставляет возможностиПриложение ИИ, с которым работает пользовательИсточник данных только для чтенияЗаранее заданный шаблон взаимодействия

5 Что такое «проблема интеграции M×N» применительно к приложениям ИИ?

Трудность обучения M моделей на N датасетахЗадача подключить M приложений ИИ к N внешним инструментам без общего стандартаПроблема управления M пользователями в N приложенияхСложность разработки M функций для N групп пользователей

Проверить ответы

Поздравляем с прохождением теста 🥳! Если нужно что-то повторить, вернитесь к разделам выше.

1.4. Протокол обмена данными

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

Осторожно

Мы спускаемся к самым тонким деталям протокола MCP. Чтобы строить что-то на MCP, всё это знать не обязательно, но полезно понимать, что оно есть и как работает.

JSON-RPC: фундамент

В основе MCP лежит JSON-RPC 2.0 — формат всех сообщений между клиентами и серверами. JSON-RPC — лёгкий протокол удалённого вызова процедур (remote procedure call), закодированный в JSON. Поэтому он:

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

(В оригинале — схема трёх типов сообщений: запрос и ответ идут парой с одинаковым id, уведомление — в одну сторону без ответа. Ссылка на рисунок.)

Протокол определяет три типа сообщений.

1. Запросы

Отправляются от клиента серверу, чтобы начать операцию. Сообщение-запрос содержит:

• уникальный идентификатор (id);
• имя вызываемого метода (например, tools/call);
• параметры метода (если они есть).

Пример запроса:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "weather",
    "arguments": {
      "location": "San Francisco"
    }
  }
}

(Здесь клиент просит сервер вызвать инструмент weather с аргументом «место = Сан-Франциско».)

2. Ответы

Отправляются от сервера клиенту в ответ на запрос. Сообщение-ответ содержит:

• тот же id, что и у соответствующего запроса;
• либо result (при успехе), либо error (при неудаче).

Пример успешного ответа:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "temperature": 62,
    "conditions": "Partly cloudy"
  }
}

Пример ответа с ошибкой:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Invalid location parameter"
  }
}

(«Partly cloudy» — «переменная облачность», «Invalid location parameter» — «недопустимый параметр места». Код −32602 в JSON-RPC означает «неверные параметры».)

Примечание переводчика: настоящий ответ на tools/call выглядит иначе

Пример успешного ответа в курсе упрощён. По спецификации MCP результат вызова инструмента — это объект с массивом content (куски текста, картинки, ссылки на ресурсы) и флагом isError, например "result": {"content": [{"type": "text", "text": "62°F, переменная облачность"}], "isError": false}. Начиная с ревизии 2025-06-18 инструмент может дополнительно вернуть структурированные данные в поле structuredContent. Ещё важно различать два вида ошибок: error — когда сломан сам запрос (нет такого метода, неизвестный инструмент), и result с isError: true — когда инструмент отработал с ошибкой; такую ошибку хост передаёт модели, чтобы она исправила вызов. Подробно — в уроке 8.3.2.

3. Уведомления

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

Пример уведомления:

{
  "jsonrpc": "2.0",
  "method": "progress",
  "params": {
    "message": "Processing data...",
    "percent": 50
  }
}

(«Processing data…» — «Обрабатываю данные…», выполнено 50%. Обратите внимание: у уведомления нет id, поэтому на него и не отвечают. В самой спецификации уведомление о прогрессе называется notifications/progress и ссылается на запрос через progressToken; в курсе пример упрощён.)

Транспортные механизмы

JSON-RPC задаёт формат сообщений, а MCP дополнительно определяет, как эти сообщения передаются между клиентами и серверами. Поддерживаются два основных транспортных механизма.

stdio (стандартный ввод/вывод)

Транспорт stdio используется для локального обмена, когда клиент и сервер работают на одной машине.

Хост-приложение запускает сервер как дочерний процесс и общается с ним: пишет в его стандартный ввод (stdin) и читает из его стандартного вывода (stdout).

Совет

Где применяется: локальные инструменты, например доступ к файловой системе или запуск локальных скриптов.

Главные преимущества этого транспорта: он простой, не требует настройки сети и надёжно изолирован средствами операционной системы.

HTTP + SSE (Server-Sent Events) / Streamable HTTP

Транспорт HTTP+SSE используется для удалённого обмена, когда клиент и сервер могут быть на разных машинах.

Обмен идёт по HTTP, а сервер с помощью Server-Sent Events (SSE, «события, отправляемые сервером») отправляет клиенту обновления по постоянному соединению.

Совет

Где применяется: подключение к удалённым API, облачным сервисам или общим ресурсам.

Главные преимущества этого транспорта: он работает по сети, позволяет интегрироваться с веб-сервисами и совместим с бессерверными (serverless) средами.

В недавних обновлениях стандарта MCP появился или был доработан «Streamable HTTP». Он гибче: сервер может при необходимости переключиться на SSE для потоковой передачи, оставаясь совместимым с бессерверными средами.

(Примечание переводчика: точнее, в ревизии 2025-03-26 Streamable HTTP заменил прежний транспорт HTTP+SSE, и старый вариант объявлен устаревшим. Для новых удалённых серверов используйте Streamable HTTP; SSE внутри него остаётся лишь как способ отправлять поток событий в ответ на запрос.)

Жизненный цикл взаимодействия

В прошлом разделе мы обсудили жизненный цикл одного обмена между клиентом (💻) и сервером (🌐). Теперь посмотрим на жизненный цикл полного взаимодействия клиента и сервера по протоколу MCP.

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

sequenceDiagram
participant C as 💻 Клиент
participant S as 🌐 Сервер
Note over C,S: Инициализация
C->>S: initialize
S-->>C: response
C-)S: initialized
Note over C,S: Обнаружение
C->>S: tools/list
S-->>C: response
Note over C,S: Выполнение
C->>S: tools/call
S--)C: notification (прогресс, необязательно)
S-->>C: response
Note over C,S: Завершение
C->>S: shutdown
S-->>C: response
C-)S: exit

Жизненный цикл соединения в изложении курса (в оригинале — четыре таблицы со стрелками)

Инициализация

Клиент подключается к серверу, и они обмениваются версиями протокола и возможностями: сервер отвечает, какую версию протокола и какие возможности он поддерживает.

Клиент подтверждает, что инициализация завершена, сообщением-уведомлением.

Обнаружение

Клиент запрашивает сведения о доступных возможностях, и сервер отвечает списком доступных инструментов.

Это можно повторить для каждого типа: инструментов, ресурсов, промптов.

Выполнение

Клиент вызывает возможности в соответствии с нуждами хоста.

Завершение

Когда соединение больше не нужно, его аккуратно закрывают, и сервер подтверждает запрос на завершение.

Клиент отправляет последнее сообщение exit, чтобы закончить завершение.

Примечание переводчика: этап завершения описан неверно

Сообщений shutdown и exit в спецификации MCP нет — они взяты из похожего протокола LSP (Language Server Protocol, которым IDE общаются с анализаторами кода). В MCP соединение завершают средствами транспорта: при stdio клиент закрывает стандартный ввод сервера и, если тот не завершился сам, останавливает процесс; при HTTP просто закрываются соединения. Этапы инициализации и обнаружения описаны верно для ревизий до 2025-11-25 включительно (уведомление о завершении инициализации в спецификации называется notifications/initialized). В ревизии 2026-07-28 MCP стал протоколом без состояния: рукопожатия initialize больше нет, версия и возможности клиента передаются в каждом запросе. Как это выглядит на проводе — в уроке 8.3.2.

Развитие протокола

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

1.5. Возможности MCP

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

Совет

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

В следующих юнитах мы покажем, как эти понятия реализуются в коде для MCP.

Инструменты

Инструменты (tools) — исполняемые функции или действия, которые модель ИИ может вызвать через протокол MCP.

• Кто управляет: инструменты обычно управляются моделью — модель ИИ (LLM) сама решает, когда их вызвать, исходя из запроса пользователя и контекста.
• Безопасность: инструменты могут выполнять действия с побочными эффектами, поэтому их выполнение может быть опасным. Обычно на это требуется явное согласие пользователя.
• Где применяются: отправка сообщений, создание задач в трекере, запросы к API, вычисления.

Пример: инструмент погоды, который получает текущую погоду для заданного места:

Python

def get_weather(location: str) -> dict:
    """Get the current weather for a specified location."""
    # Подключаемся к API погоды и получаем данные
    return {
        "temperature": 72,
        "conditions": "Sunny",
        "humidity": 45
    }

JavaScript

function getWeather(location) {
    // Подключаемся к API погоды и получаем данные
    return {
        temperature: 72,
        conditions: 'Sunny',
        humidity: 45
    };
}

(Докстринги оставлены на английском: в настоящем MCP-сервере именно они становятся описанием инструмента для модели. Перевод: «Получить текущую погоду для указанного места». Температура дана в градусах Фаренгейта: 72°F ≈ 22°C.)

Ресурсы

Ресурсы (resources) дают доступ только на чтение к источникам данных, позволяя модели ИИ получать контекст без выполнения сложной логики.

• Кто управляет: ресурсы управляются приложением — обычно хост-приложение решает, когда к ним обратиться.
• Природа: они предназначены для получения данных с минимальными вычислениями, как GET-эндпоинты в REST API.
• Безопасность: раз они только для чтения, риски обычно ниже, чем у инструментов.
• Где применяются: чтение содержимого файлов, получение записей из базы данных, чтение настроек.

Пример: ресурс, который даёт доступ к содержимому файла:

Python

def read_file(file_path: str) -> str:
    """Read the contents of a file at the specified path."""
    with open(file_path, 'r') as f:
        return f.read()

JavaScript

function readFile(filePath) {
    // Читаем содержимое файла через fs.readFile
    const fs = require('fs');
    return new Promise((resolve, reject) => {
        fs.readFile(filePath, 'utf8', (err, data) => {
            if (err) {
                reject(err);
                return;
            }
            resolve(data);
        });
    });
}

(Докстринг: «Прочитать содержимое файла по указанному пути». В настоящем MCP ресурс адресуется URI — например, file:///project/README.md, — а не произвольным путём в аргументе.)

Промпты

Промпты (prompts) — заранее заданные шаблоны или сценарии, которые направляют взаимодействие между пользователем, моделью ИИ и возможностями сервера.

• Кто управляет: промпты управляются пользователем — часто они показаны как пункты в интерфейсе хоста.
• Назначение: они выстраивают взаимодействие так, чтобы инструменты и ресурсы использовались наилучшим образом.
• Выбор: обычно пользователь выбирает промпт до того, как модель начинает работу, и тем самым задаёт контекст.
• Где применяются: типовые сценарии, шаблоны для специальных задач, пошаговые взаимодействия.

Пример: шаблон промпта для ревью кода:

Python

def code_review(code: str, language: str) -> list:
    """Generate a code review for the provided code snippet."""
    return [
        {
            "role": "system",
            "content": f"You are a code reviewer examining {language} code. Provide a detailed review highlighting best practices, potential issues, and suggestions for improvement."
        },
        {
            "role": "user",
            "content": f"Please review this {language} code:\n\n```{language}\n{code}\n```"
        }
    ]

JavaScript

function codeReview(code, language) {
    return [
        {
            role: 'system',
            content: `You are a code reviewer examining ${language} code. Provide a detailed review highlighting best practices, potential issues, and suggestions for improvement.`
        },
        {
            role: 'user',
            content: `Please review this ${language} code:\n\n\`\`\`${language}\n${code}\n\`\`\``
        }
    ];
}

(Тексты промпта оставлены на английском, как в оригинале. Системное сообщение: «Ты — ревьюер, который проверяет код на языке …. Дай подробный разбор: лучшие практики, возможные проблемы и предложения по улучшению». Сообщение пользователя: «Пожалуйста, проверь этот код на …» — и сам код в блоке.)

Сэмплирование

Сэмплирование (sampling) позволяет серверам просить клиента (а точнее, хост-приложение) выполнить обращение к LLM.

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

Пример: сервер может попросить клиента проанализировать данные, которые он обработал:

Python

def request_sampling(messages, system_prompt=None, include_context="none"):
    """Request LLM sampling from the client."""
    # В настоящей реализации здесь был бы запрос к клиенту
    return {
        "role": "assistant",
        "content": "Analysis of the provided data..."
    }

JavaScript

function requestSampling(messages, systemPrompt = null, includeContext = 'none') {
    // В настоящей реализации здесь был бы запрос к клиенту
    return {
        role: 'assistant',
        content: 'Analysis of the provided data...'
    };
}

function handleSamplingRequest(request) {
    const { messages, systemPrompt, includeContext } = request;
    // В настоящей реализации здесь обрабатывался бы запрос и возвращался ответ
    return {
        role: 'assistant',
        content: 'Response to the sampling request...'
    };
}

Сэмплирование проходит так:

1. Сервер отправляет клиенту запрос sampling/createMessage.
2. Клиент проверяет запрос и может его изменить.
3. Клиент получает ответ от LLM.
4. Клиент проверяет сгенерированный ответ.
5. Клиент возвращает результат серверу.

Совет

Такая схема с участием человека (human-in-the-loop) гарантирует, что пользователь сохраняет контроль над тем, что LLM видит и генерирует. Реализуя сэмплирование, важно давать понятные, хорошо структурированные промпты и добавлять нужный контекст.

(Примечание переводчика: в ревизии 2026-07-28 сэмплирование объявлено устаревшим — серверам советуют обращаться к LLM напрямую через API провайдера. Многие клиенты его так и не поддержали. См. урок 8.3.2.)

Как возможности работают вместе

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

Возможность	Кто управляет	Направление	Побочные эффекты	Нужно согласие	Типичное применение
Инструменты	модель (LLM)	клиент → сервер	да (возможно)	да	действия, вызовы API, изменение данных
Ресурсы	приложение	клиент → сервер	нет (только чтение)	обычно нет	получение данных, сбор контекста
Промпты	пользователь	сервер → клиент	нет	нет (их выбирает пользователь)	пошаговые сценарии, специальные шаблоны
Сэмплирование	сервер	сервер → клиент → сервер	косвенно	да	многошаговые задачи, агентное поведение

Эти возможности задуманы так, чтобы дополнять друг друга:

1. Пользователь может выбрать промпт, чтобы начать специальный сценарий.
2. Промпт может включать контекст из ресурсов.
3. В ходе работы модель ИИ может вызывать инструменты для конкретных действий.
4. Для сложных операций сервер может использовать сэмплирование, чтобы запросить дополнительную обработку в LLM.

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

Процесс обнаружения

Одна из ключевых особенностей MCP — динамическое обнаружение возможностей. Подключившись к серверу, клиент может узнать доступные инструменты, ресурсы и промпты через специальные методы-списки:

• tools/list — узнать доступные инструменты;
• resources/list — узнать доступные ресурсы;
• prompts/list — узнать доступные промпты.

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

Заключение

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

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

(Примечание переводчика: на самом деле следующий раздел курса — об SDK; Gradio разобран чуть позже. Продолжение — на странице «юнит 1, часть 2».)

Словарик

English	Русский
Model Context Protocol (MCP)	протокол контекста модели
host / client / server	хост / клиент / сервер
capability	возможность
tool / resource / prompt	инструмент / ресурс / промпт
sampling	сэмплирование (сервер просит LLM хоста сгенерировать ответ)
interoperability	совместимость
M×N integration problem	проблема интеграции M×N
JSON-RPC: request / response / notification	запрос / ответ / уведомление
transport: stdio, Streamable HTTP, SSE	транспорт: стандартный ввод/вывод, потоковый HTTP, события от сервера
lifecycle: initialization, discovery, execution	жизненный цикл: инициализация, обнаружение, выполнение
human-in-the-loop	с участием человека