MCP-серверы: как не наплодить зоопарк и не сломать всё в продакшене

[juniorstack]

Начали активно использовать MCP-серверы в нашей команде (пишем на TypeScript, используем Claude Code и Cursor). За три месяца у нас образовалось 11 MCP-серверов: для БД, для Jira, для внутренней документации, для деплоя, для мониторинга... Теперь у каждого разработчика немного разный набор серверов и разные версии. Начинаются проблемы: агент в Claude Code делает вызов к mcp-db-server, который у одного коллеги v1.2, у другого v1.4, поведение разное. Как вы организуете это хозяйство? Есть ли best practices для команды из 8-12 человек?

[rancid1]

У нас та же боль была. Решили: все MCP-серверы живут в отдельном репо, версионируются через npm workspaces, конфиг для Claude Code и Cursor лежит в .claude/mcp.json и .cursor/mcp.json в корне проекта и коммитится в гит. Новый человек пришёл — сделал npm install, запустил один скрипт setup.sh — всё поднялось. Никаких локальных кастомных конфигов.

[thumper416]

Мы пошли другим путём — сделали один 'мета-MCP-сервер' который является фасадом для всех остальных. Снаружи агент видит один сервер с namespace-префиксами (db_query, jira_create_ticket, docs_search). Внутри он маршрутизирует к реальным сервисам. Плюс: версионирование одного бинаря, централизованные логи, можно добавить rate limiting. Минус: пришлось написать ещё ~500 строк кода для маршрутизации.

[ninja_anton]

@juniorstack, Честно, у нас команда 6 человек и мы просто договорились не делать больше 5 MCP-серверов. Если что-то новое нужно — обсуждаем на ретро, нужно ли вообще или можно обойтись prompt injection в system prompt. Большинство 'нужных серверов' при ближайшем рассмотрении оказываются не нужны — агент и так справляется через bash/curl.

[krayzie]

Главная проблема которую вы описываете — это не MCP, это отсутствие dependency management. Любой инструмент разработки без version pinning превращается в зоопарк. Сделайте package.json для ваших MCP-серверов с точными версиями, добавьте проверку версий в CI. Если у кого-то в команде версия не совпадает с ожидаемой — пайплайн должен об этом говорить.

[delphin]

Мы используем Docker для всех MCP-серверов с stdio транспортом. В docker-compose.yml описаны все серверы с конкретными тегами образов. Claude Code запускает их через docker exec. Изоляция, воспроизводимость, обновление через смену тега. Единственный минус — overhead на запуск контейнера, для быстрых операций иногда заметно.

[lost300z]

@thumper416, идея с мета-сервером-фасадом интересная, но мне кажется вы получили новую точку отказа: если фасад упал или завис, агент теряет доступ ко всему сразу, а не к одному инструменту. Как у вас решена отказоустойчивость — просто рестарт через supervisor, или что-то более хитрое?

[mvdelu]

Ключевая вещь которую мы упустили на старте — разделить MCP-серверы на «команда использует» и «один человек экспериментирует». Как только экспериментальный сервер попадает в общий конфиг без явного статуса, через месяц никто уже не помнит зачем он вообще появился, но убрать страшно. У нас теперь в mcp.json поле «owner» и «status: stable|experimental», и на code review смотрят на это поле как на первый вопрос.

[sleepyraccoon]

@ninja_anton, согласен с лимитом на количество, но критерий «можно ли обойтись bash/curl» работает не всегда — например, для Jira с OAuth и пагинацией писать каждый раз в bash неудобно. Хорошее правило которое у нас прижилось: MCP-сервер оправдан если одно и то же действие повторяется агентом больше пяти раз в неделю. Меньше — промпт или скрипт, не отдельный сервер.