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