MCP подключает агента к рабочим системам, и он читает факты из источника, а не из пересказа. Это легко и быстро: достаточно понять, какую проблему он решает, и поручить подключение самому агенту. Ниже: суть, подключение, что это даёт и какие права выдавать. Пример QA с MCP разобран в статье QA с агентом через MCP.
Что такое MCP
MCP — один общий разъём, как USB. Подключил агента к Jira или GitLab, и он сам берёт оттуда данные. Подробнее
На картинке два пути данных. В первом человек пересказывает задачу агенту, и детали теряются по дороге. Во втором агент читает саму систему через MCP и видит всё, что видит человек. MCP (Model Context Protocol) — открытый стандарт, который связывает ИИ-приложения с внешними системами. У агента есть MCP-клиент, у системы MCP-сервер, и сервер сообщает агенту, какие данные и действия доступны.
Наш контекст и чужие
Наш контекст: всё, что агент видит сразу (диалог с агентом, файлы проекта). Другие контексты: всё остальное (GitLab, Jira, записи встреч, база знаний). Мост между ними — MCP: у агента MCP-клиент, у системы MCP-сервер.
На картинке слева контекст агента: диалог с ним и файлы проекта, которые он видит сразу. Справа другие системы: GitLab, Jira, tldv с записями встреч, Confluence с базой знаний. Пока MCP не подключён, агент их не видит. Мост между ними состоит из двух частей: MCP-клиент у агента и MCP-сервер у системы.
Что такое контекст
Контекст — всё, что модель видит в данный момент. Чего нет в контексте, того агент не знает.
Контекст можно представить как стол, на котором лежит всё, что модель видит прямо сейчас: сообщения диалога, открытые файлы, результаты вызовов. Чего на столе нет, того для модели не существует, пока это туда не положили. Поэтому главный вопрос при работе с агентом: что у него на столе.
| Где лежит факт | Агент видит | Что будет |
|---|---|---|
| Наш контекст: диалог, файлы проекта | сразу | ответ из данных |
| Чужой контекст: GitLab, Jira, записи встреч | через MCP | агент сам забирает нужное |
| Нигде: в головах, в закрытой системе | нет | догадка вместо факта |
Таблица показывает, что будет с фактом в зависимости от того, где он лежит. Факт в контексте агента (диалог, файлы проекта): агент отвечает по данным. Факт в другой системе (GitLab, Jira, записи встреч): агент заберёт его сам, но только через MCP. Факт нигде не записан (в головах людей, в закрытой системе): агент его не увидит и заменит догадкой. Отсюда практическое правило: записывайте решения туда, откуда агент может их взять.
Как агент забирает чужой контекст: ReAct
Агент работает по циклу ReAct: рассуждает, действует, читает результат и снова рассуждает. MCP — это шаг «действует»: результат вызова попадает в наш контекст.
Пример цикла: агент рассуждает («нужны шаги бага PAY-142»), действует (вызывает MCP-сервер Jira), читает ответ (он попадает в контекст) и отвечает по данным. Три карточки показывают, что бывает, если цикл нарушен. Одни рассуждения дают выдуманный ответ, одни действия дают лишние вызовы и расход токенов, а чередование даёт ответ точно по данным.
Обоснование: у каждой части ответа есть опора
Ответ обоснован, когда каждая его часть получена из контекста. Такое соответствие без пустых мест называется эпиморфизмом.
| Часть ответа | Опора |
|---|---|
| Шаги воспроизведения | Jira, заявка PAY-142 |
| Где падает код | GitLab, файл и строка |
| Почему так решили | tldv, запись встречи |
Таблица показывает проверку обоснованности на примере. Шаги воспроизведения берутся из заявки в Jira, место падения кода из GitLab, причина решения из записи встречи. Если у части ответа такой опоры нет, её перепроверяют вручную.
Галлюцинация: часть без опоры
Галлюцинация — уверенная догадка на месте, где опоры нет. Выглядит так же гладко, как ответ из данных. Подробно и с советами Anthropic — в разделе про галлюцинации ниже.
Галлюцинация выглядит так же гладко, как ответ из данных, поэтому по тону их не различить. Отличает их только опора: она есть или её нет.
Почему именно эти
Без него: Агент додумывает код по другим контекстам и часто ошибается, так появляются галлюцинации; человек вручную копирует файлы и изменения в диалогОфициальный MCPПодробнее
Без него: Копировать приходится много, а история изменений пропадаетОфициальный MCP AtlassianПодробнее
Без него: Пропадает привычная всем разработчикам визуализация и отображение требований. Агента важно ограничивать и не отпускать далеко в сторону: старые требования могут устареть. Фактическую картину заставляйте смотреть в GitLabТот же MCP AtlassianПодробнее
Без него: Решения остаются в головах, а митинг-ноутсы и требования пишутся по памяти спустя часы и с ошибкамиЗапись и открытый APIПодробнее
Без него: То же, что без tldv: решения со встреч теряютсяMCPПодробнее
Эти системы выбраны потому, что в них лежат четыре вида фактов: код, задачи, правила и решения со встреч. В каждой строке указано, что пропадёт без подключения. Для Confluence есть оговорка: его подключают, только если страницы вылизаны (есть владелец и дата проверки), а фактическую картину агент сверяет с кодом в GitLab. Ещё надёжнее хранить требования и спеки в Git: там у правок есть автор, дата и причина.
Как подключить Jira
Агент и его оболочка (харнесс) умеют подключаться сами. Инструкции: Atlassian и Claude Code.
Картинка сравнивает два способа. Руками: вы ищете инструкцию, вводите команды, входите в систему и проверяете результат. Поручить агенту: вы говорите одну фразу, агент подключает Jira сам, а вам остаётся только войти через браузер.
Скажите агенту
Подключи MCP-сервер Jira по инструкции Atlassian и проверь на задаче PAY-142: прочитай её и перескажи комментарии.
Команды агент запустит сам. От вас нужен только вход через браузер (OAuth): пароль агенту не передаётся. Если агент просит сделать это вас.
Что произойдёт
- 1Агент подключит Jiraодной командой, вы ничего не вводите
- 2Откроется страница Jira — главный шагтам вам предложат дать агенту доступ к Jira; вы входите и подтверждаете, пароль агент не видит
- 3Агент прочитает PAY-142откроет задачу с комментариями и перескажет их
Главный шаг здесь второй: доступ выдаёте вы сами, входом через браузер. Агент не видит ваш пароль и получает только те права, которые вы подтвердили на странице Jira. Первый и третий шаги агент делает сам.
Только чтение. Выбрать доступ только на чтение на этой странице получится не всегда. Это безопасно: агент склонен читать и почти ничего не пишет, пока вы сами не попросите.
Как это делается руками
claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp
/mcp # войти через браузер (OAuth)
claude mcp list # статус: подключён / нужен вход / ошибкаГде хранится настройка и кто видит сервер: Области MCP в Claude Code.
Руками это три команды: добавить сервер, войти через браузер командой /mcp и проверить статус. Статус бывает трёх видов: подключён, нужен вход или ошибка. Схема выше показывает, как это выглядит по шагам, а ниже в областях сказано, где хранится настройка.
Экономия
Экономия приходит от точности. Неточный запрос даёт неточный ответ, правка порождает новый запрос, и ошибки накапливаются от шага к шагу; при ручном копировании и пересказе человек вносит такие неточности незаметно. Агент берёт данные прямо из источника, поэтому цепочка короче и ошибок меньше. Платой становится рост расхода токенов на дистанции, и для него есть ограничители.
Слева путь с ручным копированием: каждый шаг добавляет неточность, и к третьему заходу ошибки накопились. Справа путь из источника: один точный запрос и один ответ, без цепочки пересказов.
Ограничители расхода
Ответ подключённой системы попадает в диалог и занимает там место, а место измеряется в токенах. Поэтому Claude Code следит за размером ответа и ставит два порога.
Шкала показывает размер ответа системы в токенах. До 10 000 токенов ответ проходит без замечаний. После 10 000 Claude Code предупреждает, что ответ большой. После 25 000 ответ не попадает в диалог целиком и сохраняется в файл.
Порог 25 000 можно поднять настройкой окружения MAX_MCP_OUTPUT_TOKENS, а порог предупреждения фиксирован.
Меньше галлюцинаций
Галлюцинация: модель выдаёт текст, который выглядит верно, но неверен или не следует из данных. Ведёт она себя одинаково уверенно в двух случаях. Подробнее
Ответ агента сопоставляется с данными: у каждой его части должна быть опора. В математике такое соответствие называется эпиморфизмом. Части без опоры модель заполняет догадкой, и они выглядят так же уверенно.
Что это значит на практике. Если системы не подключены, агент заполняет недостающее догадкой и пишет её тем же уверенным тоном: по тексту догадку от факта не отличить. Если системы подключены, на месте догадки стоят реальные данные со ссылкой, и проверка занимает один клик. Три совета Anthropic работают вместе: разрешить агенту сказать «не знаю», когда данных нет, просить опираться на дословный текст источника и требовать к каждому утверждению ссылку.
Что рекомендует Anthropic
Три совета Anthropic закрывают дырки в данных. Разрешить «не знаю»: иначе модель заполнит пробел догадкой. Опираться на цитату: дословный текст источника можно проверить. Давать ссылку к каждому утверждению: её можно открыть и сверить.
Риски и правила
В большинстве случаев защита уже встроена в устройство MCP в Claude Code. Остаётся выбрать доверенные серверы и не выдавать лишних прав. Подробнее
Стоит помнить о трёх рисках. Лишние права: сервер, которому выдали запись, может изменить или удалить данные, поэтому права выдают по минимуму. Недоверенный сервер: MCP-сервер сторонних авторов получает доступ к тому, что вы ему открыли, поэтому подключайте проверенные. Текст из систем: задача или комментарий могут содержать фразу, адресованную агенту, об этом подробно в статье про data plane и control plane.
Лестница на картинке показывает порядок выдачи прав. Сначала чтение: агент только смотрит. Потом запись с подтверждением: агент предлагает, а человек одобряет каждую запись. Запись без подтверждения откладывается, пока доверие не накоплено. Поднимайтесь на одну ступень, только когда убедились, что предыдущая работает.
С чего начать
Начинать лучше с малого: один источник, один человек, который проверяет, и режим только чтения. Подключите Jira, задайте агенту пять вопросов про реальные задачи и сверьте ответы с тем, что видите сами. Так вы поймёте, насколько агенту можно доверять, до того как давать ему права на запись.
Другие кейсы
Один подход работает в разных задачах: агент читает источники, человек проверяет результат.
| Кейс | Источники | Что делает агент | Что проверяет человек |
|---|---|---|---|
| QA | Jira, стенд, браузер | воспроизводит баг, сжимает путь, пишет отчёт | шаги руками на стенде |
| Отчёты и аналитика | база, таблицы, документы | считает запросами, собирает сводку | одно число другим способом |
| Инциденты | Sentry, Grafana | сопоставляет ошибки, метрики и время релиза | гипотезу по графикам и событиям |
Как читать таблицу. В каждой строке порядок один: агент читает источники, делает основную работу и приносит результат, а человек проверяет его одним коротким действием. В QA шаги отчёта повторяют руками на стенде. В аналитике одно число пересчитывают другим способом. В инцидентах гипотезу сверяют с графиками и событиями. Подробности в статьях по ссылкам.