"MCP (4/4), практики внедрения В процессе оформления предыдущих постов про MCP в статью на Хабре неожиданно написал еще один раздел :) Продублирую его и сюда. — В целом, практики построения систем на основе MCP не сильно отличаются от практик работы с любой другой агентской системой, но есть некоторые нюансы. Управление контекстом Одна из целей обращения к внешним системам - обогащение контекста LLM для решения поставленной задачи. Однако тут важно понимать, что контекст (т.е. токены) стоит денег, он лимитирован по длине, с его ростом LLM начинает медленнее отвечать, и, даже если все ваши данные влезают в контекст, далеко не все LLM одинаково ""умны"" с коротким и длинным контекстом. Соответственно, MCP-сервер должен быть точен и лаконичен в возвращаемых данных, а MCP-хост может применять разного рода техники по управлению контекстом, чтобы снизить стоимость работы с ним: суммаризация, кеширование, использование скользящего окна и т.д. Также стоит подумать о кешировании контекста в тех LLM, которые это поддерживают - это сильно влияет как на время до первого output-токена, так и на цену input-токенов. Скорость работы MCP создавался для работы в агентских системах навроде Claude Desktop или Cursor, где не ожидается моментальных результатов, а скорее дается задача агенту, а дальше он сам собирает нужный контекст из разных мест и/или запускает какие-то тулзы по ходу дела. И это довольно небыстрый процесс временами - тот же Cursor минутами может возиться, разбираясь в проекте и меняя код, однако он всё равно решает поставленные задачи в 10+ раз быстрее меня. В том случае, если нужна скорость или система предполагает высокую нагрузку - стоит подумать о другой, более оптимальной для вашего случая архитектуре. См. комменты к первому посту в серии на эту тему, там от подписчиков были интересные вопросы и идеи :) Качество данных LLM принимает решения на основе тех данных, которые оказались в контексте, и если в него попадает неполная, противоречивая, нерелевантная задаче информация, то ждите проблем: будет путаться, делать не то, что надо, обращать внимание на несущественные детали и т.п. Соответственно, по возможности нужно следить за качеством данных, которые попадают в контекст из внешних систем через MCP-сервера. Правило garbage in - garbage out тут всё ещё работает :) Это касается и того, насколько хорошо и уникально названы и описаны сущности, которые экспортирует MCP-сервер, чтобы модель вызывала те функции, которые вы от неё ожидаете. Безопасность Подключением MCP вы даёте LLM доступ к приватным данным и возможность совершать потенциально деструктивные операции в том окружении, где запущен MCP-сервер. Встроенного механизма авторизации в протоколе на текущий момент нет, он существует только в виде драфта для следующей версии. Так что нужно учесть следующие моменты, особенно при работе со сторонними MCP-серверами: ● проверяйте их код на предмет наличия там небезопасных операций ● запускайте сам MCP-сервер под пользователем с минимально необходимым набором прав и, по возможности, в изолированной среде (в контейнерах, к примеру, что особенно делает интересным вариант запуска через supergateway + sse + docker, описанный ранее) ● если MCP-сервер требует авторизации во внешней системе - у пользователя, которого он для этого будет использовать, тоже должны быть только самые необходимые права ● настраивайте MCP-хост на то, чтобы он спрашивал разрешение у пользователя на получение доступа к ресурсам или на вызов инструментов. Да, это довольно быстро станет обузой в работе, но при работе с непроверенным MCP-сервером стоит об этом подумать Ну и, конечно, нужно помнить о том, в случае коммерческих LLM данные передаются куда-то в облако, и этот вопрос требует отдельной проработки с учётом ваших политик безопасности. #ai #mcp"