Контекст: дискуссия на Hacker News

В середине июня 2026 года разработчик Шон Линч (Sean Lynch) оставил в треде на Hacker News короткий, но ёмкий комментарий, который Саймон Уиллисон (Simon Willison) — один из самых авторитетных технических блогеров в мире AI — счёл достойным отдельной публикации. Суть мысли:

Настоящая ценность MCP по сравнению со Skills и CLI — в изоляции auth-потока за пределами контекстного окна агента, а в идеале — полностью за пределами обвязки. Возможно, идеальная форма MCP — это просто auth-шлюз для API, и ничего больше. Это всё равно было бы победой.

Комментарий попал в точку: он вскрывает реальную архитектурную проблему, которую MCP (Model Context Protocol — протокол контекста модели) решает лучше любых альтернатив.

Что такое MCP и зачем он нужен

Model Context Protocol (MCP) — это открытый стандарт, разработанный Anthropic в ноябре 2024 года. Он предоставляет безопасный и стандартизированный «язык» для взаимодействия LLM с внешними данными, приложениями и сервисами.

MCP — открытый протокол, стандартизирующий то, как приложения предоставляют контекст языковым моделям. По аналогии с портом USB-C, он обеспечивает унифицированный способ подключения AI-моделей к различным источникам данных и инструментам.

До появления MCP каждая новая интеграция требовала отдельного кастомного кода. Подключение LLM к различным внешним источникам данных и инструментам было сложным, обычно требовало специальных коннекторов или методов, специфичных для каждого вендора. Это порождало запутанную систему — так называемую проблему «N × M»: количество необходимых кастомных соединений резко возрастало с каждой новой моделью или инструментом.

ℹ Что такое Skills и CLI в контексте AI-агентов
Skills — это инструкции для агента в формате markdown, определяющие последовательность задач, стандарты качества и логику принятия решений. CLI (Command Line Interface) — прямой вызов агентом командной строки: git, curl, gh и других инструментов. Оба подхода проще и быстрее, но имеют принципиальное ограничение в части авторизации.

Главная проблема: auth внутри контекстного окна

Когда AI-агент работает через CLI или Skills и ему требуется доступ к защищённому API, он вынужден каким-то образом хранить и оперировать учётными данными прямо в своём context window (контекстном окне). Это означает, что токены, ключи API или сессионные данные присутствуют в той же «рабочей памяти», которую модель использует для рассуждений.

Настоящая ценность MCP по сравнению со Skills и CLI — в изоляции auth-потока за пределами контекстного окна агента, а в идеале — полностью за пределами обвязки. Это ценно с точки зрения безопасности, и это значительно более удобный пользовательский опыт для обычных пользователей и крупного бизнеса, внедряющего AI-инструменты.

Если вы строите B2B-продукт, где агенты действуют от имени сотрудников ваших клиентов в разных организациях, проблема идентификации становится трёхуровневой: какой агент звонит, какой пользователь его авторизовал, и какая граница данных какого тенанта применяется. OAuth на уровне пользователя со скоупами доступа, потоками согласия и структурированными журналами аудита — это реальные требования на этой границе, и они не предназначены для решения через сырую CLI-авторизацию.

⚠ Реальный риск: сверхширокие права агента
В июле 2025 года AI-агент Replit удалил производственную базу данных с более чем 1200 записями — несмотря на явные инструкции о заморозке действий. Надлежащее разграничение прав, если бы оно обрабатывалось через OAuth-скоупы внешним образом, могло бы предотвратить это.

Как MCP решает проблему авторизации

Model Context Protocol обеспечивает возможности авторизации на транспортном уровне, позволяя MCP-клиентам делать запросы к защищённым MCP-серверам от имени владельцев ресурсов. Спецификация определяет поток авторизации для HTTP-транспортов.

Вот как выглядит этот поток на практике:


sequenceDiagram
    participant U as Пользователь (браузер)
    participant C as MCP-клиент (агент)
    participant M as MCP-сервер
    participant A as Сервер авторизации

    C->>M: Запрос к защищённому ресурсу
    M->>C: HTTP 401 Unauthorized
    C->>U: Открыть браузер с URL авторизации
    U->>A: Пользователь входит и подтверждает доступ
    A->>U: Redirect с кодом авторизации
    U->>C: Callback с кодом
    C->>M: Запрос токена (код + PKCE)
    M->>C: Access Token
    C->>M: Запросы с токеном — агент работает

