MCP - новая модная аббревиатура

У меня уже был пост про MCP в Spring AI. Но теория теорией, но для чего эта штука нужна - MCP - не до конца была понятно даже мне.
Но вот хороший и актуальный пример: https://t.me/yegor256news/1625

P.S. Автора кстати рекомендую, если кто до сих пор вдруг его не знает)

#ai #mcp

Зачем нужны MCP сервера?

Как я уже говорил: основная проблема AI в разработке - результат работы AI по определению не детерминирован, а код должен решать какую-то определенную задачу с строгой бизнес-логикой.
А что, если не придумывать код на ходу - а это по сути восстановление информации после ее сжатия с потерями - а просто понять, какой именно код нужен и взять готовый пример.
Эту проблемы может решить MCP сервер, в который загрузили официальную документацию с примерами.
Например, https://context7.com/?q=spring
Идея кажется отличной, но есть пару вопросов:
1) по приведенной выше ссылке - какой источник для Spring мне выбрать? Где больше токенов? Или более новый? Или по всем искать? (но это же долго)
2) как понять, что информацию загрузили правильно - всю, без искажений? к какой именно версии относится? у каждого источника есть Benchmark, но как и кто мерит - не ясно
3) кто отвечает за загрузку? предполагается, что это делают авторы библиотек https://context7.com/docs/adding-libraries , но по факту это не так. будет ли загрузка по данному источнику и дальше работать? если это энтузиасты - большой вопрос... одно дело быть автором open-source библиотеки, другое - безымянным автором источника данных в context7

Вообще идея крутая - зачем восстанавливать информацию или парсить интернет, когда можно подсунуть LLM точный источник. Ее бы стандартизировать (что будет с context7 через год? хорошо, если он станет Docker в своей области, а если нет?), популяризовать и прикрутить верификацию авторов - вообще идеально бы было. Сделал jar - добавь source jar, javadoc jar и mcp сервер.

#mcp #ai

Еще один AI стандарт намечается.

https://agentskills.io/home

В чем суть?
Есть агенты, каждый агент может делать что-то специфичное. Возникает идея стандартизировать его функционал, чтобы переиспользовать.
Например: чтение pdf файлов, создание xlsx таблиц...
Т.е. в первую очередь это касается навыков небольшого размера, полезных множеству агентов. Но не только.

Если посмотреть что представляет собой спецификация навыка - промты, документация, описания API и скрипты.
Пример: https://github.com/anthropics/skills/tree/main/skills/docx
Т.е. навык нужно поддерживать: версии, обновления, security fixes.

Еще можно сравнить с MCP серверами.
MCP - кастомные навыки, домен-специфичные, требующие доступа к БД или другим сервисам, реализуются в отдельном сервисе (MCP сервер).
Skills - навыки общего назначения, лежат внутри агента.

Почему стандарт? Предложил Anthropic, но поддерживают кроме Claude Code уже OpenAI с Microsoft.
Т.е. как минимум 3 из ведущих dev AI агентов. Глядись и Cline подтянется. И GigaCode.

P.S. Да помню я, что в названии блога Java!))))

#ai #mcp

Долговременное хранение контекста AI агента - можно ли попроще?

Я уже писал про GAB - систему хранения контекста диалога https://t.me/javaKotlinDevOps/495.
Напомню тем кто забыл - там два компонента Memorizer (фоновое сохранение данных) и Researcher (компиляция ответа под конкретный запрос пользователя) и два вида памяти: весь диалог и короткие сводки (кэш).
И в целом GAB - это научная работа без практического внедрения.
Когда появится реализация - это будет отдельный сервис а-ля RAG.

Так вот - как можно сделать примерно тоже самое проще? Например, в контексте агента для разработки

Краткий ответ - можно. Подробный - давайте напишем промт для агента с просьбой собрать, сохранить и поддерживать актуальность информации по проекту внутри проекта в текстовых файлах.
Пусть это будет Markdown как некий стандарт, сложившийся не только в AI.
Т.е. процесс выглядит так:
1) инициализируем память собрав всю информацию по проекту и сохранив ее
2) при старте любого диалога подтягиваем информацию
2) после успешного выполнения любых действий над проектом обновляем\чистим информацию в долговременной памяти

Как говорится - ближе к делу.
Встречаем Cline Memory Bank https://docs.cline.bot/prompting/cline-memory-bank

На что стоит обратить внимание:
1) лично я когда говорил о долговременной памяти - я подразумевал контекст сессии.
На самом деле не обязательно им ограничиваться.
В случае разработки - сессия = таска, а контекст по проекту имеет смысл хранить постоянно.
Т.е по сути он разделяется на постоянную часть и текучку.

