Azure Resource Manager MCP: как не сломать авторизацию и вызов тулов в VS Code — VogueTech

Что нового

Azure Resource Manager MCP‑сервер — это расширение для VS Code, которое даёт ИИ‑клиентам доступ к ресурсам Azure через стандартный MCP‑протокол. Новый материал от команды Azure — это не релиз фич, а подробный гайд по типовым проблемам:

типовые ошибки авторизации для личных и организационных аккаунтов (включая AADSTS500200);
особенности работы с гостевыми пользователями в Azure AD (tenant, приглашения, права Write на подписку);
влияние Conditional Access на вход и запуск тулов;
непредсказуемый порядок вызова тулов разными LLM‑клиентами;
практические рекомендации по системным промптам: как заставить ИИ всегда валидировать запросы к Azure Resource Graph до выполнения.

Это не «магический фикс», а набор конкретных шагов, который экономит время, когда MCP‑сервер в VS Code внезапно перестаёт работать так, как вы ждёте.

Как это работает

Под капотом Azure Resource Manager MCP‑сервер делает две вещи:

Интегрируется с VS Code и MCP‑клиентом.
Сервер регистрируется как провайдер тулов: LLM‑клиент в VS Code вызывает его, когда нужно:
- сгенерировать запрос к Azure Resource Graph (generate_query);
- провалидировать запрос (validate_query);
- выполнить запрос (execute_query).
Опирается на стандартную авторизацию Azure AD.
MCP‑сервер использует тот же механизм входа, что и остальные инструменты Azure в VS Code:
- личные и организационные аккаунты Azure AD;
- гостевые пользователи в чужих тенантах;
- политики Conditional Access и Security Defaults.

Из‑за этого у вас могут появляться типовые сценарии:

Личный аккаунт без прав на нужный tenant ловит ошибку AADSTS500200.
Гостевой пользователь видит tenant, но не может писать в нужную подписку из‑за отсутствия прав Write.
Tenant с включённым Conditional Access блокирует отдельные флоу входа или запуска тулов, и MCP‑сервер начинает падать с неочевидными ошибками.

Плюс к этому разные LLM‑клиенты (например, разные расширения или IDE) по‑своему решают, в каком порядке вызывать инструменты MCP. Один клиент сначала генерирует и валидирует запрос, другой может сразу попытаться выполнить его, пропустив валидацию.

Что это значит для вас

Если вы используете Azure Resource Manager MCP‑сервер в VS Code, гайд даёт понятные практические шаги.

Когда всё ломается ещё до дебага

Сначала сделайте быстрые проверки:

MCP‑сервер Azure Resource Manager установлен и включён в VS Code.
Вы вошли в VS Code под аккаунтом, у которого реально есть доступ к нужному tenant и подпискам.
В конфигурации MCP‑сервера включены все нужные вам инструменты.

Эти три пункта закрывают часть «глупых» проблем, когда дело не в Azure, а в настройках среды.

Если вы заходите личным аккаунтом

Частый кейс: вы логинитесь личным аккаунтом и получаете ошибку AADSTS500200. Что можно сделать:

Переключиться на организационный аккаунт.
Это самый простой и надёжный вариант, если у вас уже есть рабочий аккаунт с доступом к нужному tenant.
Если организационного аккаунта нет — сделать личный гостевым:
- пригласите свой личный аккаунт как гостевого пользователя в нужный tenant;
- примите приглашение на почте;
- убедитесь, что этому гостевому аккаунту выдали права Write на нужную подписку;
- при входе в Azure выберите «Sign in Options» → «Sign in to an organization»;
- введите домен вашей организации;
- выберите add a new account;
- войдите под почтой гостевого аккаунта.

Организационные аккаунты и корректно настроенные гостевые дают более предсказуемое поведение авторизации между tenant‑ами и корпоративными политиками. Если у вас есть выбор — используйте их.

Если у вас включён Conditional Access

Когда в tenant включён Conditional Access и отключены Security Defaults, вы можете столкнуться с неожиданными ошибками авторизации:

вход через MCP‑сервер ломается, хотя тот же аккаунт нормально работает в портале Azure;
отдельные флоу запуска тулов блокируются политикой, и вы видите странные ошибки при вызове инструментов.

В этом случае разработчики MCP‑сервера просят не гадать, а открыть issue в GitHub‑репозитории Azure Resource Manager MCP, описав проблему.

Когда ИИ вызывает инструменты в странном порядке

Разные LLM‑клиенты по‑разному принимают решения о вызове тулов. Это не баг MCP‑сервера, а поведение моделей:

