"#ai_on_backend MCP сервер – это не обязательно «плагин» Типичное отношение к MCP серверам слишком часто интуитивно - это отношение как к плагину с рядом инструментов. Вот есть наш AI клиент, и вот мы подключаем сервер, привнося в клиент новые функциональные возможности. В дефолтной интуиции разработчики MCP сервера часто тоже – «навешаю ка я в него сразу весь CRUD: create_news, update_news, delete_news, get_categories, assign_category, check_duplicate... И вот клиент захлебывается в инструментах, контекст раздувается, со всеми небезызвестными вытекающими. * Вот когнитивный трюк: относитесь к MCP серверу в первую очередь как к серверу. Как к отдельной самостоятельной сущности, что отвечает за кусок бизнес-логики и инкапсулирует её, а не просто «предоставляет наружу»! Смотрите на разработку MCP через призму DDD/bounded contexts, и естественным образом начнете принимать правильные решения в проектировании интерфейса. Реальный пример: **Делаю новостной агрегатор - дашборда для событий и алертов. Есть сущность ""новость"" с категориями, комментариями. Уже достаточно, чтобы следуя «интуитивным» подходам разработать обычный такой жирненький CRUD. По ряду причин AI на бэкенд дашборды было решено не внедрять, а подключать извне через MCP протокол. Это значит что агент(ы) должны подписываться на свои источники и наполнять дашборду. Немного подумав я понял что в этом MCP нужен только один инструмент — `publish_news`. И всё. Никаких get_categories, никаких апдейтов топиков, никаких манипуляций — пока они реально не потребуются. Агенту даже знать не нужно, была ли новость уже обработана — сервер сам отвечает за дедупликацию и всё остальное, это кодируется элементарно. Таким образом я сильно разгрузил предыдущий вариант системы, теперь есть несколько внешних агентов-сборщиков, у которых вместо 6-8 инструментов и лишних токенов в контексте - два-три инструмента! (инструмент от дашборды для публикации, и остальные только для работы со своим источником навостей – поисковик, кравлер, gmail, отдельные rss и так далее)"