На примере Cline Memory Bank постоянная часть:

`projectbrief.md`
- Foundation document that shapes all other files
- Created at project start if it doesn't exist
- Defines core requirements and goals
- Source of truth for project scope

`productContext.md`
- Why this project exists
- Problems it solves
- How it should work
- User experience goals

`systemPatterns.md`
- System architecture
- Key technical decisions
- Design patterns in use
- Component relationships
- Critical implementation paths

`techContext.md`
- Technologies used
- Development setup
- Technical constraints
- Dependencies
- Tool usage patterns

Текучка:

`activeContext.md`
- Current work focus
- Recent changes
- Next steps
- Active decisions and considerations
- Important patterns and preferences
- Learnings and project insights

`progress.md`

2) Является ли такая структура памяти оптимальной? Хз, но я бы с нее начал.

3) что с поддержкой данной штуки в других агентах? без проблем, т.к. по сути memory bank = промт + способность агента читать и писать в файл.
Пример для Cursor https://www.youtube.com/watch?v=azXNHRtzd5s
Roo Code решили обвернуть это в MCP сервер https://skywork.ai/skypage/en/roo-code-memory-bank-ai-agent/1980851096638783488
Почему бы и нет, поможет при разработке других агентов, причем это могут быть агенты с разным назначением.

4) в Memory Bank хранится информация по архитектуре\структуре проекта, его стек, команды запуска, code style и прочие правила работы.
И если они уже есть в проекте - можно просто их переиспользовать, стандартизировав место хранения.

5) что из этого хранить в git? постоянную часть точно, текучку - наверное нет, т.к. у каждого она своя, но надо смотреть

В общем - рекомендую, сам буду настраивать на всех проектах.

P.S. если сравнить два подхода GAB vs Memory Bank - это как JIT и AoT компиляция

#ai #ai_agents #mcp

Как-то я упустил важное обновление в IDEA - MCP сервер.

Почему важное и зачем вообще это нужно?

AI агенты уже умеют многое. Их стандартные навыки, они же тулы - просмотр содержимого каталогов, чтение и изменение файлов, выполнение скриптов в CLI. Примерный список навыков можно посмотреть на примере OpenCode https://opencode.ai/docs/tools/

Но IDEA умеет гораздо больше - поиск проблем в коде, разного рода рефакторинги, более умный поиск, уже готовые конфигурации запуска... Вот это бы это все агент мог делать за нас...

Ну собственно уже может)
https://www.jetbrains.com/help/idea/mcp-server.html

Список тулов на старте неплох:
- create_new_file
- execute_run_configuration
- execute_terminal_command
- find_files_by_glob
- find_files_by_name_keyword
- get_all_open_file_paths
- get_file_problems
- get_file_text_by_path
- get_project_dependencies
- get_project_modules
- get_repositories
- get_run_configurations
- get_symbol_info
- list_directory_tree
- open_file_in_editor
- reformat_file
- rename_refactoring
- replace_text_in_file
- search_in_files_by_regex
- search_in_files_by_text

Особенно радуют reformat_file и get_file_problems - даже за самым хорошим агентом приходилось исправлять.
rename_refactoring конечно же надо делать средствами IDE, т.к. в этом случае вероятность ошибок стремится к нулю.
execute_terminal_command - меня постоянно раздражают мелкие окошки терминала в чате, по возможности стоит использовать терминал IDEA.
ну и работа с run configuration ускорит процесс отладки для агента (не нужен подбор команд) и уберет дублирование (не надо дублировать в промте)
Фича в Community, поэтому появится в форках - уже в OpenIDE https://habr.com/ru/articles/989716/ и скоро в GigaIDE.

Не хватает остальных рефакторингов. И хорошая новость - плагины тоже могут добавлять MCP навыки, я думаю сейчас этот процесс в самом разгаре)

Лично я буду тестить. Да, по умолчанию MCP сервер выключен. И для части агентов есть автоконфигурация - Cline, Cloude Code. Но даже там, где ее нет это не проблема.

#ide #idea #ai #mcp

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 через --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

В продолжение темы MCP - вот пример переписывания MCP тулов для запуска браузера на скилах и Node.js скриптах https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp

А все почему? Цитата:

Playwright MCP has 21 tools using 13.7k tokens (6.8% of Claude's context). Chrome DevTools MCP has 26 tools using 18.0k tokens (9.0%). That many tools will confuse your agent, especially when combined with other MCP servers and built-in tools.

При этом Claude по большей части эту проблему пофиксили.

P.S. Что интересно - многие агенты написаны на Node.js, и они за собой тащат Node.js через скилы. Под соусом - ну у вас же точно установлен Node.js.

#ai #mcp

Хочется добить тему с 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