# Как меняется приоритет MCP-конфигурации в терминалах и IDE Конфликты конфигурации MCP связаны не с MCP, а с клиентом. Это различие помогает избежать долгой и бесполезной отладки. Протокол объясняет клиенту, как общаться с сервером после его запуска. Он не говорит Claude Code, VS Code, Cursor, GitHub Copilot CLI или расширению, какой JSON-файл читать первым, нужно ли объединять две записи с одинаковым именем и может ли плагин зарегистрировать сервер после загрузки файловой конфигурации. Если предположить существование единой иерархии, можно запустить не тот исполняемый файл, хотя имя инструмента будет выглядеть правильно. Такую ошибку легко не заметить. В списке инструментов есть `github`, агент вызывает `github.search_code`, и вызов проходит успешно. При этом терминальный агент мог запустить обёртку проекта для тестовой учётной записи, а IDE использовала глобальную команду для вашей личной учётной записи. Имя совпало, команда нет. Вот рабочее правило, которым я пользуюсь: разбирайте MCP-конфигурацию отдельно для каждого клиента, процесса и имени сервера. Считайте команду сервера, аргументы, окружение, рабочий каталог, URL транспорта и источник учётных данных единым определением запуска. Не пытайтесь вывести эти параметры из подписи, которую видите на панели агента. ## У MCP нет общей лестницы приоритетов MCP стандартизирует сообщения и возможности между клиентами и серверами. Он не задаёт переносимую структуру файлов или правило выбора при конфликте источников конфигурации. Клиент может использовать JSON-файлы, базу настроек, API плагина, корпоративную политику, флаг командной строки или всё сразу. Поэтому четыре выражения, которые часто считают взаимозаменяемыми, означают разное: - **Пользовательская конфигурация** это глобальное определение клиента для одной учётной записи или профиля. - **Проектная конфигурация** это определение, связанное с репозиторием или рабочей областью. - **Конфигурация плагина** это сервер, зарегистрированный или предоставленный установленным расширением либо плагином. - **Настройка редактора** это параметр самого редактора, который может управлять MCP-конфигурацией, а может и не управлять ею. Последнее различие создаёт больше проблем, чем должно. У VS Code есть зрелая иерархия обычных настроек: параметры рабочей области имеют приоритет над пользовательскими, а значения-объекты могут объединяться, тогда как простые значения и массивы заменяются. Это действительно относится к `settings.json`. Но это не доказывает, что `.vscode/mcp.json` использует те же правила объединения и разрешения конфликтов. VS Code описывает MCP-конфигурацию как отдельный файл `mcp.json` в рабочей области или профиле пользователя. Не переносите предположения из механизма настроек в другой формат конфигурации. Практический вывод простой: фраза «рабочая область имеет приоритет» ничего не объясняет, пока не указаны клиент, его версия, формат конфигурации и точный конфликт. Файл рабочей области может добавить сервер, скрыть одноимённый глобальный сервер, работать вместе с ним или не загрузиться из-за непроверенной рабочей области. Это разные результаты, а общая схема приоритетов их скрывает. ## Единица конфликта это имя сервера Большинство клиентов организуют MCP-конфигурацию как карту: слева имя сервера, справа одно определение запуска. Ключ карты часто используется клиентом, чтобы определить конфликт двух объявлений. Рассмотрим два файла: ```json // user configuration { "mcpServers": { "catalog": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"], "env": { "CATALOG_TARGET": "production" } } } } ``` ```json // project configuration { "mcpServers": { "catalog": { "command": "node", "args": ["./tools/catalog-fixture.js"], "env": { "CATALOG_TARGET": "fixture" } } } } ``` Человек видит два сервиса каталога. Клиент видит два значения по ключу `catalog`. Если он выбирает одно определение, обычно выбирается всё определение целиком. Не рассчитывайте, что клиент объединит глобальную команду с проектными аргументами или проектную команду с глобальным окружением. Некоторые системы настроек объединяют объекты, но MCP-клиент не обязан так делать. Поэтому частичные переопределения плохо подходят для такой задачи. Если проекту нужен другой endpoint, объявите полную нужную команду. Пользователю, которому нужен личный инструмент, стоит выбрать другое имя. Частичное переопределение не позволяет понять, заменил ли клиент весь объект сервера или объединил поля способом, который вы не проверяли. Пока вы разбираетесь с конфигурацией, используйте имена, которые показывают владельца и назначение: ```json { "mcpServers": { "catalog-user-live": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"] }, "catalog-repo-fixture": { "command": "node", "args": ["./tools/catalog-fixture.js"] } } } ``` Эти имена не назовёшь изящными. Зато они честно описывают ситуацию. Когда у команды появится одно каноническое определение, его можно переименовать в `catalog`. До этого короткое дублирующееся имя превращает каждый вызов инструмента в угадайку. Отделяйте одинаковое имя от одинаковой возможности. Два сервера могут предоставлять инструмент `search`, но оставаться разными, если их имена различаются. Агент может путаться из-за похожих описаний, однако это не обязательно конфликт имён в конфигурации клиента. Сначала разберитесь с выбором клиента, затем улучшайте описания и названия инструментов. ## В Claude Code порядок областей MCP определён явно Claude Code проще всего анализировать, потому что в документации указана последовательность для серверов с одинаковыми именами. Локальная область имеет приоритет над проектной, а проектная над пользовательской. Важно использовать актуальную терминологию: `local` это частная область конкретного проекта по умолчанию; `project` записывает общий `.mcp.json`; `user` действует во всех проектах. Раньше Anthropic использовала другие названия для некоторых областей, поэтому старые заметки и история команд могут вводить в заблуждение. Если `catalog` есть во всех трёх областях, Claude Code запускает локальное определение. Следующим идёт определение из общего `.mcp.json`, а пользовательское служит запасным вариантом. ```sh # private to this checkout and this user claude mcp add catalog --scope local -- node ./tools/catalog-fixture.js # shared with the repository claude mcp add catalog --scope project -- node ./tools/catalog-service.js # available in all repositories for this user claude mcp add catalog --scope user -- node ~/bin/catalog-personal.js ``` Ожидаемый результат проверки это один эффективный сервер с именем `catalog`, полученный из локальной области, если присутствуют все три определения. После каждого изменения запускайте команду клиента, которая показывает или получает сервер, вместо того чтобы доверять только что отредактированному файлу: ```sh claude mcp get catalog ``` В выводе должны быть указаны имя сервера и параметры настроенного транспорта или команды. Сравните фактические команду, аргументы и окружение с ожидаемым определением. Если команда не совпадает с отредактированной, перестаньте менять файлы и выясните, какая область всё ещё владеет этим именем. Не смешивайте правило областей MCP с общей иерархией настроек Claude Code. Anthropic отдельно описывает управляемую корпоративную политику, аргументы командной строки, локальные настройки проекта, общие настройки проекта и пользовательские настройки. Управляемый параметр может ограничивать поведение вокруг MCP, но не выступать вторым определением MCP-сервера. Эти две иерархии отвечают на разные вопросы. Есть ещё одна ловушка в проектной области. Claude Code запрашивает подтверждение перед использованием сервера из `.mcp.json`. Это подтверждение касается разрешения клиенту использовать сервер проекта. Оно не меняет приоритет одноимённых конфигураций. Не считайте окно подтверждения доказательством того, что победила общая команда. ## VS Code хранит MCP-файлы отдельно от обычных настроек VS Code документирует два места для конфигурации MCP-серверов: `.vscode/mcp.json` в рабочей области и пользовательский `mcp.json`, который открывается командой `MCP: Open User Configuration`. Файл рабочей области предназначен для публикации вместе с исходным кодом, а файл профиля следует за пользователем и может отличаться в разных профилях VS Code. Такая структура создаёт разумное ожидание: конфигурация репозитория описывает инструменты репозитория, а профиль описывает личные инструменты. Но сама по себе она не документирует полное правило разрешения одинаковых имён. В частности, справочник конфигурации MCP описывает схему и расположение файлов, но не говорит, что обычные правила приоритета VS Code применяются к записям `servers` по полям. Здесь опытные пользователи часто делают неверный вывод. Они знают, что настройки рабочей области VS Code имеют приоритет над пользовательскими, помещают одно имя MCP-сервера в конфигурацию профиля и рабочей области, меняют проектную команду и решают, что именно она будет запущена. Возможно, так и будет. Но вывод, основанный на соседней подсистеме настроек, остаётся выводом, а не документированным контрактом. Считайте конфликт одинаковых имён в VS Code поводом для теста. Сделайте два варианта заметно разными и используйте безопасную команду, которая покажет, какой вариант запустился: ```json { "servers": { "precedence-probe": { "type": "stdio", "command": "sh", "args": ["-lc", "printf 'workspace probe started\\n' >&2; exec node ./tools/probe-server.js"] } } } ``` В конфигурации профиля пользователя добавьте другую метку: ```json { "servers": { "precedence-probe": { "type": "stdio", "command": "sh", "args": ["-lc", "printf 'profile probe started\\n' >&2; exec node $HOME/bin/probe-server.js"] } } } ``` Затем полностью перезапустите сервер через интерфейс управления MCP в VS Code или перезапустите редактор, если интерфейс не показывает состояние процесса достаточно ясно. Проверьте вывод или журналы MCP-сервера и найдите метку. Не проводите такой тест на реальной базе данных или рабочем окружении. Проверка приоритета должна подтверждать путь запуска, а не изменять данные. То же относится к включению сервера. VS Code указывает, что состояние включения и отключения хранится отдельно от конфигурации сервера, поэтому общий файл может присутствовать, а сервер не запуститься в конкретной рабочей области. «Я вижу его в `mcp.json`» и «этот клиент его запустил» это разные факты. Многокорневые рабочие области создают ещё одну причину для ошибочной уверенности. В обычных настройках VS Code есть области рабочей области и отдельных папок, но файл MCP рабочей области не становится автоматически объявлением сервера для каждой папки. Если инструменту нужна команда относительно корня репозитория, явно укажите корень и ожидаемый рабочий каталог в тесте. Команда, работающая в одном корне, может завершиться ошибкой или незаметно обратиться к другому файлу, когда редактор открывает несколько папок. ## Cursor добавляет проектные, глобальные и расширенные способы регистрации Cursor документирует проектную MCP-конфигурацию в `.cursor/mcp.json` и глобальную в `~/.cursor/mcp.json`. Кроме того, API расширений позволяет программно регистрировать MCP-серверы. Это три разных источника: файл репозитория, пользовательский файл и код внутри расширения. С первыми двумя легко работать, если имена уникальны. Общий сервис разработки репозитория поместите в `.cursor/mcp.json`. Личную утилиту, например локальный сервис поиска заметок, поместите в глобальный файл. CLI Cursor сообщает, что обнаруживает и использует `mcp.json`, поэтому общая конфигурация полезна, когда IDE и её терминальный агент действительно работают в одном окружении. Сложный случай это одинаковое имя во всех трёх источниках. Публичная документация Cursor о MCP показывает, где находятся проектный и глобальный файлы, но не публикует полный контракт для каждого конфликта между глобальной конфигурацией, проектной конфигурацией и сервером расширения, зарегистрированным динамически. Не создавайте такое правило на основе сообщения на форуме, старой заметки о выпуске или поведения на одном компьютере. Безопасный вариант это не допускать конфликта. Если расширение предоставляет `issue-tracker`, не добавляйте вторую запись `issue-tracker` в `.cursor/mcp.json` в надежде, что команда репозитория её заменит. Дайте серверу репозитория другое имя, например `issue-tracker-fixture`, и ясно укажите в инструкциях агента или описаниях инструментов, когда его использовать. Это особенно важно для команд, которые используют плагин ради удобства, а файл ради воспроизводимости. Плагин может сам управлять установкой, OAuth, обновлениями или регистрацией. Файл репозитория виден при проверке изменений. Это разные модели владения. Сначала решите, кто владеет сервером, а потом пытайтесь согласовать конфигурации. Границы окружения делают конфликты Cursor страннее, чем они есть на самом деле. Настольная IDE может работать в одной операционной системе, а её терминал, удалённая рабочая область или контейнер разработки в другой. Глобальный файл в домашнем каталоге может существовать в одном окружении, но отсутствовать в другом. Команда из проектного файла может находить `node`, `python` или относительный исполняемый файл через другое значение `PATH`. До обсуждения приоритета запишите, где работает клиентский процесс и где работает процесс сервера. Для каждого варианта запишите небольшую карточку запуска: ```text client: Cursor desktop / Cursor CLI client environment: local macOS / WSL / remote host / container config source: ~/.cursor/mcp.json / .cursor/mcp.json / extension registration server name: issue-tracker command: node ./tools/issue-mcp.js working directory: repository root credential source: OAuth / local environment / external gateway ``` Такая пятиминутная запись полезнее целого дня переключения параметров в панелях. ## GitHub Copilot CLI документирует приоритет проектной MCP-конфигурации над пользовательской GitHub Copilot CLI описывает это точнее многих клиентов. В его документации сказано, что проектная MCP-конфигурация в `.mcp.json` или `.github/mcp.json` имеет приоритет над одноимённым определением в `~/.copilot/mcp-config.json`. Это ясное правило «проект выше пользователя» для имён MCP-серверов в CLI. Используйте его как правило конкретного клиента, а не как общую истину для GitHub Copilot в любом редакторе. У Copilot CLI есть собственный каталог конфигурации, настройки репозитория, локальные параметры, поддержка плагинов, хранилище разрешений и процесс командной строки. Сеанс Copilot в VS Code это другая клиентская поверхность со своей документацией о MCP и собственным жизненным циклом. Чистая конфигурация Copilot CLI может выглядеть так: ```json // ~/.copilot/mcp-config.json { "mcpServers": { "docs": { "command": "node", "args": ["/Users/dev/bin/company-docs-mcp.js"] }, "catalog": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"] } } } ``` ```json // .mcp.json in the repository { "mcpServers": { "catalog": { "command": "node", "args": ["./tools/catalog-fixture.js"] } } } ``` В этом репозитории Copilot CLI должен использовать проектное определение `catalog` и сохранить пользовательское определение `docs`, потому что проект не содержит конфликтующей записи `docs`. Полезная модель именно такая: переопределяйте только имя, которым владеет проект, а несвязанные личные инструменты оставляйте без изменений. Плагины усложняют картину, поскольку могут приносить собственное поведение агента и жизненный цикл MCP-сервера. В документации GitHub сказано, что плагины, включённые для репозитория, относятся к области репозитория, а клиент останавливает MCP-сервер плагина, когда репозиторий больше не включает этот плагин. Значит, сервер плагина связан с его активацией, а не просто скопирован в пользовательский MCP-файл. Если сервер плагина и сервер из файла используют одно имя, не угадывайте, какая команда победит. Проверьте видимое состояние серверов CLI, состояние плагина и вывод при запуске. Если документация установленной версии не описывает такое столкновение, переименуйте одно определение или удалите одного поставщика. Совет «просто переопредели сервер плагина в репозитории» кажется удобным, потому что он короткий. Но он ошибочен, если плагин регистрируется после загрузки файлов или хранит дополнительные данные жизненного цикла. ## Редактор и его терминал это разные MCP-клиенты Терминал внутри IDE кажется частью редактора. На самом деле это отдельный процесс оболочки. Когда вы запускаете `claude`, `copilot` или `cursor-agent`, команда может читать свои файлы, текущий каталог, окружение, домашний каталог и переменные переопределения конфигурации. Расширение чата редактора это другой процесс с другой реализацией клиента. Отсюда знакомая жалоба: «MCP-сервер работает в IDE, но не в терминале». Возможны вполне обычные причины: - Редактор открыл файл рабочей области, а терминал запустился во вложенном каталоге или соседней копии репозитория. - Редактор использует удалённый хост или контейнер, а команда в терминале работает локально. - Терминал получил особые значения `PATH`, `HOME`, прокси или переменной учётных данных из оболочки. - Редактор активировал сервер плагина, который CLI не загружает. - CLI нашёл проектный сервер с тем же именем и заменил пользовательскую запись. Не начинайте с копирования всех конфигурационных файлов во все возможные места. Так вы увеличите число потенциальных конфликтов и скроете первоначальную причину. Запускайте по одному клиенту и собирайте свидетельства. Для терминальных клиентов используйте встроенную команду, которая показывает или получает MCP-серверы. Для редакторов откройте представление управления MCP и его вывод или журналы. Записывайте имя сервера, команду, аргументы, расположение процесса и время запуска. Если терминал и редактор показывают одно имя, но разные команды, причина найдена: конфигурация разрешается по-разному. Если команда одинаковая, а поведение различается, проверяйте рабочий каталог, учётные данные, сетевой доступ и сам сервер. Полезный тест это временно заменить команду нужного сервера обёрткой, которая перед запуском настоящего сервера записывает однозначную метку в стандартный поток ошибок. Обёртка должна быть безопасной и после теста её нужно удалить. ```sh #!/bin/sh printf '%s client=%s cwd=%s\n' \\ "MCP probe started" \\ "${MCP_CLIENT_LABEL:-unknown}" \\ "$PWD" >&2 exec node "$(dirname "$0")/real-server.js" ``` Не выводите токены, заголовки, значения учётных данных, полное окружение или тела запросов. Журналы часто сохраняются дольше терминального сеанса, и проверка приоритета не должна создавать утечку секретов. ## Регистрация плагина это не переопределение из конфигурационного файла Плагин это поставщик конфигурации сервера, а не просто ещё одна папка с JSON-файлом. Он может зарегистрировать сервер динамически, управлять аутентификацией, выбрать версию, реагировать на изменения рабочей области или остановить сервер при деактивации. Из-за этого небезопасны два популярных совета. Первый: «добавь то же имя в файл проекта, чтобы переопределить плагин». Это работает только тогда, когда клиент документирует загрузку файлов после плагинов и замену регистрации плагина при конфликте одинаковых имён. Без такого контракта дубликат может вызвать ошибку, скрытую замену, появление двух похожих инструментов или изменение поведения после обновления. Второй: «отключи сервер в интерфейсе, и проект чист». Состояние включения может храниться вне общего файла. VS Code прямо отделяет состояние включения и отключения от MCP-конфигурации. Коллега может клонировать репозиторий, получить тот же файл и при этом иметь другой набор активных серверов. Вместо этого используйте один из вариантов владения: 1. **Сервером владеет файл:** репозиторий фиксирует определение сервера. Все используют этот файл, а плагин не регистрирует тот же сервис. 2. **Сервером владеет плагин:** плагин управляет регистрацией и аутентификацией. Репозиторий не объявляет дубликат. 3. **Роли серверов разделены:** плагин владеет `tracker-live`, а файл проекта владеет `tracker-fixture`. Имена, описания и разрешения явно различают цели. Третий вариант не самый эффектный, зато часто самый безопасный. Командам нередко нужны одновременно личный рабочий сервис и тестовый сервис репозитория. Если считать их одним сервером лишь потому, что оба работают с трекером задач, вероятность случайного вызова рабочего окружения возрастает. ## Повторяемый способ доказать, какая команда победила Разрешение конфигурации можно проверить независимо от поведения агента. Описанный ниже метод использует безопасный stdio-сервер или обёртку и подходит как для локальной команды, так и для удалённого сервиса. ### Создайте пробу из двух источников Выберите одно имя сервера, например `precedence-probe`. Определите его ровно в двух источниках, которые хотите сравнить. Пусть каждый вариант перед запуском одного и того же безопасного тестового сервера выводит свою метку. Для сервера на основе команды различайте все важные части: ```json { "mcpServers": { "precedence-probe": { "command": "sh", "args": ["-lc", "printf 'SOURCE=PROJECT CWD=%s\\n' \\\"$PWD\\\" >&2; exec node ./tools/probe.js"], "env": { "MCP_PROBE_SOURCE": "project" } } } } ``` Пользовательский вариант должен выводить `SOURCE=USER` и указывать на другой известный файл. Не полагайтесь только на переменную окружения: клиент может скрыть её, отфильтровать или запустить старый процесс. Добавьте заметную метку в путь команды и её вывод. ### Перезапустите сервер, а не только чат MCP-серверы часто работают как долгоживущие дочерние процессы. Редактирование JSON, пока сервер продолжает работу, ничего не доказывает о следующем запросе. Используйте управление клиента, которое останавливает и запускает сервер заново. Если оно непонятно, полностью закройте соответствующий клиент и снова откройте рабочую область. Сначала проверьте журналы на стороне клиента. Ожидаемое свидетельство выглядит так: ```text MCP probe started SOURCE=PROJECT CWD=/path/to/repository ``` Если метки нет, клиент мог отклонить конфигурацию до запуска процесса, использовать удалённый транспорт или оставить старый сервер работающим. Это тоже полезный результат. Теперь вопрос звучит не как «какая конфигурация победила?», а как «загрузилась ли эта конфигурация и запустил ли клиент процесс?» ### Меняйте только одну границу за раз Запустите пробу в терминальном клиенте, затем в клиенте IDE. Меняйте текущий рабочий каталог только после получения базового результата. Отключайте плагин лишь после проверки поведения без него. Сначала проверьте пользовательский и проектный источники, а уже затем добавляйте локальные переопределения или управляемые настройки. Храните небольшую таблицу результатов в задаче репозитория или командных заметках: | Клиент | Окружение | Источники вариантов | Наблюдаемая метка | Фактическая команда | | --- | --- | --- | --- | --- | | Claude Code | локальная оболочка | local, project, user | LOCAL | `node ./tools/probe-local.js` | | VS Code | контейнер разработки | workspace, profile | WORKSPACE | `node ./tools/probe-workspace.js` | | Cursor | настольная система | project, global, extension | extension marker | plugin-managed | Таблица должна описывать наблюдаемое поведение, а не ожидаемое. На наблюдаемых результатах команда может принимать решения. Схема, скопированная из описания другого клиента, всего лишь гипотеза. ## Держите учётные данные вне спора о приоритетах Конфликт команд это проблема выполнения. Конфликт учётных данных это проблема безопасности. Не решайте первую проблему, распространяя секреты по проектной, плагинной, пользовательской и редакторской конфигурации, пока что-нибудь не заработает. В проектной конфигурации, которая хранится в репозитории, обычно должны быть команда сервера, безопасные сведения об endpoint и инструкции по получению учётных данных. Там не должно быть долгоживущего bearer-токена в `env`, пути к закрытому SSH-ключу, которого нет у коллег, или пользовательского заголовка, дающего доступ к рабочему окружению. Проектный файл становится приглашением к выполнению для каждого клона и каждого агента, которому клиент разрешит его использовать. Если серверу нужен секрет, выберите границу учётных данных под задачу: - OAuth подходит, когда сервер и клиент его поддерживают, а пользователь должен выдать доступ интерактивно. - Локальный менеджер секретов или внедрение через окружение подходят для личного определения сервера. - Тестовый сервер репозитория должен использовать нерабочие учётные данные с узкими разрешениями. - Шлюз действий подходит, когда агенту нужно запросить действие, но он не должен получать исходные API- или SSH-учётные данные. Именно поэтому команда сервера может выглядеть безобидно и всё равно быть опасной. `npx some-mcp-server` может разрешиться в разные установленные версии на разных машинах. `node ./tools/server.js` может унаследовать `AWS_PROFILE`, `GH_TOKEN` или корпоративный прокси от родительского процесса. Объявление проекта можно проверить, но фактический источник учётных данных при этом останется невидимым. Когда агентам нужен доступ по HTTP или SSH, Sallyport может хранить API- или SSH-учётные данные в зашифрованном хранилище, а агент подключается через shim `sp mcp` и получает только результаты действий. Это не определяет, какая конфигурация клиента победит, но не позволяет выбранной команде одновременно передать агенту необработанные секреты. Не считайте приоритет конфигурации системой разрешений. Проектное определение может выбрать команду, но не доказывает, что этой команде можно действовать без проверки. Одобрение, хранение учётных данных и аудиторские свидетельства должны оставаться отдельными средствами контроля. ## Сделайте каноническую команду очевидной Команде нужен простой ответ на вопрос: какую команду должен запустить агент этого репозитория для данного сервиса? Если ответ спрятан среди пользовательских файлов, поведения плагина, фрагментов README и настроек редактора, конфигурация уже слишком расплывчата. Запишите каноническое общее определение в одном месте. Дайте ему стабильное имя сервера. Укажите, какие клиенты его поддерживают и какой источник им владеет. Личные варианты назовите иначе. Если сервисом должен владеть плагин, зафиксируйте плагин как канонический источник и не добавляйте конкурирующее определение в файл. Затем оставьте в репозитории небольшую команду проверки или пробу. Изменения конфигурации заслуживают тестов так же, как и сценарии развёртывания. Сервер, который запускает не ту команду, может прочитать не те файлы, обратиться не к тому endpoint или унаследовать не те учётные данные ещё до того, как агент что-либо скажет. Полезный результат это не универсальная таблица приоритетов. Нужно, чтобы у каждого клиента был один наблюдаемый путь запуска, у каждого имени сервера один владелец, а никому не приходилось угадывать, какую команду выполнит агент.