Что такое MCP и зачем он твоему ИИ-агенту

Claude Code из коробки читает и правит файлы, запускает команды в терминале, ищет по коду. А теперь попросите его показать пять последних заказов из вашей базы или завести задачу в трекере. Он не сможет. Агент живёт внутри репозитория и не видит ничего снаружи: ни базу данных, ни Linear, ни Slack. MCP убирает эту стену.

Проблема: агент заперт в репозитории

У языковой модели есть встроенный набор инструментов: чтение, запись, правка файлов, поиск, запуск команд. Этого хватает, пока задача не выходит за пределы кода. Но реальная разработка почти всегда цепляет внешние системы. Данные лежат в Postgres. Тикеты в Jira или Linear. Логи в одном сервисе, метрики в другом.

Можно, конечно, выдать агенту curl и попросить дёргать API руками. На словах работает, на практике разваливается. Агент каждый раз гадает, какие у эндпоинта поля, путается в авторизации и заново делает одну и ту же чёрную работу. Наутро он забудет формат ответа и переспросит. Нужен способ подключать внешние инструменты один раз и по-человечески, а не заклинанием на каждый запрос.

Что такое MCP

MCP расшифровывается как Model Context Protocol. Это открытый стандарт от Anthropic, который описывает, как подключать внешние инструменты и данные к ИИ-агенту. Ключевое слово тут - стандарт. Вы пишете один сервер для своего API, и его понимает любой агент, который говорит на этом протоколе: Claude Code, Cursor, что угодно. Написали раз, используете везде.

Сравните с USB-C. Раньше у каждого устройства был свой разъём и свой провод, а сумка полнилась переходниками. Потом договорились об одном порту, и стало проще. MCP делает то же самое для связки агента с внешним миром: единый разъём вместо десятка самодельных адаптеров.

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

Разберём на живом примере. Вы пишете агенту: «сколько заказов пришло за вчера». Агент видит подключённый сервер базы данных и его инструмент query_database, формирует SQL, отдаёт серверу. Сервер выполняет запрос у себя на машине, получает число и возвращает его агенту. Дальше агент вставляет это число в ответ или в отчёт, который для вас готовит. Вы не писали ни строчки интеграции, только подключили готовый сервер.

Три примитива: tools, resources, prompts

MCP-сервер отдаёт агенту три типа возможностей. Проще всего понять их по аналогии с обычным веб-API.

Tools, то есть инструменты, это действия. Агент вызывает их, чтобы что-то сделать: query_database, create_ticket, send_message, run_tests. Аналогия - POST-запрос. Именно tools вы будете использовать чаще всего, большинство серверов ими и ограничиваются.

Resources, ресурсы, это данные для чтения. Схема базы, конфиг, кусок документации, снимок метрик. Агент подтягивает их в контекст, когда нужно свериться с фактами. Аналогия - GET-запрос.

Prompts, шаблоны, это заготовки под типовые задачи. Например, сервер базы данных отдаёт шаблон analyze_slow_query, и агент разбирает медленный запрос по готовым правилам, а не выдумывает их с нуля. Аналогия - хранимая процедура.

Примитив	Что это	Аналогия в веб-API
Tools	Действия: агент что-то делает	POST-запрос
Resources	Данные для чтения	GET-запрос
Prompts	Заготовки под типовые задачи	Хранимая процедура

Как это выглядит на практике

Подключение живёт в файле .mcp.json в корне проекта. Вот минимальный пример с тремя готовыми серверами:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://readonly_user:pass@localhost:5432/mydb"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

Каждый блок - это команда запуска сервера. Обычно npx скачивает готовый пакет, поэтому писать код не нужно. Перезапустили Claude Code, убедились, что серверы поднялись, и можно давать команду вроде «покажи структуру таблицы users и пять последних строк». Агент сам вызовет нужный инструмент и вернёт живые данные, а не выдумку.

Готовые серверы под частые задачи уже написаны за вас: filesystem, github, postgres, slack, linear. Каталог лежит на modelcontextprotocol.io и в подборке awesome-mcp-servers.

Одно правило безопасности, которое нельзя нарушать

Секреты держите в переменных окружения через синтаксис ${VAR}, как с GITHUB_TOKEN в примере выше, а не открытым текстом в конфиге. Так токен не утечёт вместе с закоммиченным файлом. Опасные операции вроде деплоя в прод оставьте за пределами MCP: для них есть hook с ручным подтверждением. У сервера, который умеет всё, слишком высокая цена ошибки.

С чего начать

Возьмите два сервера и доведите связку до первого живого ответа.

Когда увидите, как агент отвечает реальными строками из вашей базы, механика щёлкнет в голове раз и навсегда.

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