Комментарии 10
Спасибо за интересную статью! Но использовать 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ке будет прям сильно легче получить более точную информацию о том, что нужно делать дальше.

Что такое MCP-сервер, и зачем он нужен