MCP сервер: что это и зачем он нужен AI-агенту

MCP сервер — это слой, через который AI-приложение или агент получает стандартизованный доступ к внешним инструментам, данным и действиям. Он не является самим агентом. Его задача — показать агенту, какие возможности доступны, какие входные параметры нужны и какой результат вернется после вызова.

Если говорить проще, MCP сервер стоит между AI-агентом и внешней системой: репозиторием, Jira, GitLab, Confluence, Figma, браузером, базой данных или внутренним API. Агент не должен знать все детали каждого API заранее. Он может через MCP client увидеть список tools, resources и prompts, выбрать нужное действие и получить результат в понятном формате.

Главное разделение такое: MCP отвечает за подключение и доступ, а рабочая процедура, права записи, preview, human review и политика команды живут уровнем выше.

В MCP обычно есть несколько ролей, и их полезно не смешивать.

• AI-приложение или host — среда, где пользователь работает с моделью: чат, IDE, coding agent, внутренний ассистент.
• MCP client — часть host-приложения, которая устанавливает соединение с конкретным MCP server и передает запросы туда и обратно.
• MCP server — отдельный процесс или сервис, который открывает агенту доступ к конкретной системе или набору возможностей.
• External system — реальный источник данных или действий: Jira, GitLab, GitHub, файловая система, база данных, браузер, Figma, Confluence.
• Tool — вызываемое действие: найти issue, прочитать файл, выполнить поиск, создать комментарий, запустить проверку.
• Resource — данные или контекст, которые можно прочитать: документ, схема базы, файл, страница, список задач.
• Prompt — шаблон инструкции или сценария, который сервер может предложить клиенту.

У одного host-приложения может быть несколько MCP clients, а каждый client обычно связан с отдельным server. Поэтому агент может одновременно работать с несколькими специализированными MCP серверами, но границы доступа лучше задавать для каждого подключения отдельно.

MCP сервер нужен не для красоты архитектуры, а для практического расширения возможностей агента.

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

Для coding agent это особенно заметно: один сервер может дать доступ к репозиторию, другой — к задачам, третий — к браузерной проверке, четвертый — к документации. Агент получает не абстрактное “подключение ко всему”, а набор конкретных возможностей с описаниями и схемами параметров.

MCP легко переоценить, если считать его готовой системой управления агентом. Это не так.

• Не сам агент: server предоставляет возможности, но не планирует работу вместо агента и не принимает бизнес-решения.
• Не замена API: часто MCP server сам внутри обращается к обычному API, просто делает его удобным и discoverable для AI-клиента.
• Не гарантия безопасной записи: если открыть tool `create_issue`, это еще не значит, что агент должен создавать задачи без preview и подтверждения.
• Не процедура работы команды: MCP не решает, когда заводить Epic, как писать acceptance criteria, кого назначать assignee и что считать хорошим результатом.

Поэтому внедрение MCP сервера не завершает пилот AI-агента. Оно только открывает технический канал доступа. Дальше нужны границы, сценарии, роли, review и журналирование.

Чтобы не смешивать архитектурные слои, полезно разложить их по ролям.

Хорошая архитектура обычно выглядит так: сначала команда описывает повторяемую процедуру, затем решает, какие read/write-возможности ей нужны, и только после этого подключает MCP server или другой API-слой под эту процедуру.

В реальной работе MCP server почти всегда привязан к конкретному источнику или классу действий.

• GitHub, GitLab, Jira: найти задачу, прочитать MR, получить список issue, подготовить комментарий, проверить статус pipeline. Запись лучше открывать отдельно и только с preview.
• Figma и Playwright: взять дизайн-контекст, проверить страницу в браузере, собрать скриншот, выполнить smoke-проверку пользовательского сценария.
• Поиск, документы, Confluence: найти релевантные страницы, прочитать канон, собрать выдержки для draft, проверить, что ссылка ведет на живой источник.
• Файлы и репозитории: читать структуру проекта, искать по коду, открывать документы и выполнять ограниченные локальные операции в заданных корнях.

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

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

API, CLI + Skill или MCP

API задаёт контракт внешней системы. SDK или HTTP-клиент вызывает этот API из программы, CLI предоставляет команды, а MCP — стандартный интерфейс для совместимых AI-клиентов. Поэтому MCP часто работает поверх существующего API, а не заменяет его.

Число агентов само по себе не определяет выбор. Одному агенту может понадобиться MCP из-за доступного ему интерфейса; несколько агентов могут использовать общий SDK или CLI. MCP-сервер также может запускаться локальным процессом через stdio: отдельный сетевой сервис нужен не всегда. Различие локального и удалённого подключения описано в официальном обзоре архитектуры MCP ↗.

Как CLI и Skill используются внутри агента

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

Skill описывает процедуру: какие данные собрать, какой инструмент вызвать, как проверить результат и когда остановиться. Он может использовать CLI, прямой API или MCP. Инструкция не выдаёт доступ и не ограничивает технические полномочия сама по себе; различия разобраны в материале об AGENTS.md, SKILL.md и MCP.

Условный пример подключения

В условной системе API позволяет искать записи, читать их и сохранять черновики. Внутренний агент уже вызывает эти операции через зарегистрированный CLI-клиент, получает JSON и проверяет сохранённый результат. Пользователь работает с агентом в чате. Для этого сценария существующего клиента и Skill с процедурой может быть достаточно.

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

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

Главный риск MCP-подключения — не сам протокол, а слишком широкий доступ без понятной операционной рамки.

• Разделяйте read и write: чтение документации, задач и репозитория не должно автоматически давать право создавать issue, коммитить код или публиковать комментарии.
• Ограничивайте секреты: server не должен раскрывать токены модели, пользователю или публичному логированию; секреты остаются в управляемом контуре исполнения.
• Используйте sandbox: для локальных файлов, команд и браузера нужны разрешенные корни, понятные лимиты и запрет на неожиданные побочные действия.
• Ставьте approval before write: запись в backlog, MR, production-системы, внешние каналы и документы должна проходить через preview и явное подтверждение.
• Ведите аудит: важно понимать, какой tool был вызван, с какими параметрами, от чьего имени и какой результат вернул.

Чем ближе tool к изменению состояния проекта или раскрытию данных, тем меньше он должен быть “автоматическим”.

• Начинать с write tools: команда открывает `create_issue`, `post_comment` или `merge_request_update` раньше, чем договорилась о preview и критериях качества.
• Путать MCP server и бизнес-процедуру: server дает доступ, но не знает, как именно ваша команда ведет backlog, review, релизы и документацию.
• Давать агенту весь backlog или repo без границ: широкий read-доступ кажется удобным, но быстро превращается в шум, утечки контекста и неверные выводы.
• Считать “подключили MCP” завершенным пилотом: настоящий пилот заканчивается проверенными сценариями, guardrails, журналом действий и понятным решением, что автоматизировать дальше.

После базового определения посмотрите, какие MCP-интеграции можно подключать coding agent.

Если нужно не только чтение, а запись в Jira или GitLab, используйте отдельную процедуру: MCP для Jira и GitLab.