Инструменты по категориям
В metadata-категории учитываются только структурные операции по индексу XML-выгрузки. Семантический поиск по справке и чтение документных чанков описаны отдельно в категории «Справка по конфигурации», а bundled skill — в «Агентских навыках».
Инструменты по метаданным
conf_doc_list_objects | точный/подстрочный поиск объектов по имени или синониму с фильтром типа, конфигурации и лимитом до 500 записей. |
|---|---|
conf_doc_get_object | карточка объекта со структурными полями, количеством реквизитов и табличных частей, UUID, списком чанков и help pages. |
conf_doc_search_roles_by_object | точный поиск ролей, выдающих права на объект; поддерживает фильтр прав, типа метаданных, конфигурации и лимит до 500 результатов. |
Сильные стороны
29 поддерживаемых типов верхнеуровневых объектов; реквизиты и табличные части; измерения/ресурсы регистров; значения перечислений; ссылки на формы; права ролей и RLS-условия. Один backend хранит несколько конфигураций, а клиенту не нужен доступ к XML или SQLite.
Ограничения
нет графа зависимостей и изменения метаданных; формы представлены ссылками и справкой, а не деревом элементов. Отчётные модули и запросы СКД находятся в документных чанках, но не образуют полноценный индекс всей BSL-кодовой базы. Это снимок XML-выгрузки, а не живая база или EDT workspace.
Когда выбирать
когда нужен локальный OSS-индекс структуры и прав конфигурации вместе с отдельным семантическим слоем справки, но без графа связей и авторства метаданных.
1C Conf Doc превращает XML-выгрузку конкретной конфигурации в справочный индекс. Для этой категории учитываются только operations, непосредственно отвечающие за поиск по смыслу и чтение документного контекста; структурные list/get/role tools вынесены в сравнение «Метаданные конфигурации».
Инструменты по категории
conf_doc_search | семантический FAISS-поиск по документным чанкам с лексическим boost по имени/синониму, фильтром типа объекта и дедупликацией до одного лучшего чанка на объект. |
|---|---|
conf_doc_get_object_chunk | читает полный выбранный фрагмент: overview со справкой и формами, таблицы реквизитов/табличных частей, а для отчётов также модуль объекта и запросы основной СКД. |
conf_doc_query | формирует готовый RAG-ответ с источниками; доступен только при отдельно включенном серверном LLM provider, иначе возвращает 503. |
Сильные стороны
полностью локальный вариант с sentence-transformers по умолчанию; несколько конфигураций в одном backend; прозрачный двухшаговый search → chunk workflow. Top-1 search может дополнительно возвращать нормализованные odata_fields, чтобы агент быстрее нашёл бизнес-объект и его поля.
Ограничения
качество semantic retrieval зависит от содержимого справки/комментариев и embedding-модели; README рекомендует короткие keyword-запросы вместо длинных пользовательских вопросов. odata_fields построены по XML конфигурации и не подтверждают фактический состав OData-публикации. Весь BSL-код не индексируется: модуль объекта извлекается только у отчётов. Подготовка требует отдельного backend, XML-выгрузки и построения embeddings.
Когда выбирать
когда нужна самостоятельная OSS-справка по собственной конфигурации с semantic search, точным углублением в найденный объект и возможностью работать без внешней chat-модели.
Формат
один Agent Skill conf-doc-search, поставляемый рядом с самостоятельным MCP/HTTP backend.
Skill задаёт двухшаговый workflow
короткий semantic search, затем чтение карточки объекта и нужного чанка. Для OData-сценариев он требует сначала использовать найденную структуру как подсказку, а перед $select/$expand/$filter обязательно проверить реальные имена через $metadata целевой публикации.
Что покрывает
- выбор конфигурации и проверку доступности backend;
- формулирование коротких keyword-запросов и фильтрацию по типам объектов;
- углубление
search → get_object → get_object_chunk; - выбор Catalog/Document/Register для data-задач вместо случайных Role/Report результатов;
- чтение реквизитов, табличных частей, справки, модулей отчётов и запросов СКД из чанков;
- диагностику пустой выдачи, HTTP 404/503 и несовместимой размерности FAISS;
- разделение embeddings для поиска и опционального LLM для RAG.
Сильные стороны
skill фиксирует конкретные ограничения backend и предотвращает опасную подмену metadata-структуры фактической OData-схемой. Есть готовые curl-примеры и отдельные workflows для понимания объекта и подготовки запроса к данным.
Ограничения
это инструкция без собственного исполняемого слоя; она полезна только вместе с запущенным 1C Conf Doc API/MCP и заранее проиндексированной XML-выгрузкой. Skill описывает семь read/search tools и намеренно не маршрутизирует административный conf_doc_delete_configuration.
Когда выбирать
когда команда уже использует 1C Conf Doc и хочет, чтобы агент стабильно выполнял search/drill-down и не выдавал поля XML-выгрузки за гарантированные поля OData-публикации.
Что учитывать
conf-doc mcp обращается по HTTP к отдельному FastAPI backend; backend запускается локально или в Docker и хранит общий SQLite/FAISS-индекс одной или нескольких XML-выгрузок конфигуратора.mcp на машине MCP-клиента и embedding-провайдер на backend. По умолчанию Docker использует локальную sentence-transformers модель, но первое получение модели требует сети; вместо нее можно настроить OpenAI-compatible embeddings. Для conf_doc_query дополнительно нужен включенный LLM provider ollama или openai; без него tool ожидаемо возвращает HTTP 503.conf_doc_health, conf_doc_list_configurations и conf_doc_delete_configuration; первые два читают состояние backend, а третий изменяет его. conf_doc_search выполняет FAISS-поиск с дедупликацией до одного лучшего чанка на объект, фильтром типа и лимитом 1–50; роли исключены из векторного индекса и ищутся точным conf_doc_search_roles_by_object. Результат top-1 может содержать odata_fields, но они построены из XML конфигурации, а не из публикации OData, поэтому точные имена полей нужно сверять с $metadata. Индекс read-only относительно исходной конфигурации, однако conf_doc_delete_configuration удаляет запись конфигурации из индекса и при remove_files=true также серверные каталоги XML-слота, Markdown и FAISS. MCP и HTTP API не имеют встроенной аутентификации или разграничения read/admin операций; README прямо рекомендует не публиковать порт без reverse proxy и аутентификации. README-таблица перечисляет 7 tools и пропускает role-search/delete, тогда как production-код и тест регистрации подтверждают 9.