Comments 17
Спасибо за интересную статью! Но использовать MCP только для того чтобы ознакомить модель с контекстом проекта - это, на мой взгляд, overhead. Достаточно простой просьбы - изучи проект, ознакомься со структурой. Всё. Теперь модель знает всё про ваш проект.
Приветствую, спасибо что уделили время)
Вы в целом правы, но я тут имел ввиду немного другое.
MCP функционал здесь скорей нужен для более "глубокого" погружение в историю проекта. Смысл внутренней базы знаний не в том чтобы описать где/какие папки/сервисы лежат.
А в том, чтобы у LLM была возможность запросить по ключевым словам список уже известных багов в проекте (которые были решены).
Это работает в целом как поиск в каком нибудь трекере jira по задачам/багам. Но в моем случае - трекера нет, и нужно все это хранить в какой-то базе (она может быть любой, но в моем случае это просто папка .local-kb/ Для наглядности приведу пример:
1) Вы получаете багу, фиксите ее.
2) Заводите файл .local-kb/bugs/incorrect-safari-font-renderer-2025-12-28.md
3) Внутри этого файла, примерное такое содержание
---
id: bug-YYYY-MM-DD-short-name
type: bugfix
title: Название бага
date: YYYY-MM-DD
status: completed
tags: []
apps: []
packages: []
files: []
related: []
---
# Название бага
## 🐛 Проблема
Описание проблемы и как она проявлялась.
## 🔍 Причина
Корневая причина бага.
## ✅ Решение
Как был исправлен баг.
## 🧪 Как воспроизвести (было)
Шаги для воспроизведения до фикса.
И при решение задач в будущем, LLM будет опираться на информацию связанную с этой задачей. (Если scope новой баги/задачи попадет под нее).
Поэтому появляется огромный смысл документировать все, что вы делаете в проекте не только в виде кода/комментариев.
Вот если бы только были какие-то уже готовые утилиты, чтобы хранить исправления вместе описанием... Или какие-то сервисы, где можно было бы описывать баги и работу с ними... Но таких нет.
Вода
интересно для меня как новичка, но вот как AI агент понимает, что
а) у него есть специализированный MCP сервер посвященный именно этой теме? или он запрашивает все имеющиеся сервера
б) какую функцию у него ему надо вызвать?
Приветствую, поделюсь своим опытом, на примере редактора Cursor
Представим, что вы уже подключили существующий mcp сервер (или создали свой). Пример от меня также есть на Github
1) Нужно добавить интерфейс для подключения в .cursor/mcp.json
"ui-kit": {
"command": "npx", // команда для запуска вашего сервера на node js
"args": [ // аргументы для запуска сервера
"tsx",
"mcp/mcp-ui-kit-server/src/server.ts"
],
"cwd": "" // опционально, указываем путь из какой папки запустить команду
}Допустим, ваш MCP сервер реализует следующий интерфейс для чтения LLMкой (иначе говоря - tools)
| `uikit_list_components` | Список компонентов (фильтр по пакету, категории) | Обзор доступных компонентов |
| `uikit_get_component` | Детали компонента (props, events, slots) | Понять API компонента перед использованием |
| `uikit_search` | Поиск по имени, описанию, категории | Найти нужный компонент |
| `uikit_list_icons` | Список иконок с группировкой | Найти нужную иконку |
| `uikit_generate_usage` | Генерация примера использования | Быстро получить код для копирования |
| `uikit_stats` | Статистика документации | Обзор UI Kit |
После чего, проверяете конфигурацию (что все корректно подключено) в настройках Cursor. `Settings - Cursor Settings - Tools & MCP. Там примерно такая картина должна быть, если статус зеленый - значит Cursor успешно запустил ваш сервер, и все корректно работает.
2) Дальше, в корне файла в AGENTS.md жестко указываете инструкцию, что в случае если задача касается верстки или создания каких-то компонентов использовать mcp-ui-kit-server с развернутым описанием выше указанных tools.
Это кстати можно дополнительно сделать в самой реализации MCP сервера - там есть поле description . Но для примера, скину как эта инструкция реализована у меня.
#### 4. 🎨 mcp-ui-kit-server — Документация UI компонентов
MCP сервер на Node.js для работы с документацией Vue UI компонентов. Предоставляет информацию о props, events, slots компонентов из `@package/ui` и `@package/ai-kit`.
| Инструмент | Описание | Когда использовать |
|------------|----------|-------------------|
| `uikit_list_components` | Список компонентов (фильтр по пакету, категории) | Обзор доступных компонентов |
| `uikit_get_component` | Детали компонента (props, events, slots) | Понять API компонента перед использованием |
| `uikit_search` | Поиск по имени, описанию, категории | Найти нужный компонент |
| `uikit_list_icons` | Список иконок с группировкой | Найти нужную иконку |
| `uikit_generate_usage` | Генерация примера использования | Быстро получить код для копирования |
| `uikit_stats` | Статистика документации | Обзор UI Kit |
**Документируемые пакеты:**
- `@package/ui` — Основная библиотека UI компонентов
- `@package/ai-kit` — Компоненты для AI функциональности
**Примеры использования:**
```
# Список компонентов форм
uikit_list_components(category: "form")
# Список компонентов из ai-kit
uikit_list_components(package: "ai-kit")
# Детали компонента AppButton
uikit_get_component(name: "AppButton")
# Поиск компонентов для модальных окон
uikit_search(query: "modal")
# Список иконок действий
uikit_list_icons(category: "actions")
# Пример использования компонента
uikit_generate_usage(name: "AppInput", framework: "vue")
```
**Когда использовать:**
1. Перед использованием UI компонента — проверь его API через `uikit_get_component`
2. При поиске подходящего компонента — используй `uikit_search` или `uikit_list_components`
3. При работе с иконками — используй `uikit_list_icons`
4. Для быстрого старта — генерируй примеры через `uikit_generate_usage`
---
### 🎯 Стратегия использования MCP серверов
// Тут у меня также указаны инструкции и для других MCP серверов.
5. **При работе с UI компонентами:**
- `uikit_get_component` — узнать API компонента (props, events, slots)
- `uikit_search` — найти подходящий компонент
- `uikit_list_icons` — найти нужную иконку
- `uikit_generate_usage` — получить пример использованияПример реализации MCP сервера для ui-kit, есть на Github (в статье также есть ссылка)
Также, можно попросить агента тестово запустить команды, что все работает. В Cursor это выглядит вот так
Опять же, исходя из вашего проекта и запросов - инструкции могут быть разными. Нужно играться с инструкциями до тех пор, пока не добьете желаемого результата. Прямо как с джунами в вашей команде =))
Что делать, если контекст лежит где-то в другом месте? Например, у вас есть задача, добавить объект запроса для авторизации в системе.
Скачать оба репозитория и открыть две папки в одной сессии агента. Он все обнюхает и сделает как надо. Агенты очень хорошо понимают код и не очень хорошо документацию.
Согласен, что хорошо написанный код является отличной документацией. В случае с кодом собственного проекта иногда этого достаточно. Но я заметил, что когда начал документировать баги собственного проекта в виде задач, он начал лучше решать "похожие" случаи.
А в случае, если информация об интерфейсах API лежит например в сваггере на сервере у бэкендеров, или например метаданные о багах сервера в Sentry, то тут LLMке будет прям сильно легче получить более точную информацию о том, что нужно делать дальше.
Кто его знает. Я запустил пет проект примерно на 40 тысяч строк, из которых агентом (Claude Sonet 4 - 4.5) написана примерно вторая половина (начинал без агента) и при этом не написал ни слова документации сам и удалял всю что писал агент. Код там скорее процедурный, далекий от канонического. Но в целом агент не выполняет задачу хорошо только в случае если я сам не предствляю еще как это впереть в текущую архитектуру или если мне было лень указывать детали и он выбрал решение от балды. И что такое баги я тоже забыл. Агент почти не делает простых ошибок - или его вообще несет не в ту степь, или пишет код без багов. Может задача слишком линейная, трудно сказать.
Непонятно нужен ли MCP для UI библиотеки. Не проще ли генерировать список доступных компонентов и вставлять в Claude.md / agents.md со ссылками на нужный компонент или чгенерированный файл с какой то подробной информацией по нему, аналогично тому что MCP делает при получении списка доступных компонентов? Ну то есть не ясендо конца профит, или ты в md файлах пропишешь список или будешь поднимать какой то сервер для аналогично задачи.
Можно и так. Но вопрос скорее в том, что в случае смены набора компонентов, нужно не забыть об этом написать в ручном описании(а скорее всего так и будет). А MCP примерно как раз и занят такой генерацией, просто за вас. И второй момент, опять же, если это разовый проект - то наверное это и избыточно, тащить кучу MCP серверов, но если работа постоянно ведется в нескольких проектах, то их наличие может быть очень даже большим приимуществом. Я вот как минимум memory.mcp таскаю везде, и порой это помогает ИИ разобраться во схожих косяках, даже в параллельных проектах, если записи в "базе" сервера настроены как глобальные.
Все так и есть. В моем случае, у меня в районе 90 UI компонентов из ui-kit либы. Поддерживать их актуальность путем постоянного обновления root файла с инструкциями для LLM - тяжело.
А теперь можно просто генерировать/обновлять документацию по этим компонентам каждый раз, когда в них что-то меняется и хранить рядом в проекте. Для генерации (и в примере выше) для vue vue-docgen-api. Для React есть тоже хорошая либа
Использую для каждого агента свою документацию с контекстом, при этом документация автоматически обновляется ответственным агентом. Не совсем понимаю, какие плюшки даёт сервер. Пока выглядит как потеря контроля над контекстом. Может имеет смысл в больших командах?
Для ваших целей скорее нужен RAG, чем MCP.
Я понимаю MCP как "lambda-функции для AI" - если надо что-то сделать "на стороне" или получить информацию из внешнего API. Собственно буква P значит "протокол", т.е. универсальный язык общения LLM с внешним миром.
Что такое MCP-сервер, и зачем он нужен