один клиент всегда сначала валидирует запросы к Azure Resource Graph;
другой может сгенерировать запрос и сразу выполнить его, пропустив валидацию;
третий может вообще не вызвать нужный тул, если промпт не даёт ему явной инструкции.

Чтобы снизить хаос:

Жёстко задать порядок вызова тулов в системном промпте.
Для работы с Azure Resource Graph команда рекомендует такой сценарий:
- всегда сначала вызывать generate_query;
- потом обязательно вызывать validate_query;
- только если валидация прошла успешно — вызывать execute_query.
Зашить это правило в конфигурацию клиента.
Например, в системном промпте или политике клиента явно прописать:

"Always validate generated Azure Resource Graph queries before executing them. Use generate_query, then validate_query, and execute only if validation succeeds."

Это уменьшает количество неожиданных вызовов и помогает ловить ошибки ещё на этапе генерации, а не после выполнения некорректного запроса в проде.

Когда пора эскалировать проблему

Если вы прошли все шаги выше, а MCP‑сервер продолжает вести себя странно, команда просит собрать минимальный набор данных и открыть issue в GitHub‑репозитории:

Соберите:

последовательность вызовов тулов, которую использовал клиент;
текст ошибок, traceID и временные метки;
контекст tenant/subscription (без секретов и токенов);
тип аккаунта: личный, гостевой или организационный.

Это помогает быстро воспроизвести проблему и не тратить время на уточняющие вопросы.

Кому это вообще нужно

Azure Resource Manager MCP‑сервер полезен, если вы:

автоматизируете работу с ресурсами Azure через ИИ‑ассистента в VS Code;
строите свои MCP‑клиенты и хотите, чтобы LLM‑модели безопасно ходили в Azure Resource Graph;
работаете в корпоративной среде с жёстким Conditional Access и гостевыми пользователями.

Если вы не используете Azure и не планируете подключать ИИ к управлению облаком, этот гайд вряд ли пригодится. Если же вы завязаны на Azure и VS Code, материал экономит часы отладки странных ошибок авторизации и поведения тулов.

Для России есть важный нюанс: доступ к Azure и авторизации в tenant‑ах часто требует обходных путей и VPN. Если у вас нет стабильного доступа к облаку Microsoft, MCP‑сервер и описанные сценарии работать не будут.

Место на рынке

Azure Resource Manager MCP‑сервер живёт в довольно узкой нише: это не конкурент GPT‑4o или Claude 3, а инфраструктурный слой между LLM‑клиентом и Azure.

По сути, он конкурирует не с моделями, а с альтернативными способами подключить ИИ к облаку:

самописные REST‑обёртки над Azure Resource Manager и Azure Resource Graph;
прямую работу через Azure CLI или PowerShell‑скрипты без MCP;
другие MCP‑серверы, которые дают ИИ доступ к облачным ресурсам, но не к Azure.

Чётких цифр по скорости работы, стоимости запросов или сравнению с другими подходами команда не приводит. Основной плюс здесь — стандартный MCP‑протокол и глубокая интеграция с экосистемой Azure и VS Code.

Минус — зависимость от Azure AD, политик Conditional Access и корпоративных настроек безопасности. Если у вас сложная структура tenant‑ов и гостевых пользователей, без описанного в гайде чек‑листа и грамотных системных промптов MCP‑сервер легко превращается в источник загадочных ошибок.

Как запустить и отлаживать

Команда Azure даёт базовый сценарий, с которого стоит начать при проблемах:

Убедитесь, что Azure Resource Manager MCP‑сервер установлен и включён в VS Code.
Войдите под организационным аккаунтом с доступом к нужному tenant и подпискам.
Проверьте, что в конфигурации MCP включены нужные инструменты.

В системном промпте клиента пропишите политику вызова тулов, например:

Always validate generated Azure Resource Graph queries before executing them. Use generate_query, then validate_query, and execute only if validation succeeds.

Если используете личный аккаунт:
- пригласите его как гостя в нужный tenant;
- примите приглашение;
- выдайте права Write на нужную подписку;
- при входе используйте путь Sign in Options → Sign in to an organization → add a new account и зайдите под гостевым email.
При странных ошибках авторизации на tenant‑е с Conditional Access — соберите traceID, таймстемпы, тип аккаунта и последовательность вызовов тулов и создайте issue в GitHub‑репозитории MCP‑сервера.

Этот сценарий покрывает большинство проблем, с которыми сталкиваются команды, подключающие ИИ‑ассистентов к управлению ресурсами Azure через MCP.