MCP: как работает Model Context Protocol

LLM уже некоторое время умеют вызывать инструменты, но Model Context Protocol (MCP) дает для этого структурированный и стандартизованный способ.

При этом до сих пор есть путаница в том, чем MCP на самом деле является.

Многие считают, что MCP это приложение, API или какой-то инструмент, но это не так. Это протокол, а значит, речь идет о вполне конкретной категории.

Разберем по шагам.

Если вы хотите сразу увидеть, что MCP дает на практике, посмотрите это короткое видео:

Что такое протокол?

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

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

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

Или представьте это как USB-C для AI-инструментов. Двадцать лет назад рынок был заполнен разными типами кабелей для зарядки и передачи данных. Похожим образом в AI-экосистемах было несколько способов передавать инструменты языковым моделям. Такие фреймворки, как LangChain, Haystack и Pydantic AI, определяли собственные форматы для интеграции инструментов. Это означало, что если разработчик хотел написать набор инструментов для Google Maps, ему приходилось делать это для каждой конкретной технологии.

Чтобы сделать это более наглядным, рассмотрим самый популярный протокол, HTTP (Hypertext Transfer Protocol), на котором работают сайты. HTTP, среди прочего, определяет, как браузер (клиент) запрашивает веб-страницу у веб-сервера и как сервер должен отвечать.

Вот пример цикла HTTP-запроса и ответа:

1. Браузер делает HTTP-запрос

Когда вы вводите https://example.com в браузере, браузер отправляет структурированный HTTP-запрос веб-серверу:

Вот HTTP-параметры и значения, используемые в нашем примере:

"GET" – Это действие (запрос веб-страницы).
"/index.html" – Конкретная запрашиваемая веб-страница.
"HTTP/1.1" – Версия используемого протокола.
"Host: example.com" – Доменное имя сайта.
"User-Agent: Mozilla/5.0" – Информация о браузере, который делает запрос.

Веб-сервер знает, как интерпретировать этот запрос, потому что HTTP стандартизирует этот формат. Он понимает этот «язык».

2. Сервер отвечает с использованием протокола HTTP

Сервер обрабатывает запрос и отправляет структурированный HTTP-ответ:

"HTTP/1.1 200 OK" – Код ответа (200 означает успех).
"Content-Type: text/html" – Тип отправляемого содержимого.
"Content-Length: 512" – Размер ответа.
HTML Content – Фактическое содержимое веб-страницы (там только заголовок "Welcome to Example.com")

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

Как MCP работает как протокол

Теперь применим тот же подход к MCP (Model Context Protocol).

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

Что это за «инструменты»?

В контексте LLM инструменты, это внешние системы, API или сервисы, с которыми AI может взаимодействовать, чтобы расширить свои возможности за пределы генерации текста. Они позволяют AI-агентам получать данные в реальном времени, записывать на встречи или отправлять сообщения вашим друзьям, что делает их гораздо полезнее для реальных задач.

Допустим, вы спрашиваете AI-агента:

«Который сейчас час в Лондоне?»

Поскольку сам AI не знает правильного ответа, так как AI-модели имеют дату отсечения знаний (октябрь 2023 года для моделей OpenAI), ему нужно получить актуальные данные из сервиса времени. Но вместо того чтобы использовать HTTP для запроса веб-страницы, AI использует MCP для запроса данных о времени.

Вот что происходит:

1. AI-агент делает MCP-запрос к сервису времени (пример)

"method": "tools.call" → AI вызывает внешний инструмент.
"tool": "get_time" → Имя инструмента, который он хочет использовать.
"args": { "location": "London" } → Конкретные входные параметры.

Как и в HTTP, этот запрос следует строгому формату, чтобы любой MCP-совместимый инструмент точно знал, как его интерпретировать.

2. MCP-сервер времени отвечает

Внешний инструмент (сервер времени) следует правилам ответа MCP и отправляет:

"status": "success" → Подтверждает, что запрос был обработан корректно.
"result" → Содержит фактические данные о времени.

Теперь AI-агент может взять эти данные и составить настоящий ответ пользователю:

«Текущее время в Лондоне, 12:20 PM (GMT).»

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

«MCP, это приложение.» → Нет, MCP, это набор правил. Чтобы реально использовать его, вам нужно AI-ПО и инструменты, которые реализуют MCP, так же как приложению Instagram нужны работающие серверы Instagram, чтобы отвечать на HTTP-запросы и отдавать данные.

