MCP Cline подключает к кодовому агенту внешние инструменты через описание сервера в конфигурации: Cline запускает локальный процесс либо обращается по адресу и получает список действий, которые модель вправе вызывать. Один сервер открывает агенту ровно те операции, которые заложены в его инструментах, поэтому ключи, одобрения и порядок отключения продумывают до первого вызова. Схема рассчитана на команду, где за каждым сервером закреплён ответственный человек.
Что получает агент
Cline читает конфигурацию MCP, поднимает каждый включённый сервер и показывает модели его инструменты; запуск и права настраиваются полями command, env, disabled и autoApprove.
Базовая работа Cline в репозитории — чтение файлов, правки и запуск команд — описана в отдельной статье про Cline. MCP добавляет другое: агент выходит за пределы папки проекта и обращается к трекеру задач, базе данных, документации или браузеру. Каждое такое обращение оформлено как инструмент сервера с названием, описанием и набором аргументов.
Соседний случай разобран в материале про OpenCode: там другой клиент и другой формат файла. У Cline своя конфигурация, свои флаги одобрения и свой интерфейс управления серверами, поэтому настройки между клиентами переносят заново, поле за полем. Общая механика протокола изложена в статье про MCP для бизнеса, а здесь речь о том, что делает именно Cline.
Выберите одну задачу, которой сервер действительно нужен: например, чтение карточек задач из трекера при подготовке правки. Сервер для всего подряд превращает агента в пользователя с широким доступом. Узкая задача сразу подсказывает, какие инструменты оставить, а какие скрыть от модели. Список инструментов читайте глазами: у каждого есть название, описание и аргументы, и по ним видно, умеет сервер только искать или ещё и записывать. Описание пишет автор сервера, поэтому сверяйте его с реальным поведением на тестовых данных.
Конфигурация сервера
По документации Cline, серверы описываются в JSON-конфигурации. В расширении для редактора её открывают из панели MCP Servers: вкладка Configure и кнопка Configure MCP Servers. В командной строке Cline файл лежит по пути ~/.cline/mcp.json, а управлять списком серверов помогает команда cline mcp: через неё можно просмотреть, добавить, изменить, включить, выключить и удалить запись. Сверяйте детали с обзором MCP в репозитории Cline, поскольку интерфейс меняется между версиями.
| Поле | Для чего нужно | Что проверить |
|---|---|---|
| command и args | Запуск локального сервера через STDIO | Источник пакета и закреплённая версия |
| url и headers | Подключение к удалённому серверу | Адрес принадлежит владельцу сервиса, заголовок с токеном берётся из секрета |
| env | Переменные окружения процесса, включая ключи | Значения лежат в менеджере секретов, а файл остаётся без паролей |
| disabled | Временное отключение без удаления записи | Лишние серверы выключены на время задачи |
| autoApprove | Список инструментов, которые идут без вопроса | Только чтение, никаких записывающих действий |
| type | Вид подключения | Значение streamableHttp для удалённых серверов, SSE как устаревший вариант |
Cline поддерживает локальный STDIO, потоковый HTTP для удалённых серверов и прежний SSE. Для нового подключения берите STDIO у локальных инструментов и Streamable HTTP у размещённых сервисов. Старый SSE оставляйте только тем серверам, которые пока предлагают лишь его. Если поле type опустить, Cline по документации выберет именно SSE, поэтому для рекомендованного транспорта впишите streamableHttp явно. Название сервера пишите по сути задачи, чтобы в журнале одобрений читалось, какое хранилище затронул вызов. Перед сохранением запустите команду сервера в терминале вручную: так ошибка пути, отсутствующий пакет или пустая переменная видны сразу, а в панели Cline вы получите уже работающую запись. Версию пакета закрепите в аргументах, иначе очередное обновление молча изменит набор инструментов.
Секреты и границы
Ключ для сервера выдайте отдельный и с минимальными правами в целевой системе. Документация Cline советует хранить чувствительные значения в переменных окружения и устанавливать только доверенные серверы. Добавьте к этому проверку на стороне самой системы: токен на чтение трекера запретит изменение задачи на стороне трекера, даже когда модель получит такую идею из текста чужого тикета.
- Создайте служебную учётную запись для агента с ролью только на чтение.
- Передайте токен через переменную окружения процесса, а файл конфигурации держите вне репозитория.
- Для записывающих инструментов оставьте ручное одобрение каждого вызова.
- Список autoApprove заполняйте по одному инструменту после пробного прогона.
- Фиксируйте, кто владеет сервером и кто отзывает ключ.
Параметр autoApprove экономит нажатия, но снимает человека с проверки конкретного вызова. Допускайте в него безопасные операции чтения: поиск, получение карточки, список файлов. Всё, что создаёт, изменяет или удаляет, пусть требует решения оператора. Ответы серверов бывают с вложенным текстом, в том числе с инструкциями для модели; считайте такой текст данными, а решение о действии оставляйте за правилами и человеком.
Пробный вызов
Проверку проводят на тестовых данных: отдельная папка, песочница трекера или копия базы. Реальную систему подключают после того, как вы увидели список инструментов и один осмысленный ответ.
- Добавьте сервер в конфигурацию с
disabledв значении истина и впишите ключ тестовой среды вenv. - Переведите
disabledв значение ложь и откройте панель серверов: сервер должен показать статус подключения и список инструментов без ошибок запуска. - Сравните список с ожидаемым. Лишние инструменты скройте на стороне сервера, если он это позволяет, либо смените сервер.
- Поставьте агенту узкую задачу на чтение: найти одну тестовую карточку и пересказать её. Вызов одобряйте вручную.
- Сверьте ответ агента с исходными данными в самой системе и посмотрите журнал, какой инструмент и с какими аргументами сработал.
Отсюда видна граница ответственности. Агент формулирует запрос и пересказывает ответ, сервер выполняет вызов с назначенными ему правами, а человек подтверждает то, что меняет данные. Расхождение между пересказом и исходной карточкой фиксируется как ошибка этапа, и автоматическое одобрение для этого инструмента остаётся выключенным. Повторите прогон на трёх-четырёх разных карточках, включая пустую и очень длинную: на таких краях видно, как сервер режет ответ и что приходит агенту при ошибке доступа.
Какие внешние системы вы бы открыли агенту первыми?
Отключение и ревизия
Подключённый сервер живёт дольше задачи, ради которой его включали. Раз в период просматривайте конфигурацию: какие записи нужны, у каких истёк срок ключа, кто назначен ответственным. Ненужный сервер переводите в disabled сразу после завершения задачи, а при подозрении на утечку отзывайте токен в самой системе и только потом чистите файл.
Если сервер завис, возвращает ошибки или присылает изменившийся список инструментов после обновления пакета, отключите запись и вернитесь к ручной работе. Обновление закрепляйте по версии и проверяйте тем же пробным вызовом. Права доступа и срок жизни токенов подробнее разобраны в статье про OAuth, токены и отзыв прав.
Для команды полезен короткий реестр: название сервера, назначение, владелец, тип токена, список разрешённых без вопроса инструментов и дата последней проверки. Реестр занимает страницу и отвечает на вопрос аудитора за минуту. Новичку в команде он же объясняет, почему у агента есть доступ к одним системам и нет доступа к другим, и кого просить о расширении прав. Если нужен проект с разбором систем, правами и приёмкой, расскажите о задаче на странице про ИИ-агентов для бизнеса.
Возьмите тестовый трекер и один сервер с правом чтения. Запишите в конфигурацию только command и env, а autoApprove оставьте пустым. Проведите пробный запрос, сверьте пересказ с карточкой и лишь затем решайте, какой инструмент отпустить без вопроса.