MCP-клиенты

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

Видео 4:56 и текст урока

К концу урока вы сможете:

объяснить роль MCP-клиента;
назвать способы связи клиента и сервера (транспорты);
пройти весь поток сообщений от вопроса пользователя до ответа Claude.

Видео и текст урока.

Смотреть урок на Skilljar MCP clients · 4:56

MCP-клиент — мост между вашим сервером и MCP-серверами. Это ваша точка доступа ко всем инструментам, которые даёт MCP-сервер. Когда нужно воспользоваться внешними инструментами или сервисами, клиент берёт на себя передачу сообщений и все детали протокола.

Независимость от транспорта

Одна из сильных сторон MCP — независимость от транспорта (transport agnostic). Проще говоря, клиент и сервер могут общаться разными способами. Самая распространённая схема — клиент и сервер на одной машине, общаются через стандартный ввод/вывод.

На нашем сервере MCP-клиент, который общается через стандартный ввод/вывод с локальным MCP-сервером GitHub. — MCP-клиент и локальный MCP-сервер GitHub общаются через стандартный ввод/вывод (stdio).

Но вы не ограничены этим вариантом. MCP-клиенты и серверы могут соединяться и через:

HTTP;
WebSockets;
другие сетевые протоколы.

MCP-клиент на нашем сервере общается с отдельным MCP-сервером GitHub через WebSockets. — Тот же клиент, но связь с отдельным MCP-сервером — по сети.

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

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

MCP-клиент отправляет ListToolsRequest MCP-серверу GitHub и получает ListToolsResult со списком инструментов. — ListToolsRequest → ListToolsResult: клиент узнаёт, какие инструменты есть у сервера.

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

Тот же обмен ListToolsRequest и ListToolsResult. — Список инструментов приходит в ListToolsResult.

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

MCP-клиент отправляет CallToolRequest MCP-серверу GitHub, тот возвращает CallToolResult. — CallToolRequest → CallToolResult: сервер выполняет инструмент и возвращает результат.

Полный пример потока

Вот как все части работают вместе в реальном сценарии. Пользователь спрашивает «What repositories do I have?» — полный поток обмена:

Схема потока со столбцами: пользователь, наш сервер, MCP-клиент, MCP-сервер, GitHub и Claude; сообщений пока нет. — Участники: пользователь, ваш сервер, MCP-клиент, MCP-сервер, GitHub и Claude.

Всё начинается, когда пользователь отправляет запрос на ваш сервер. Сервер понимает, что прежде чем делать запрос, Claude нужно передать список доступных инструментов.

Единственная стрелка пока — от пользователя к нашему серверу с вопросом «What repositories do I have?». — Первая стрелка: вопрос пользователя «What repositories do I have?».

Ваш сервер просит у MCP-клиента инструменты; клиент отправляет MCP-серверу ListToolsRequest и получает в ответ ListToolsResult.

Наш сервер говорит MCP-клиенту «I need a list of tools to send to Claude», клиент спрашивает MCP-сервер. — «I need a list of tools to send to Claude» — клиент запрашивает инструменты у MCP-сервера.

Теперь у вашего сервера есть всё для первого запроса к Claude — и вопрос пользователя, и доступные инструменты.

Наш сервер отправляет Claude вопрос и инструменты одним шагом «Query + Tools». — Вопрос и инструменты уходят Claude одним запросом («Query + Tools»).

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

После ToolUse от Claude наш сервер говорит MCP-клиенту «Please run this tool with these args». — Получив ToolUse, сервер просит клиента: «Please run this tool with these args».

Ваш сервер просит MCP-клиента выполнить запрошенный Claude инструмент. MCP-клиент отправляет CallToolRequest MCP-серверу, а тот делает настоящий запрос к GitHub.

Схема из шести дорожек от User до GitHub, заканчивается CallToolRequest и запросом MCP-сервера к GitHub. — CallToolRequest доходит до MCP-сервера, и тот обращается к GitHub.

GitHub возвращает данные о репозиториях. Они идут обратно через MCP-сервер в виде CallToolResult, затем к MCP-клиенту и, наконец, к вашему серверу.

Схема запроса о репозиториях с новым сообщением toolResult от нашего сервера к Claude. — Результат возвращается Claude в сообщении с toolResult.

Ваш сервер отправляет результаты инструмента обратно Claude в следующем сообщении. Теперь у Claude есть всё, чтобы составить полный ответ.

Полная схема: ответ Claude «Your repositories are…» идёт через наш сервер к пользователю. — Ответ Claude «Your repositories are…» через ваш сервер возвращается пользователю.

Наконец, Claude отвечает оформленным ответом, и ваш сервер передаёт его пользователю.

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

Пояснение

Транспорты по спецификации. Текущая спецификация MCP (2026-07-28) определяет два стандартных транспорта: stdio (сервер — подпроцесс клиента, сообщения через стандартные потоки) и Streamable HTTP (каждое сообщение — HTTP POST на одну конечную точку MCP, ответы — JSON или поток SSE). WebSockets в число стандартных не входит: его можно реализовать как пользовательский транспорт.
Формат сообщений. Все сообщения MCP — JSON-RPC. Названия вроде ListToolsRequest — имена типов в SDK; в самом протоколе это методы tools/list и tools/call (а для ресурсов и промптов — resources/read, prompts/get и т. п.).
Схема курса = обычный tool use. Посмотрите на поток: Claude по-прежнему получает инструменты в tools и отвечает tool_use, а ваш сервер — как и в блоке про инструменты — выполняет вызов и отправляет tool_result. Разница только в том, что «выполнение» — это запрос к MCP-серверу через клиента.

Дальше

Дальше — практика: учебный проект с CLI-чатом, своим MCP-клиентом и своим MCP-сервером.

Оригинал урока: MCP clients.