«MCP, это база данных.» → Нет, MCP не хранит данные. Он помогает AI-агентам взаимодействовать с базами данных или API.

«MCP похож на API.» → Не совсем. API, это конкретный способ взаимодействия с одной системой, а протокол (например, MCP или HTTP) определяет универсальный способ взаимодействия множества разных систем. MCP, это язык, который AI-система может использовать для взаимодействия со множеством реальных API (время, базы данных, Stripe, Slack и т. д.).

Почему MCP вызывает интерес

Теперь, когда мы знаем, что MCP, это стандартизированный способ взаимодействия AI-ПО с внешними инструментами и приложениями, и что MCP не является API, разберем, почему сообщество AI-разработчиков (включая нас) заинтересовалось им.

Поскольку MCP не является API, а позволяет AI-приложениям взаимодействовать с реальными API в масштабе, он помогает быстрее запускать проекты, которым нужно подключаться ко множеству внешних систем. Инструменты также дают модели доступ к внешнему миру, и то, что произошло в инциденте OpenAI Hugging Face, показывает, как выглядит такой доступ, когда он выходит за рамки задачи. Для этого разработчикам иногда приходилось проходить полный цикл разработки API-интеграции, но сегодня они обычно используют существующие библиотеки или open-source-проекты (например, доступные на GitHub), которые предоставляют нужную функциональность.

Использование таких библиотек ускоряет старт разработки, но их корректная интеграция с вашей системой (если она несовместима с реализацией, которую вы нашли на GitHub) все равно требует усилий, чтобы инструмент работал с AI.

С MCP, когда фреймворк уже настроен, добавление новой интеграции (например, интеграции Google Drive) может свестись к подключению к MCP-серверу Google Drive несколькими строками кода. Вы не столкнетесь с проблемами совместимости, потому что обе стороны используют один и тот же протокол: MCP.

Сравним оба подхода, чтобы яснее увидеть различия.

Стандартная интеграция и использование Model Context Protocol (MCP)

Чтобы сделать сравнение конкретным, пройдем процесс добавления доступа к файлам Google Drive для AI Agent, сначала вручную, а затем с MCP-совместимым инструментом.

Стандартная интеграция

1. Найти и адаптировать библиотеку: вы ищете клиент Google Drive API или open-source-проект. Google предоставляет клиентские библиотеки (например, Google Drive API for Python), вы добавляете такую библиотеку в проект. При этом вам все равно нужно убедиться, что она работает в окружении вашего AI.

2. Реализовать логику: вы пишете функции, например для поиска файлов или получения документа из Drive. Когда AI что-то нужно, он должен вызывать эти функции. Вы преобразуете запрос AI в API-вызовы, специфичные для Google Drive. Получив ответ от Google, вы извлекаете содержимое, чтобы передать его обратно в контекст AI.

3. Обработать ошибки и граничные случаи: добавляете код для обработки случаев вроде «файл не найден», ошибок прав доступа или лимитов частоты API-запросов. Если API Google возвращает ошибку, вы перехватываете ее и, возможно, отвечаете извиняющимся сообщением или просите AI переформулировать запрос. Также нужно защититься от ситуации, когда ваш AI отправляет слишком много запросов слишком быстро.

4. Поддерживать: со временем, если Google обновит API или библиотеку, вам придется обновить свой код. Если вы найдете баг в библиотеке, возможно, придется исправлять его самостоятельно или искать другой источник. По сути, вы становитесь сопровождающим этой интеграции Google Drive внутри вашего AI-приложения.

Этот процесс распространяется и на другие инструменты: хотите добавить Slack или базу данных к вашему AI? Нужно повторить весь процесс для каждого из них.

Интеграция MCP

Теперь посмотрим, как этот процесс выглядел бы при использовании MCP.

Сначала определим ключевые понятия:

Client – AI-приложение (ChatGPT, приложение Claude, Quickchat AI), которое устанавливает соединение с одним или несколькими серверами и запрашивает информацию или действия для выполнения задач, заданных пользователем.

Server – каждый сервер может подключаться к чему-то вроде базы данных, API (Google Drive) и определять набор «инструментов» или данных, которые он может предоставить. В этом случае сервер, это программа, которая предоставляет эти инструменты и возможности Client (AI-приложению).

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

