К содержимому урока

MCP-клиенты

Урок 03Введение

Загрузка видео

MCP-клиент служит коммуникационным мостом между вашим сервером и MCP-серверами. Это точка доступа ко всем инструментам, которые предоставляет MCP-сервер: он берет на себя обмен сообщениями и детали протокола, чтобы вашему приложению не пришлось делать это напрямую.

Коммуникация, независимая от транспорта

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

MCP-клиент взаимодействует с локальным MCP-сервером GitHub через стандартные потоки ввода и вывода

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

  • HTTP
  • WebSockets
  • Другие сетевые протоколы

MCP-клиент и MCP-сервер GitHub взаимодействуют через сетевой транспорт

Типы сообщений MCP

После подключения клиент и сервер обмениваются типами сообщений, определёнными в спецификации MCP. Основные типы, с которыми вы будете работать:

ListToolsRequest запрашивает доступные инструменты, а ListToolsResult возвращает их определения

ListToolsRequest/ListToolsResult: Клиент спрашивает сервер: «Какие инструменты ты предоставляешь?» — и получает список доступных инструментов.

CallToolRequest запускает инструмент с аргументами, а CallToolResult возвращает результат

CallToolRequest/CallToolResult: Клиент просит сервер выполнить конкретный инструмент с заданными аргументами, а затем получает результат.

Как все работает вместе

Вот полный пример того, как запрос пользователя проходит через всю систему: от вашего сервера через MCP-клиент к внешним сервисам вроде GitHub и обратно к Claude.

Допустим, пользователь спрашивает: «Какие у меня репозитории?» Пошаговый процесс выглядит так:

  1. Запрос пользователя: Пользователь отправляет вопрос на ваш сервер
  2. Обнаружение инструментов: Вашему серверу нужно узнать, какие инструменты доступны, чтобы передать их Claude
  3. Обмен списком инструментов: Ваш сервер спрашивает MCP-клиент о доступных инструментах
  4. Коммуникация MCP: MCP-клиент отправляет ListToolsRequest MCP-серверу и получает ListToolsResult
  5. Запрос к Claude: Ваш сервер отправляет Claude запрос пользователя вместе с доступными инструментами
  6. Решение о вызове инструмента: Claude решает, что для ответа нужно вызвать инструмент
  7. Запрос на выполнение инструмента: Ваш сервер просит MCP-клиент выполнить инструмент, который указал Claude
  8. Вызов внешнего API: MCP-клиент отправляет CallToolRequest MCP-серверу, а тот выполняет реальный вызов GitHub API
  9. Возврат результатов: GitHub возвращает данные репозиториев, которые проходят обратно через MCP-сервер как CallToolResult
  10. Результат инструмента для Claude: Ваш сервер отправляет результаты инструмента обратно Claude
  11. Итоговый ответ: Claude формирует итоговый ответ на основе данных репозиториев
  12. Пользователь получает ответ: Ваш сервер возвращает ответ Claude пользователю

Последовательность от вопроса пользователя до получения списка инструментов, вызова GitHub и итогового ответа Claude

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

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