MCP-сервер простыми словами: зачем ИИ-агенту внешние инструменты

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

Языковая модель внутри агента (с самим понятием агента можно разобраться в статье что такое ИИ-агент) — это застывший слепок текста. Она обучена на огромном массиве данных до определённой даты и сама по себе с тех пор не меняется. У неё нет открытой вкладки браузера, нет подключения к вашей базе данных, нет доступа к файлам на диске. Всё, что она умеет — читать текст, который ей подложили в контекст, и писать текст в ответ. Назовём это «мозг за стеклом»: рассуждает модель блестяще, но стекло физически не пропускает ничего нового, пока кто-то не поднесёт к нему текст с другой стороны.

Хорошая аналогия — эксперт, которого заперли в кабинете без телефона и окна и попросили дать точный прогноз. Он прекрасно разбирается в климате и помнит статистику за сто лет, но у него нет доступа к показаниям датчиков за дверью прямо сейчас. Сколько бы он ни рассуждал, ответ останется образованной догадкой, а не наблюдением. Инструмент — это и есть то самое окно, которое кто-то наконец прорубил в стене кабинета.

Агент не научился видеть мир — ему просто стали чаще подносить к стеклу свежий лист с текстом.

Так что же происходит, когда агент всё-таки «проверяет» что-то? Он не превращается на секунду в браузер. Модель формулирует что-то вроде «мне нужно вызвать функцию X с такими-то параметрами», этот запрос перехватывает код агента, выполняет реальное действие — обращается к базе, дёргает API, читает файл — и кладёт результат обратно в тот же контекст, который видит модель. Модель читает уже готовый ответ как обычный текст и продолжает рассуждать поверх него. Для пользователя это выглядит как «агент посмотрел», а по сути — агент вызвал инструмент, а модель прочитала то, что инструмент вернул.

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

В терминологии протокола приложение, с которым вы разговариваете, называют host — это Claude Desktop, Claude Code или любое другое приложение-агент, которое вы открываете на экране. Внутри host живёт MCP-client — встроенный модуль, который умеет говорить на языке протокола с внешними MCP-серверами. Дальше в статье для простоты мы чаще будем говорить просто «агент», имея в виду host вместе с его клиентом, но если встретите эти два термина отдельно — теперь понятно, что за ними стоит.

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

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

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

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

Разберём по шагам. Агент получает вашу задачу и в процессе рассуждения решает, что ему не хватает актуальных данных — ответить только по памяти не получится. MCP-клиент, встроенный в агента, обращается к одному или нескольким MCP-серверам и спрашивает: какие инструменты у тебя есть? Сервер отвечает списком — с именами, описаниями и схемами параметров (к этому мы вернёмся чуть ниже). Агент выбирает подходящий инструмент, клиент формирует вызов в стандартном формате (на практике это сообщения в духе JSON-RPC — читаемый, структурированный текст) и отправляет его серверу. Сервер выполняет реальную работу — идёт в базу, вызывает внешний API, читает файл — и возвращает результат клиенту. Клиент кладёт этот результат обратно в контекст модели, и дальше модель продолжает рассуждать уже с учётом свежих данных.

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

У MCP-сервера на самом деле есть не только инструменты. Спецификация выделяет три основных примитива:

В повседневных разговорах про MCP чаще всего имеют в виду именно инструменты — это самый заметный примитив, и дальше мы тоже сосредоточимся на нём.

Разница не в красноречии ответа — современная модель одинаково гладко напишет текст в обоих случаях. Разница в том, на чём этот текст основан.

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

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

{
  "name": "get_keyword_rankings",
  "description": "Возвращает текущие позиции заданных ключевых слов в поисковой выдаче для указанного домена и региона.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "domain": {
        "type": "string",
        "description": "Домен сайта, например mysite.com"
      },
      "keywords": {
        "type": "array",
        "items": { "type": "string" },
        "description": "Список ключевых фраз для проверки"
      },
      "region": {
        "type": "string",
        "description": "Регион поиска, например ru-RU"
      }
    },
    "required": ["domain", "keywords"]
  }
}

Три поля здесь делают всю работу. name — машиночитаемый идентификатор, по которому клиент вызывает инструмент. description — это то, что реально читает модель, принимая решение; хорошо написанное описание повышает шанс, что агент вызовет инструмент в нужный момент и не перепутает его с похожим — по сути, тот же навык, что и в промпт-инжиниринге, только объектом становится не весь диалог, а одна функция. inputSchema задаёт структуру параметров — агент обязан собрать вызов, который ей соответствует, а сервер вправе отклонить всё, что не прошло валидацию.

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

Разберём, как это выглядело бы одним конкретным циклом. Пользователь спрашивает агента: «Как там позиции по запросу «купить плед» на mysite.com?» Модель в процессе рассуждения решает, что для точного ответа ей нужны текущие данные, и находит среди доступных инструментов get_keyword_rankings — описание подходит по смыслу. Клиент собирает вызов с domain: mysite.com и keywords: ["купить плед"], сервер идёт за данными (в реальности — к какой-то системе ранжирования или парсеру выдачи) и возвращает, условно, структуру вида {"купить плед": {"position": 7, "url": "mysite.com/catalog/pledy"}}. Этот фрагмент попадает в контекст модели, и уже оттуда она собирает человеческий ответ: «Сейчас позиция седьмая, ведёт страница /catalog/pledy». Ни одно число в этом ответе модель не придумала сама — она аккуратно пересказала то, что вернул инструмент.

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

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

Это не повод относиться к протоколу с подозрением — то же самое можно сказать про любой стандарт вроде HTTP или USB-C: сам по себе разъём не защитит от плохого кабеля и не ускорит медленное устройство. Но держать эти ограничения в голове полезно, особенно прежде чем подключать агента к системе с правом что-то менять, а не только читать.

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

Самый частый сценарий — агент в инструменте для разработки: Claude Code, Claude Desktop и похожие окружения умеют подключаться к MCP-серверам, которые дают доступ к файловой системе проекта, к git, к таск-трекеру, к документации, к базе данных на стейджинге. Это во многом основа того, что называют вайбкодингом: агент не просто пишет код по описанию, а может сам проверить, проходят ли тесты, посмотреть лог ошибки, заглянуть в соседний файл — потому что у него есть подключённый инструмент, а не только то, что вы вставили в чат руками.

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

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

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

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

Коротко закроем вопросы, которые обычно возникают первыми.

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

• Посмотрите, какие MCP-серверы уже существуют для систем, которыми вы пользуетесь каждый день — файлы, git, таск-трекеры, базы данных, поисковая аналитика
• Перед подключением сервера прочитайте список его инструментов — что именно он может прочитать и что может изменить
• Начните с инструментов только для чтения, прежде чем давать агенту права на запись или изменение данных
• Проверьте, под какими учётными данными работает сервер, и не выдавайте доступ шире, чем нужно для конкретной задачи
• Протестируйте связку на некритичных данных или в песочнице, прежде чем подключать боевые системы
• Храните ключи и токены для MCP-серверов там же, где остальные секреты проекта — не в истории переписки с агентом