Ключ здесь в том, что весь auth-поток происходит вне контекстного окна модели. Агент не «видит» и не хранит пароли или сырые токены — он получает уже готовый access token через стандартный OAuth 2.1-механизм.

С точки зрения пользователя — это один клик в браузере. С точки зрения команды безопасности — это OAuth, реализованный правильно: на уровне пользователя, со скоупами, привязанный к аудитории, отзываемый, без общих секретов в конфигурационных файлах.

MCP против CLI и Skills: честное сравнение

ПараметрCLI / SkillsMCP
Простота внедрения✅ Высокая⚠️ Требует настройки
Auth вне контекста агента❌ Нет✅ Да
Поддержка OAuth 2.1❌ Нет✅ Да
Аудит и журналирование❌ Минимальное✅ Полное
Потребление токенов✅ Минимальное⚠️ Высокое
Мультиагентные сценарии⚠️ Ограниченно✅ Нативно
Корпоративное развёртывание❌ Сложно✅ Оптимально

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

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

💡 Когда выбирать MCP

Используйте MCP, если:

  • У вас более одного агента или мультиагентная архитектура
  • Агенты действуют от имени других пользователей (B2B-сценарии)
  • Нужен аудит-трейл и централизованное управление доступом
  • Есть compliance-требования (SOC 2, ISO 27001 и т.д.)
  • Масштаб развёртывания — больше небольшой команды

«Идеальный MCP» — только auth-шлюз?

Мысль Шона Линча о том, что идеальная форма MCP — это просто auth-шлюз для API — звучит радикально, но имеет серьёзное основание. Вся накопленная критика MCP сводится к одному: протокол съедает слишком много токенов.

Определения инструментов MCP могут сжигать 55 000+ токенов ещё до того, как агент обработает единственное сообщение пользователя.

Perplexity CTO Денис Ярац объявил в марте 2026 года, что Perplexity уходит от MCP, сославшись на 72% потребления контекстного окна для описаний инструментов MCP.

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

Преимущество MCP в части авторизации над CLI реально в теории, но на практике экосистема ещё догоняет спецификацию.

📝 Практический пример: EMA в корпоративной среде
18 июня 2026 года команда MCP опубликовала Enterprise-Managed Authorization (EMA) как стабильное расширение, устранив главный барьер для корпоративного развёртывания MCP. Ранее каждый сотрудник был вынужден вручную проходить OAuth для каждого MCP-сервера в отдельности — это создавало очереди тикетов для IT-команд и лишало службу безопасности централизованного контроля и аудит-трейла. EMA полностью меняет эту модель: администраторы один раз настраивают MCP-аутентификацию в identity provider, и сотрудники автоматически получают все утверждённые коннекторы при первом входе.

Текущее состояние экосистемы MCP

Несмотря на дискуссии, MCP уверенно движется в сторону корпоративного стандарта. В апреле 2026 года MCP Dev Summit NA собрал 1200 участников — вдвое больше предыдущего мероприятия, подтвердив, что MCP перешёл в разряд корпоративной инфраструктуры.

К первому кварталу 2026 года экосистема резко выросла: более 9400 серверов в официальном реестре, 97 миллионов ежемесячных загрузок SDK по TypeScript и Python.

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

Вывод

Комментарий Шона Линча — это не просто наблюдение, а точная архитектурная формулировка. MCP может быть сложным, тяжёлым и избыточным для простых сценариев. Но одно он делает принципиально лучше любой альтернативы: выносит авторизацию за пределы агента.

Если однажды появится облегчённая версия MCP, которая делает только это — управляет auth-потоком, выдаёт токены и устраняется с дороги — она изменит то, как мы строим агентные системы. И, как справедливо замечает Линч, это само по себе уже будет победой.

💡 Подводим итог
Главная ценность MCP — не в богатом наборе инструментов и не в стандартизации вызовов функций. Его настоящее преимущество — в том, что auth-поток (авторизация) происходит вне контекстного окна агента и потенциально полностью за пределами его рабочей обвязки. Это делает агентные системы безопаснее, удобнее для пользователей и пригоднее для корпоративного масштабирования.