MCP - новая проблема.
Есть такой стандарт для стандартизированного добавления кастомных тулов - MCP.
Он позволяет разрабатывать тулы на любом языке и выставлять их наружу, для использования агентом, по протоколу JSON-RPS через http (независимый удаленный сервис) или stdio (дочерний процесс).
Вроде бы крутая штука. Если бы не детали реализации)
Главная проблема такая - по стандарту MCP сервер выставляет метод tools/list, возвращающий список тулов в формате name, description, inputSchema.
В чем проблема?
Предположим мы выставляем в MCP API какой-то серьезной системы. Например, Atlassian. Сколько там методов? А какого размера у них inputSchema?
А контекст не бесконечен, более того, после заполнения 50% контекста качество ответов ухудшается.
Т.е. подключив пару тяжелых MCP серверов есть шанс сразу же, с первого запроса, снизить качество работы LLM. А MCP могут и не пригодиться в данном сеансе работы.
Вторая проблема - агент подключается ко всем MCP при старте, вызывая ряд методов (initialize, tools/list) что требует времени.
Слышал по этому поводу мнения, что MCP нам вообще не нужны.
Я бы сказал - такие MCP - да, не нужны. А в целом идея хорошая, не все скилами можно реализовать из-за сложности и вопросов безопасности.
Что делать?
1) несколько профилей агента, с разным набором MCP серверов. Возможно даже lite версию вообще без MCP (Claude Code через
2) переписать MCP на skill если это простая прокси к внешнему API. Скил может включать в себя Python скрипты. Агенты такие скилы неплохо пишут.
Скилы сделаны "по уму", там в контекст по умолчанию выставляется только name и description, содержимое SKILL.md и другие файлы добавляются по мере необходимости.
Этап подключения для скилов отсутствует, это просто специализированный промт.
3) lazy load описаний и схем тулов, сделанный на уровне агента. Claude Code, видимо по принципу "Я тебя породил, ..." реализовал это первым https://vc.ru/ai/2864901-claude-code-i-mcp-lazy-loading-uluchshaet-ai-agentov.
Итоги, цитата:
Причем lazy load включается тоже lazy - когда описания MCP tools начинают занимать более 10% контекстного окна. Красиво)
Причем есть предложение дальнейших оптимизаций: https://github.com/anthropics/claude-code/issues/44536
Включая:
а) грузить description скилов тоже лениво. Тут видится противоречие, по стандарту именно description содержит информацию когда подгружать скил. Имя конечно тоже должно быть адекватным, но оно может быть очень коротким.
С другой стороны, если имена нескольких скилов лексически\семантически похожи - ленивая загрузка будет работать, т.к. агент загрузит оба скила и далее уже по описанию выберет правильный.
б) ленивое подключение к MCP - тут понятно
в) профили агентов - это стандартизация решения номер №1. Сейчас это несколько разных папок с агентами, а должны быть - несколько файлов профиля.
г) загрузка тулов\скилов по условию (только при написании тестов, например)
д) динамическая выгрузка
Ну в общем полноценное управление памятью, т.е контекстом)
Есть похожие issues и для других агентов, пока в статусе Open
https://github.com/openai/codex/issues/2335
https://github.com/anomalyco/opencode/issues/17482
4) решение на уровне стандарта MCP. Вот тут все плохо, идут обсуждения, но конкретных предложений нет.
Вот предложение https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1576
Вот еще одно https://github.com/orgs/modelcontextprotocol/discussions/532
Но до реализации дело не дошло.
Вывод - AI агенты активно развиваются.
#ai #ai_agents #mcp #ai_agent_context_management
Есть такой стандарт для стандартизированного добавления кастомных тулов - MCP.
Он позволяет разрабатывать тулы на любом языке и выставлять их наружу, для использования агентом, по протоколу JSON-RPS через http (независимый удаленный сервис) или stdio (дочерний процесс).
Вроде бы крутая штука. Если бы не детали реализации)
Главная проблема такая - по стандарту MCP сервер выставляет метод tools/list, возвращающий список тулов в формате name, description, inputSchema.
В чем проблема?
Предположим мы выставляем в MCP API какой-то серьезной системы. Например, Atlassian. Сколько там методов? А какого размера у них inputSchema?
А контекст не бесконечен, более того, после заполнения 50% контекста качество ответов ухудшается.
Т.е. подключив пару тяжелых MCP серверов есть шанс сразу же, с первого запроса, снизить качество работы LLM. А MCP могут и не пригодиться в данном сеансе работы.
Вторая проблема - агент подключается ко всем MCP при старте, вызывая ряд методов (initialize, tools/list) что требует времени.
Слышал по этому поводу мнения, что MCP нам вообще не нужны.
Я бы сказал - такие MCP - да, не нужны. А в целом идея хорошая, не все скилами можно реализовать из-за сложности и вопросов безопасности.
Что делать?
1) несколько профилей агента, с разным набором MCP серверов. Возможно даже lite версию вообще без MCP (Claude Code через
--strict-mcp-config --mcp-config '{}', Gemini\Qwen Code через --allowed-mcp-server-names '{}').2) переписать MCP на skill если это простая прокси к внешнему API. Скил может включать в себя Python скрипты. Агенты такие скилы неплохо пишут.
Скилы сделаны "по уму", там в контекст по умолчанию выставляется только name и description, содержимое SKILL.md и другие файлы добавляются по мере необходимости.
Этап подключения для скилов отсутствует, это просто специализированный промт.
3) lazy load описаний и схем тулов, сделанный на уровне агента. Claude Code, видимо по принципу "Я тебя породил, ..." реализовал это первым https://vc.ru/ai/2864901-claude-code-i-mcp-lazy-loading-uluchshaet-ai-agentov.
Итоги, цитата:
Контекст при старте: экономия до 95%. В одном реальном кейсе — с 51 000 токенов до 8 500.
Точность на Opus 4: с 49% до 74% на MCP-бенчмарках с большими библиотеками инструментов.
Точность на Opus 4.5: с 79,5% до 88,1%.
Максимальное описание инструмента: ограничено 2 КБ
Причем lazy load включается тоже lazy - когда описания MCP tools начинают занимать более 10% контекстного окна. Красиво)
Причем есть предложение дальнейших оптимизаций: https://github.com/anthropics/claude-code/issues/44536
Включая:
а) грузить description скилов тоже лениво. Тут видится противоречие, по стандарту именно description содержит информацию когда подгружать скил. Имя конечно тоже должно быть адекватным, но оно может быть очень коротким.
С другой стороны, если имена нескольких скилов лексически\семантически похожи - ленивая загрузка будет работать, т.к. агент загрузит оба скила и далее уже по описанию выберет правильный.
б) ленивое подключение к MCP - тут понятно
в) профили агентов - это стандартизация решения номер №1. Сейчас это несколько разных папок с агентами, а должны быть - несколько файлов профиля.
г) загрузка тулов\скилов по условию (только при написании тестов, например)
д) динамическая выгрузка
Ну в общем полноценное управление памятью, т.е контекстом)
Есть похожие issues и для других агентов, пока в статусе Open
https://github.com/openai/codex/issues/2335
https://github.com/anomalyco/opencode/issues/17482
4) решение на уровне стандарта MCP. Вот тут все плохо, идут обсуждения, но конкретных предложений нет.
Вот предложение https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1576
Вот еще одно https://github.com/orgs/modelcontextprotocol/discussions/532
Но до реализации дело не дошло.
Вывод - AI агенты активно развиваются.
#ai #ai_agents #mcp #ai_agent_context_management
GitHub
[FEATURE] Lazy context loading: extend the ToolSearch pattern to all context components · Issue #44536 · anthropics/claude-code
Preflight Checklist I have searched existing requests and this feature hasn't been requested yet This is a single feature request (not multiple features) Problem Statement Claude Code loads ALL...
👍2
Хочется добить тему с MCP, точнее о проблеме с загрязнением контекста тулами из MCP.
Схемами тулов, если уж быть точным.
Есть еще одно решение - MCP Progressive Discovery.
Т.е. MCP сервер не сразу объявляет все доступные тулы, а по мере необходимости.
Как это сделать?
Объявляем meta-tool, один.
В его описании указываем все, что умеет MCP.
Как только клиент его вызывает, возвращаем ему что-то типа: "подожди немного и вызови вот такой тул".
Бросаем событие list_changed - это часть протокола MCP, позволяющая динамически менять список объявляемых тулов и оповещать об этом клиентов.
А клиент, соответственно, получив данное событие обновляет список тулов и вызывает нужный.
Будет ли работать на всех агентах - думаю нет, надо тестить. Агент должен поддерживать событие list_changed.
К слову, если объявить у MCP сервера кастомное API слушателя событий, и бросать ему туда события о том, что происходит в агенте - можно даже не ждать, пока он вызовет Meta-tool.
Ну, например, начали работать с git - логично показать соответствующие тулы.
Еще вариант - тот же meta-tool, но заменяющий собой несколько атомарных тулов.
Например, за все операции с git.
Я тут вижу много проблем: теряем Single Responsibility, схемы становятся формальными (объявляем что-то типа response: object), валидация типов будет происходить в коде в рантайме.
Но в каких-то случаях может пригодится. Можно его переформулировать как упрощение API MCP сервера с целью уменьшения размер схем.
#ai #ai_agents #mcp #ai_agent_context_management
Схемами тулов, если уж быть точным.
Есть еще одно решение - MCP Progressive Discovery.
Т.е. MCP сервер не сразу объявляет все доступные тулы, а по мере необходимости.
Как это сделать?
Объявляем meta-tool, один.
В его описании указываем все, что умеет MCP.
Как только клиент его вызывает, возвращаем ему что-то типа: "подожди немного и вызови вот такой тул".
Бросаем событие list_changed - это часть протокола MCP, позволяющая динамически менять список объявляемых тулов и оповещать об этом клиентов.
А клиент, соответственно, получив данное событие обновляет список тулов и вызывает нужный.
Будет ли работать на всех агентах - думаю нет, надо тестить. Агент должен поддерживать событие list_changed.
К слову, если объявить у MCP сервера кастомное API слушателя событий, и бросать ему туда события о том, что происходит в агенте - можно даже не ждать, пока он вызовет Meta-tool.
Ну, например, начали работать с git - логично показать соответствующие тулы.
Еще вариант - тот же meta-tool, но заменяющий собой несколько атомарных тулов.
Например, за все операции с git.
Я тут вижу много проблем: теряем Single Responsibility, схемы становятся формальными (объявляем что-то типа response: object), валидация типов будет происходить в коде в рантайме.
Но в каких-то случаях может пригодится. Можно его переформулировать как упрощение API MCP сервера с целью уменьшения размер схем.
#ai #ai_agents #mcp #ai_agent_context_management