• Инициализация MCP-сервера. Разработчик или системный администратор настраивает MCP-сервер для конкретного инструмента или источника данных. MCP-сервер обычно представляет собой небольшую программу, реализующую спецификацию MCP. Например, есть готовый MCP-сервер Google Drive, который умеет искать и получать документы.

  При инициализации сервера вы даете ему доступ к целевой системе (Google Drive). Затем сервер предоставляет набор инструментов, соответствующих действиям или запросам, которые он может обрабатывать. По сути, это API-адаптер, который говорит на MCP с одной стороны и на нативном языке сервиса с другой стороны.

  Когда сервер запущен, он ожидает запросы.

• Подключение LLM (клиента) к MCP-серверу. Далее AI-приложению (сторона «клиента») нужно подключиться к этому серверу. На практике, если вы используете AI-платформу с поддержкой MCP (например, Claude Desktop), вы указываете в конфигурации адрес или команду для запуска сервера. После подключения клиент устанавливает с сервером сессию, следуя handshake MCP. Если вы используете интерфейс Claude, вы увидите, что Claude «подключен» к определенным MCP-серверам (UI может показывать доступные коннекторы).

Так это выглядит в Claude UI

• Обнаружение доступных инструментов. После установления соединения первое, что нужно сделать, это узнать, что предлагает сервер (иногда это происходит автоматически после подключения к серверу). MCP-клиент отправляет серверу запрос tools/list (это определено в протоколе). Сервер отвечает списком доступных инструментов, у каждого из которых есть данные вроде имени, описания и схемы входных параметров.

  Например, сервер может ответить, что у него доступны инструменты create_file(path, content), read_file(path) и search_files(query). Затем клиент делает эту информацию доступной для LLM. Во многих реализациях клиент форматирует описания инструментов и включает их в контекст модели (например, добавляет в системный prompt: «У вас есть доступ к следующим инструментам… [список инструментов]»).

Вот системный prompt AI вместе с сообщением пользователя, который запрашивает текущее время

При реализованных MCP-инструментах интегрируется инструмент с именем “get_current_time”, который позволяет AI обратиться к внешнему ресурсу и получить точное время в Лондоне

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

• Использование инструмента через MCP. Когда AI нужно выполнить действие или получить данные, он вызывает инструмент через MCP. С точки зрения AI (особенно для таких моделей, как Claude, которые нативно поддерживают использование инструментов), он решит в рассуждении: «Мне нужно вызвать инструмент X с такими параметрами». MCP-клиент фиксирует это намерение и отправляет запрос tools/call в формате MCP на соответствующий сервер (MCP-сервер Google Drive).

• MCP-сервер действует как мост. Он получает структурированный MCP-совместимый запрос от AI-агента, сопоставляет его с правильным endpoint Google Drive API, переписывает запрос в настоящий вызов Google Drive API, выполняет запрос, обрабатывает ответ и снова форматирует его в MCP-совместимый ответ перед отправкой обратно AI-агенту.

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

  Допустим, AI Agent использует MCP-инструмент, чтобы найти файл в Google Drive. Если запрос содержит недопустимый ID файла (например, строку длиной пять символов вместо ожидаемого формата), MCP-сервер вернет сообщение об ошибке:

  Вместо простого сбоя AI Agent может взять этот структурированный ответ и преобразовать его в понятную пользователю обратную связь:

  “Похоже, указанный вами ID файла слишком короткий. ID файлов Google Drive обычно имеют длину 28 символов. Проверьте его и попробуйте еще раз.”

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

• Ответ на вопрос или запрос пользователя. Когда MCP-сервер возвращает результат, MCP-клиент передает эти данные обратно AI-приложению. Затем модель включает результат в свои рассуждения или напрямую в ответ, который генерирует для пользователя.

  Если пользователь просит создать новый файл Google Sheets, ответ сервера (с ID файла и сгенерированной ссылкой) будет передан модели. Затем модель ответит пользователю: «Готово. Ваш новый файл Google Sheets создан. Вы можете открыть его здесь: [link].»

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

Преимущества использования MCP

Обратите внимание, как этот подход скрывает многие детали: клиент не обрабатывал API-ключи или HTTP-статусы, это делает MCP-сервер.

Главная идея, это простота в точке интеграции: мы «запрашиваем» клиентов и получаем их. Логика того, как их получить, инкапсулирована в другом месте. Это означает, что разработчику, работающему на стороне AI, не нужно писать новые HTTP-вызовы для каждого нового действия, он просто вызывает инструменты по имени. Основную работу (auth, вызов endpoints Google Drive, форматирование ответа) выполняет код MCP-сервера, который можно переиспользовать и который стандартизирован.

