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 и так далее)