Комментарии 3
Думаю, это правильное решение. Если ИИ давать сразу всё, он только запутается. Лучше показывать ему только то, что нужно в данный момент. Так и работает быстрее, и ошибок меньше.
Интересная архитектура. По сути, в какой-то момент MCP начинает требовать собственного control plane: каталог, роутинг, нормализация, права, хуки, метрики.
мне кажется, самый неприятный вопрос начинается после дедупликации так как одинаковое имя инструмента ещё не гарантирует одинаковую семантику и даже совместимость схем между разными версиями серверов: пока различия сводятся к podName vs pod, нормализатор выглядит отлично, но если один сервер немного иначе трактует фильтр, namespace или destructive-операцию, прослойка может уже не исправить ошибку, а незаметно её замаскировать.
есть ли у вас проверка совместимости инструментов внутри одного kind? например fingerprint схем, версионирование capabilities или запрет объединения при расхождении контрактов? думаю на следующем масштабе именно drift между серверами станет большей проблемой, чем размер каталога
у меня нет внутри вида разных версий, если новая версия приходит я весь вид обновляю, а если понадобится чтобы один мцп был другой версии то просто будет новый кайнд типа gitlab-2 или можно будет как то похитрее, с дифами что то придумать, либо в под к мцп сделать сайдкар контейнер с отдельным нормализатором.

Как я раздаю агентам 733 инструмента из 23 мцп серверов