Вот краткое описание ключевых преимуществ:

• Уменьшает объем связующего кода, специфичного для API. До MCP, чтобы заставить AI использовать внешний сервис, обычно требовалось писать много «связующего» кода: вызывать API, преобразовывать ответ в текст, который модель может обработать, затем разбирать вывод модели, чтобы, возможно, вызвать другой API, и так далее. С MCP значительная часть этого связующего кода исчезает. Клиент модели и сервер обмениваются данными структурированным образом, поэтому вам не нужно вручную преобразовывать другие форматы (например, JSON) в текст и обратно, это делает протокол. Также не нужно писать логику, которая решает, когда что вызывать. Это делает AI (направляемый описаниями инструментов и собственными рассуждениями или prompt).

• Переиспользуемые общие коннекторы вместо одноразовых API-оберток. С MCP вы пишете интеграцию один раз и можете переиспользовать ее во многих проектах и AI-системах. Например, можно создать MCP-сервер для внутренней wiki вашей компании. Любое AI-приложение с поддержкой MCP сможет подключиться к этому серверу и запрашивать wiki. Вам не нужно заново реализовывать «поиск по wiki» для каждого нового AI-чатбота или каждого другого поставщика LLM. Такая переиспользуемость отличается от прошлого подхода, когда каждая команда могла писать собственную, немного отличающуюся интеграцию для одного и того же API. MCP поощряет библиотеку коннекторов, которыми можно делиться и которые можно совместно улучшать.

• Plug-and-play-интеграция с разными LLM. MCP не зависит от модели. Протоколу не важно, является ли клиентом Claude, GPT-4, DeepSeek или любая будущая модель, если клиент умеет работать с интерфейсом MCP. В будущем, если вы захотите перейти на другую модель, вы сможете сделать это без переписывания всех интеграций.

• Более простая поддержка. Поскольку это открытый стандарт, вокруг него растет сообщество, которое вносит готовые серверы (для баз данных, популярных API и т. д.), и вы можете использовать их вместо разработки с нуля. По мере интеграции все большего числа систем MCP помогает избежать «спагетти» из множества точечных интеграций. И вам не нужно отслеживать все обновления API от других провайдеров.

Станут ли API-интеграции устаревшими?

И традиционные API-интеграции, и MCP имеют свое место. Лучший подход может зависеть от характера проекта, экспертизы команды и долгосрочных целей.

Если вам нужно интегрироваться только с одним или двумя внешними сервисами, а взаимодействия относительно простые, прямое подключение к API часто является самым быстрым решением. Если вашему веб-приложению нужно только проверить платежный токен Stripe при checkout, прямой вызов API Stripe прост и эффективен. Введение MCP в таком сценарии может быть избыточным. Вы можете подключить AI Agent к любому документированному REST API с помощью одного проверенного HTTP Action или использовать интеграцию в один клик, например Google Sheets для записи лидов и запросов на демо, без запуска MCP-сервера.

В случаях, когда вам нужен очень строгий контроль над request/response (для настройки производительности, специальной обработки данных или проприетарных протоколов), прямой код к API может быть лучше. Традиционные интеграции позволяют использовать все продвинутые возможности API и точно настраивать вызовы. Если у API есть необычные требования или если вы хотите избежать любого слоя абстракции для максимальной ясности и контроля, традиционный подход уместен.

Конкретный пример того, как MCP-инструменты предоставляются production AI Agent вместе с кастомными API-действиями, см. в том, как Quickchat AI Agents объединяют оба подхода. Более подробное обсуждение того, когда использовать MCP, отдельные AI Actions или “Generate from Text”, находится в статье API для AI Agents: от MCP до кастомных endpoints. Чтобы попробовать самостоятельно, следуйте пошаговому руководству как подключить ваш AI Agent к удаленному MCP-серверу, чтобы он вызывал живой инструмент в середине разговора.

Список доступных MCP-серверов

Если вы хотите начать работу с MCP, посмотрите каталоги MCP-серверов ниже:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Вы также можете запустить его без написания кода: любой Quickchat AI Agent можно превратить в MCP-сервер с hosted URL, который Claude, ChatGPT и Cursor вызывают как инструмент. Соединение работает и в обратную сторону: Quickchat AI Agent может вызывать hosted MCP-сервер поставщика как свои инструменты. Именно так AI-помощник для планирования на базе MCP-сервера Calendly проверяет реальную доступность и бронирует встречи из чата, а AI-чатбот Notion отвечает из живого help center и записывает запросы поддержки обратно в базу данных Notion.

