MCP-серверы

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

Что такое MCP простыми словами

MCP расшифровывается как Model Context Protocol — «протокол контекста для модели». Звучит технично, но идея за этим простая. Это единый стандарт-переходник, через который агент получает доступ к инструментам, сервисам и данным за пределами твоего проекта.

Представь розетку. У тебя дома один тип розетки, а приборов — десятки: чайник, ноутбук, лампа. Им не нужно договариваться друг с другом, они просто втыкаются в общий стандарт и получают питание. MCP работает так же. Есть агент, и есть внешний мир — браузеры, базы данных, рабочие сервисы. Чтобы агент мог с ними работать, кто-то должен сделать «вилку» под каждый из них. MCP — это и есть общая форма вилки, на которую все согласились.

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

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

Зачем это вообще нужно

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

Тебе нужно, чтобы он проверил, как реально выглядит твоя страница в браузере? Сам по себе он этого не видит. Нужно вытащить данные из рабочей базы? Без доступа он только догадывается, что там лежит. Нужно завести задачу в системе, где живёт твоя команда? Он про неё не знает. Во всех этих случаях агент начинает «болтать» — выдавать правдоподобные предположения вместо реальных действий. А предположение, выданное уверенным тоном, — это худшее, что может сделать помощник.

MCP закрывает этот разрыв. Он превращает агента из собеседника, который рассуждает о твоей работе, в исполнителя, который в эту работу залезает руками: смотрит реальное состояние, меняет его, проверяет результат.

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

Механика везде одна. Ты прописываешь MCP-сервер в конфиге Claude Code — указываешь, какой сервер подключить и с какими параметрами доступа. После перезапуска у агента появляются новые инструменты. Дальше ты ничего специально не делаешь: агент сам решает, когда они нужны.

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

Конфиг — это файл .mcp.json в корне твоего проекта; внутри него верхний ключ так и называется — mcpServers. Концептуально запись выглядит так — один блок на каждый сервер:

"mcpServers": {
  "browser": { "command": "...", "args": ["..."] },
  "database": { "command": "...", "args": ["..."] }
}

Конкретные команды зависят от сервера и берутся из его инструкции. Суть в том, что это просто список: добавил строчку — появились руки, убрал — пропали.

Полезные категории коннекторов

Не буду называть бренды — экосистема меняется быстро, и важнее понимать категории. Под рабочие и бизнес-задачи обычно полезны такие группы:

• Доступ к вебу. Поиск по интернету и чтение страниц. Агент перестаёт ограничиваться тем, что знал на момент обучения, и работает с актуальной информацией и первоисточниками.
• Работа с браузером. Агент открывает страницы, кликает, заполняет формы, делает скриншоты. Незаменимо, когда нужно глазами проверить интерфейс или пройти сценарий как живой пользователь.
• Базы данных. Прямые запросы к твоим данным. Вместо догадок «наверное, в таблице такие-то поля» агент смотрит реальную схему и реальные строки.
• Системы задач и трекеры. Создание и обновление задач, чтение тикетов. Агент встраивается в тот процесс, где уже живёт твоя команда.
• Файловые хранилища. Доступ к документам и файлам за пределами проекта — там, где лежат твои рабочие материалы.
• Коммуникации. Чтение и отправка сообщений в мессенджерах и почте — чтобы агент мог доносить результат туда, где ты его реально увидишь.

Это не обязательный набор. Это палитра. Берёшь из неё ровно то, что нужно под твою конкретную работу.

Как выбирать и не подключать лишнее

Здесь новичков подстерегает соблазн: подключить всё подряд, «чтобы было». Не делай так. У каждого сервера есть цена, и она не только в деньгах.

Во-первых, контекст. Каждый подключённый сервер добавляет агенту описание своих инструментов, и это место в его «оперативной памяти». Десяток лишних серверов — это десяток наборов инструкций, которые агент таскает с собой постоянно, даже когда они не нужны. Внимание размывается, ответы становятся хуже.

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

Правило простое: подключай сервер под реальную, текущую нужду, а не «на всякий случай». Появилась задача, где без браузера никак, — подключил браузер. Нет задачи — нет сервера. Лишний инструмент не помогает, он мешает.

Безопасность: доступ — это не игрушка

Главное, что нужно усвоить про MCP: если ты дал агенту доступ к чему-то, он этим реально может пользоваться. Это не симуляция и не «посмотреть одним глазком». Подключил сервер к базе с правом записи — агент может в эту базу писать и удалять. Подключил доступ к рабочему сервису — он может там что-то менять.

Отсюда несколько здравых границ:

• Не цепляй агента к боевым системам, пока не разобрался. Сначала потренируйся на тестовом окружении, на копии данных, на песочнице. Боевая база и живой рабочий сервис — не место для первых экспериментов.
• Давай минимально необходимый доступ. Если задача — только читать данные, не выдавай право на запись. Чем уже доступ, тем меньше площадь возможной ошибки.
• Понимай, что именно ты подключаешь. Прежде чем прописать сервер в конфиг, разберись, что он умеет и к чему получит доступ. «Поставил по инструкции из интернета, не глядя» — плохой план, когда речь о ключах от твоих систем.

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

Коротко

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

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