Что такое MCP и зачем он нужен
Если вы хоть раз слышали «подключи MCP-сервер» и кивали, не понимая, о чём речь, — этот урок для вас. К концу вы будете знать, что такое MCP, какую проблему он решает, что именно делает MCP-сервер и почему разработчикам стало проще давать Claude доступ к Jira, базе данных или внутренней вики.
Проблема: модель умна, но заперта
Языковая модель вроде Claude знает очень много, но у неё нет рук. Она не видит вашу таблицу в Google Sheets, не может заглянуть в задачу в трекере и не знает, что сегодня лежит в папке проекта. Всё, что она получает, — это текст, который вы ей прислали.
Первый способ дать модели «руки» появился давно: разработчик описывает функцию («получить задачу по номеру»), модель просит её вызвать, программа выполняет вызов и возвращает результат. Это называется вызовом инструментов (tool use), и оно прекрасно работает. Но у него есть неприятное свойство: каждую связку «приложение — сервис» приходится писать заново.
Представьте, что в агентстве пять приложений с ИИ (чат для аналитиков, помощник в IDE, бот в Telegram, скрипт для отчётов, ассистент в CRM) и пять сервисов (Jira, GitLab, Confluence, база клиентов, календарь). Чтобы каждое приложение умело работать с каждым сервисом, нужно двадцать пять интеграций. Добавили шестой сервис — ещё пять. Это та же проблема, которая была с зарядками для телефонов до появления единого разъёма.
Решение: один протокол вместо N×M интеграций
MCP (Model Context Protocol, протокол контекста модели) — открытый стандарт, который описывает, как приложение с ИИ и внешний сервис договариваются друг с другом. Сервис один раз оборачивают в MCP-сервер, а приложение один раз учат быть MCP-клиентом. После этого любой клиент работает с любым сервером.
Аналогия с USB здесь самая точная. Производитель клавиатуры не знает, к какому ноутбуку её подключат, а производитель ноутбука не знает, какие устройства в него воткнут. Они оба соблюдают стандарт, и этого достаточно. MCP — такой же разъём, только для ИИ-приложений.
Стандарт открытый: его опубликовала Anthropic в конце 2024 года, а сейчас его поддерживают Claude, Claude Code, Cursor, VS Code и десятки других инструментов. Спецификация и документация живут на modelcontextprotocol.io.
Три участника: хост, клиент, сервер
В MCP всегда три роли, и их легко перепутать.
Хост — приложение, с которым работает человек: приложение Claude, Claude Code, редактор кода. Именно хост запускает модель и решает, что ей показывать.
Клиент — компонент внутри хоста, который держит соединение с одним конкретным сервером. Если к Claude Code подключены три сервера, внутри него работают три клиента. Вы почти никогда не пишете клиент сами — он уже встроен в хост.
Сервер — небольшая программа, которая знает, как обращаться с конкретным сервисом, и выставляет наружу его возможности по правилам MCP. Сервер для GitLab умеет читать merge-request'ы, сервер для базы данных — выполнять запросы, сервер для файловой системы — читать и записывать файлы.
Слово «сервер» здесь сбивает с толку. Это не обязательно что-то большое в облаке. Чаще всего MCP-сервер — это скрипт на сотню строк, который хост запускает у вас на компьютере как обычный процесс и общается с ним через стандартный ввод-вывод. Об этом подробнее в уроке «Архитектура: хост, клиент, сервер».
Что сервер отдаёт наружу
Сервер может предложить хосту три вида вещей. В MCP их называют примитивами.
- Инструменты (tools) — действия, которые модель может вызвать: «создать задачу», «выполнить SQL-запрос», «отправить сообщение». Инструменты выбирает и вызывает сама модель, когда решает, что это нужно.
- Ресурсы (resources) — данные, которые можно прочитать: содержимое файла, страницу документации, запись из базы. Ресурсы обычно подключает человек или хост, чтобы дать модели контекст.
- Промпты (prompts) — готовые шаблоны запросов, которые сервер предлагает пользователю: «проанализировать логи за сегодня», «подготовить релиз-ноты». Это ускорители для типовых сценариев.
Каждому примитиву посвящён отдельный урок, а сейчас достаточно запомнить: инструменты — это «сделать», ресурсы — «прочитать», промпты — «начать типовой разговор».
Как это выглядит в жизни
Разберём типичный сценарий. Тестировщик хочет, чтобы Claude Code воспроизвёл баг из трекера. Без MCP он копирует описание задачи, логи и скриншоты в чат вручную. С MCP-сервером для трекера он пишет: «Воспроизведи баг PROJ-1432 и предложи исправление».
Дальше происходит следующее:
- Claude Code (хост) при запуске подключился к серверу трекера и узнал, что тот умеет: у него есть инструмент «получить задачу по ключу».
- Модель читает запрос, понимает, что ей нужно содержимое задачи, и просит хост вызвать этот инструмент с параметром
PROJ-1432. - Хост через клиент передаёт вызов серверу. Сервер ходит в API трекера, получает задачу и возвращает её текст.
- Модель получает описание бага, находит нужный код, воспроизводит проблему и предлагает патч.
Самое важное: пункт 2 модель делает сама. Никто не писал сценарий «сначала получи задачу, потом ищи код». Модель увидела список доступных инструментов и выбрала подходящий, как человек выбирает нужную вкладку в браузере.
Что MCP не делает
Полезно очертить границы, чтобы не ждать от протокола лишнего.
MCP не делает модель умнее и не добавляет ей знаний. Он даёт доступ к данным и действиям, а решение, что с ними делать, по-прежнему принимает модель.
MCP не решает вопросы безопасности за вас. Сервер с инструментом «удалить все записи» будет послушно удалять записи, если модель его вызовет. Поэтому хосты спрашивают у человека подтверждение перед выполнением инструментов, а хорошие серверы делают опасные операции недоступными или требуют явного флага.
MCP не заменяет обычные API. Под капотом MCP-сервер сам ходит в обычный REST- или GraphQL-API сервиса. Протокол лишь стандартизирует то, как эти возможности описываются для модели.
Попробуйте сами
10–15 мин на рабочем месте- Откройте настройки Claude (раздел с коннекторами) или Claude Code и посмотрите, какие MCP-серверы уже подключены. Для каждого попробуйте ответить: какие инструменты он даёт модели и какой сервис стоит за ним.
- Вспомните три сервиса, которыми вы пользуетесь каждый день (трекер, вики, таблицы, мессенджер). Для каждого напишите одну фразу, которую вы хотели бы сказать Claude, если бы у него был доступ к этому сервису. Это и есть будущие инструменты вашего MCP-сервера.
- Зайдите на modelcontextprotocol.io и найдите список готовых серверов. Отметьте те, которые пригодились бы команде прямо сейчас.
Коротко
- MCP — открытый стандарт подключения ИИ-приложений к внешним сервисам, «USB для ИИ».
- Он превращает задачу «N приложений × M сервисов» в «N клиентов + M серверов».
- Три роли: хост (приложение), клиент (соединение внутри хоста), сервер (обёртка над сервисом).
- Сервер предлагает инструменты (действия), ресурсы (данные) и промпты (шаблоны).
- Модель сама решает, какой инструмент вызвать; хост спрашивает у человека подтверждение.
- MCP-сервер — чаще всего маленький скрипт на вашем компьютере, а не облачный сервис.
Видеоверсия
Сценарий озвучки · 544 слова, ≈ 4 мин
Если вы когда-нибудь слышали фразу «подключи MCP-сервер» и делали вид, что всё понятно, — этот ролик для вас. За пять минут разберём, что это такое и зачем нужно.
Начнём с проблемы. Языковая модель вроде Claude знает очень много, но у неё нет рук. Она не видит вашу таблицу, не может открыть задачу в трекере и не знает, что лежит в папке проекта. Всё, что у неё есть, — это текст, который вы ей прислали.
Первое решение придумали давно: разработчик описывает функцию, например «получить задачу по номеру», модель просит её вызвать, программа выполняет и возвращает результат. Это называется вызов инструментов, и это работает. Но каждую связку между приложением и сервисом приходится писать заново. Пять приложений и пять сервисов — это двадцать пять интеграций. Добавили шестой сервис — пишите ещё пять. Точно так же было с зарядками для телефонов, пока не появился единый разъём.
MCP — это и есть такой разъём. Расшифровывается как Model Context Protocol, протокол контекста модели. Это открытый стандарт, который описывает, как приложение с ИИ и внешний сервис договариваются друг с другом. Сервис один раз оборачивают в MCP-сервер, приложение один раз учат быть MCP-клиентом, и дальше любой клиент работает с любым сервером. Производитель клавиатуры не знает, к какому ноутбуку её подключат, и ему это не нужно. Оба соблюдают стандарт — и всё работает.
В MCP три участника. Хост — это приложение, с которым работает человек: Claude, Claude Code, редактор кода. Клиент — это компонент внутри хоста, который держит соединение с одним сервером. И сервер — небольшая программа, которая знает, как обращаться с конкретным сервисом, и выставляет его возможности наружу по правилам протокола.
Слово «сервер» сбивает с толку. Это не обязательно что-то большое в облаке. Чаще всего MCP-сервер — это скрипт на сотню строк, который хост запускает прямо на вашем компьютере как обычный процесс.
Что сервер отдаёт наружу? Три вида вещей. Инструменты — это действия, которые модель может вызвать: создать задачу, выполнить запрос, отправить сообщение. Ресурсы — это данные, которые можно прочитать: файл, страница документации, запись из базы. И промпты — готовые шаблоны запросов для типовых сценариев. Запомните просто: инструменты — «сделать», ресурсы — «прочитать», промпты — «начать типовой разговор».
Посмотрим на живой пример. Тестировщик хочет, чтобы Claude Code воспроизвёл баг из трекера. Он пишет: «Воспроизведи баг номер тысяча четыреста тридцать два и предложи исправление». Claude Code ещё при запуске подключился к серверу трекера и знает, что у того есть инструмент «получить задачу по ключу». Модель читает запрос, понимает, что ей нужно содержимое задачи, и просит вызвать этот инструмент. Сервер идёт в трекер, забирает задачу и возвращает текст. Модель находит нужный код, воспроизводит проблему и предлагает патч.
Самое важное здесь — что выбор инструмента модель сделала сама. Никто не писал ей сценарий. Она увидела список доступных инструментов и взяла подходящий, как человек открывает нужную вкладку в браузере.
И напоследок о границах. MCP не делает модель умнее — он даёт ей доступ к данным и действиям. MCP не отвечает за безопасность: если сервер умеет удалять записи, модель может это вызвать, поэтому хост всегда спрашивает у вас подтверждение. И MCP не заменяет обычные API: под капотом сервер сам ходит в обычный интерфейс сервиса, а протокол лишь стандартизирует, как эти возможности описаны для модели.
Итак, MCP — это USB для ИИ. Один стандарт вместо десятков интеграций, три роли — хост, клиент и сервер, и три примитива — инструменты, ресурсы и промпты. В следующем уроке разберём архитектуру подробнее и посмотрим, как хост и сервер на самом деле обмениваются сообщениями.