Quickchat AI также запускает удаленный MCP-сервер для вашего собственного аккаунта. Подключите его к ChatGPT, Claude, Cursor или Codex, и вы сможете управлять своими AI Agents оттуда: аналитика, transcripts разговоров, обновления knowledge base и создание новых Agent, все за одним входом через OAuth. Пошаговая настройка для каждого клиента описана в статье Управляйте своим AI Agent из ChatGPT, Claude и Codex с помощью MCP.

FAQ

Работает ли это только с Claude?

MCP не зависит от модели. Протоколу не важно, является ли клиентом Claude, GPT-4, локальная производная LLaMA или любая будущая модель, если клиент умеет работать с интерфейсом MCP. Это означает, что при создании интеграций инструментов вы не привязаны к одному AI-провайдеру.

Чем MCP отличается от того, чтобы сразу дать модели всю нужную информацию? Почему бы просто не набить prompt данными?

MCP принципиально отличается от заполнения prompt модели данными, потому что позволяет модели динамически получать информацию по мере необходимости, а не работать со статическим заранее загруженным prompt. Добавление большого объема текста в prompt упирается в ограничения, поскольку у AI-моделей фиксированное контекстное окно. Это означает, что слишком большой объем данных может привести к потере важных деталей, замедлить ответы и увеличить расходы на API (из-за моделей оплаты за токены, используемых поставщиками LLM). Кроме того, такой подход дает знания только на один момент времени, тогда как MCP обеспечивает доступ к живым внешним данным в реальном времени и позволяет AI выполнять действия, а не только читать информацию. AI с заполненным prompt может знать данные клиента, но не сможет обновлять записи или обрабатывать транзакции.

Что если мы подключим к AI десятки инструментов? Не перегрузит ли это модель и не приведет ли к неправильному использованию инструментов?

Это зависит от реализации, но верно, что у текущих LLM есть ограничения в том, насколько хорошо они различают и выбирают между множеством вариантов. Если предоставить модели, например, 50 возможных инструментов, есть риск, что она выберет неправильный. Сам подход MCP не заставляет загружать все сразу. Вы должны подключать релевантные инструменты в зависимости от контекста. Лучшая практика, подключать только инструменты, которые нужны для текущей задачи или домена, и использовать multiagent collaboration, то есть своего рода маршрутизацию инструментов или агента, который сначала решает, какое подмножество инструментов следует рассматривать.

MCP и Function Calling

Традиционный function calling (как в API OpenAI или других LLM) позволяет разработчику определить набор функций, передать их определения модели и дать модели возможность «вызывать» их по имени с аргументами. Это был большой шаг для AI-интеграции, но у него есть ограничения. Одно из главных различий, это то, когда и как определяются инструменты. В классическом function calling все возможные функции должны быть объявлены заранее (на этапе проектирования) в prompt или через API. Модель может вызывать только эти фиксированные функции. В MCP инструменты можно обнаруживать во время выполнения, AI может запрашивать, что доступно, и даже получать новые инструменты в середине сессии.

MCP и GPT Actions & Plugins

GPT Actions/Plugins относятся к экосистеме OpenAI, где можно было включать plugins (например, веб-браузер или PDF reader) для ChatGPT, или “GPTs” (кастомные агенты ChatGPT), которые могут использовать инструменты. Это было интересно, но требовало кастомной разработки для каждого plugin и было ограничено платформами OpenAI. Если вам был нужен plugin ChatGPT для задачи, нужно было создать API и manifest, а также пройти одобрение OpenAI или как минимум включить его вручную. Каждый plugin по сути был отдельным silo: plugin погоды, plugin путешествий и т. д., каждый со своими endpoints и логикой. MCP улучшает эту концепцию, унифицируя ее и делая открытой.

MCP и RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG), это техника, при которой LLM дополняется внешней базой знаний. Обычно RAG включает в себя векторную базу данных или поисковый индекс: запрос пользователя используется для получения релевантных документов или данных (семантическим поиском или другими методами), а эти документы передаются модели как дополнительный контекст для «чтения» при формировании ответа. RAG служит для передачи модели знаний, которых у нее изначально не было, и особенно полезен для фактологических QA или доменной информации. Однако RAG доступен только для чтения, модель извлекает текстовые фрагменты, но не выполняет действий за пределами retrieval.

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