Одна точка доступа для каждого агента вместо 20 MCP-конфигураций на репозиторий.

Предыстория

Платформенная команда обслуживала около шестидесяти инженеров в десятке продуктовых отрядов. За год внедрения MCP каждый отряд подключил собственный набор серверов — GitHub, Postgres, Linear, Sentry, внутренний инструмент развёртывания — прямо в конфигурации Claude Code и Cursor. Каждый репозиторий нёс свой mcp.json, а внедрение нового инструмента означало пул-реквест в каждый проект, которому он был нужен.

Схема работала, но не масштабировалась. Два десятка серверов теперь дублировались в десятках конфигурационных файлов, каждый со слегка расходящимися версиями и ключами, вставленными тем, кто настроил его первым.

Задача

Три проблемы всплывали на каждой ретроспективе.

• Разрастание конфигураций. Добавление или обновление сервера требовало правки каждого репозитория. Конфигурации расходились, и никто не мог с уверенностью сказать, какими инструментами располагает тот или иной отряд.
• Ключи не там, где следует. Персональные токены доступа и API-ключи оседали на машинах разработчиков, а порой и в закоммиченной конфигурации. Ротация скомпрометированного токена превращалась в поиск иголки в стоге сена.
• Переполненное окно контекста. Каждый MCP-сервер при каждом запросе вталкивал в промпт полную схему своих инструментов. При двадцати подключённых серверах агент тратил значительную часть контекста на определения инструментов ещё до того, как видел первую строку самой задачи.

Подход

Команда развернула единый портал onemcp, один раз добавила в него свои серверы и авторизовала каждый вышестоящий сервис на месте. Вместо того чтобы каждый клиент общался с каждым сервером, клиенты общаются с порталом, а портал распределяет запросы по вышестоящим сервисам.

Форму задачи изменили два обстоятельства:

• Одна точка доступа заменяет многие. Репозиторий больше не перечисляет серверы; он направляет Claude Code или Cursor на URL портала и наследует весь отобранный набор инструментов. Замена или обновление сервера выполняется один раз, в портале.
• Code Mode заменяет стену определений. Вместо того чтобы заранее вставлять каждую схему инструмента, портал раскрывает лишь три мета-инструмента — search, describe и execute. Агент по мере надобности находит те немногие инструменты, которые нужны задаче, и вызывает их из единого скрипта за один цикл.

Развёртывание

Миграция шла отряд за отрядом на протяжении двух недель. Для каждого репозитория команда удаляла локальный список серверов и вставляла единственную запись портала. Поскольку ключи хранит портал, разработчики попутно удаляли токены со своих машин.

Платформенная команда сохранила портал единой точкой управления: новые серверы проходили централизованную проверку и добавлялись, а доступ управлялся в одном месте, а не в десятках файлов mcp.json.

Результаты

• Более 20 серверов за одной точкой доступа. Репозитории ссылаются на единственный URL портала. Добавление инструмента — это изменение портала, а не пул-реквест по всему парку.
• Накладные на инструменты за запрос снижены примерно на 90%. Замена сотен предзагружаемых определений тремя мета-инструментами снизила накладные за запрос примерно с 15 000 токенов до около 500 — контекст, который агенты теперь отдают задаче.
• Ключи на стороне хоста. Вышестоящий OAuth и токены остаются в портале, никогда не попадая в клиентские конфигурации или закоммиченные файлы. Ротация — это одно обновление в одном месте.

Мы перестали поставлять MCP-конфигурацию в пул-реквестах. Теперь репозиторий указывает на одну точку доступа и получает всё, а токенами управляет служба безопасности, а не мы.

Связанные примеры внедрения

• ИИ-агент поддержки на «токен-диете»
• Самообслуживаемые агенты для данных без утечки ключей