npm - @hubex/mcp - Versions diffs - 0.2.0 → 0.3.0 - Mend

@hubex/mcp 0.2.0 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (3) hide show

package/CONNECTING.md CHANGED Viewed

@@ -21,11 +21,9 @@ npm install -g @hubex/mcp
 Без установки — `npx -y @hubex/mcp`; тогда в конфигах вместо `"command": "hubex-mcp"`
 пишут `"command": "npx"` и `"args": ["-y", "@hubex/mcp"]`.
-Патч-часть версии — дата сборки схем по UTC (`0.2.20260827`), так что по версии
-установленного пакета сразу видно, насколько свежий в нём кэш swagger.
-> Первый релиз выпускается вручную, и до него этот вариант вернёт 404 —
-> пользуйтесь вариантом Б.
+Патч-часть версии — дата сборки схем по UTC (`0.3.20260901`), так что по версии
+установленного пакета сразу видно, насколько свежий в нём кэш swagger. Нулевой патч
+(`0.3.0`) означает ручной выпуск.
 ### Вариант Б — готовый пакет (для тех, кому его передали)
@@ -33,7 +31,7 @@ npm install -g @hubex/mcp
 `@hubex/mcp` в `hubex-mcp`). Установка:
 ```bash
-npm install -g ./hubex-mcp-0.2.0.tgz
+npm install -g ./hubex-mcp-0.3.0.tgz
 ```
 Дальше всё как в варианте А: в `PATH` появляется команда `hubex-mcp`, абсолютные пути

package/README.md CHANGED Viewed

@@ -1,122 +1,59 @@
 # HubEx MCP
-MCP-сервер для управления **тестовыми данными** в HubEx (создание, редактирование, удаление
-заявок, объектов, компаний, пользователей) прямо из Claude.
+Помощник, который позволяет Claude работать с данными HubEx: заводить и править
+заявки, объекты, компании и пользователей обычными словами — «создай тестовую
+заявку по объекту X», «покажи, что в заявке 12345». Программировать для этого
+ничего не нужно, достаточно один раз вписать настройку в вашу программу.
-Окружение задаётся в `HUBEX_ENV`: `dev`, `stg` или `prod`. На проде базовый URL — без префикса
-(`https://api.hubex.ru/fsm`); ограничить его чтением можно через `HUBEX_READONLY=true`.
+Работает с **Claude Desktop**, **Claude Code**, **Cursor** и **Codex CLI**.
-## Что внутри
+---
-- **13 инструментов** (список — в разделе [«Инструменты»](#инструменты)): поиск и исполнение
-  работают через тонкий индекс, а не через по-эндпоинтную генерацию, поэтому их число не растёт
-  вместе с количеством эндпоинтов HubEx (~1100 в 22 сервисах).
-- Единый HTTP-клиент с авторизацией (Bearer + `X-Application-ID`) и понятными сообщениями об ошибках.
-- Два режима авторизации: готовый токен или логин/пароль (Basic → JWT через сервис AUTHN, авто-refresh).
-- Три независимых рубежа ограничения доступа: список HTTP-методов на сервере, тумблеры инструментов
-  в MCP-клиенте, проверка метода на исполнении.
+## Что понадобится
-## Установка
+1. **Node.js версии 20 или новее** — бесплатная программа с сайта
+   [nodejs.org](https://nodejs.org) (берите кнопку **LTS**). Проверить, установлен ли
+   он: откройте Терминал, введите `node -v` и нажмите Enter. Ответ вида `v20.11.0`
+   или больше — всё в порядке.
+2. **Доступ в HubEx** — токен или логин с паролем, тот же, с которым вы заходите
+   в систему.
-```bash
-npm install
-npm run build
-```
-## Инструменты
-13 инструментов, число не зависит от количества эндпоинтов HubEx (~1100 в 22 сервисах).
-| Инструмент | Назначение |
-|---|---|
-| `hubex_whoami` | окружение, tenant, срок действия токена |
-| `hubex_get_guide` | гайд по процессу, топики сгруппированы по областям: база — `start`, `dictionaries`; заявки — `taskcreate`, `taskedit`, `taskchecklists`; объекты и контрагенты — `assets`, `companies`, `users`, `materials`; настройка тенанта — `lifecycle`, `tasktypes`, `roles`, `notifications`, `sla`, `attributes`, `checklisttemplates` |
-| `hubex_list_scopes` | карта сервисов; с `service` — ресурсы внутри |
-| `hubex_search_read_endpoints` | поиск GET-эндпоинтов |
-| `hubex_search_write_endpoints` | поиск POST/PUT/PATCH-эндпоинтов |
-| `hubex_search_delete_endpoints` | поиск DELETE-эндпоинтов |
-| `hubex_search_head_endpoints` | поиск HEAD-эндпоинтов |
-| `hubex_describe_endpoint` | полная схема параметров и тела (до 5 идентификаторов за вызов) |
-| `hubex_request_read` | выполнить GET |
-| `hubex_request_write` | выполнить POST/PUT/PATCH |
-| `hubex_request_delete` | выполнить DELETE (принимает `body`: часть эндпоинтов удаляет пачкой по списку) |
-| `hubex_request_head` | выполнить HEAD |
-| `hubex_create_test_task` | создать тестовую заявку с дефолтами и префиксом `[MCP-TEST]` |
-### Как этим пользоваться
-Типичный путь модели:
-1. `hubex_get_guide` с нужным топиком — понять порядок вызовов.
-2. `hubex_list_scopes` — увидеть сервисы; с `service=WORK` — ресурсы внутри.
-3. `hubex_search_read_endpoints` со `scope`/`tag`/`query` — найти эндпоинт.
-4. `hubex_describe_endpoint` — получить схему только для того, что будет вызвано.
-5. `hubex_request_*` — выполнить.
-Ступени необязательны: зная идентификатор из гайда, можно идти сразу к шагу 4.
-### Ограничение доступных методов
+Сам сервер скачивать и устанавливать не нужно: он загрузится автоматически при
+первом запуске и будет обновляться сам.
-Три независимых рубежа:
+---
-1. `HUBEX_METHODS` на сервере — запрещённые группы не регистрируются и не видны агенту.
-2. Тумблеры инструментов в MCP-клиенте — можно выключить пару `search_delete` + `request_delete`.
-3. Проверка на исполнении — `request_*` принимает только `endpointId` и отклоняет чужой метод.
+## Шаг 1. Найти файл настроек
-Поэтому поиск и исполнение разделены по методам симметрично: выключения только
-поискового инструмента было бы недостаточно.
+У каждой программы он свой:
-## Миграция с 0.1.x
-Это ломающее изменение: все инструменты v1 вида `hubex_work_tasks_list`, `hubex_es_assets_get`
-и подобные (по одному на каждый сгенерированный эндпоинт) больше не существуют. Взамен —
-лестница `hubex_list_scopes → hubex_search_*_endpoints → hubex_describe_endpoint → hubex_request_*`,
-описанная выше. `hubex_whoami` и `hubex_create_test_task` не изменились. Если в сохранённых
-промптах или конфигурации использовались v1-имена инструментов — замените их на новую лестницу.
+| Программа | Файл настроек |
+|---|---|
+| Claude Desktop (macOS) | `~/Library/Application Support/Claude/claude_desktop_config.json` |
+| Claude Desktop (Windows) | `%APPDATA%\Claude\claude_desktop_config.json` |
+| Cursor | `~/.cursor/mcp.json` |
+| Codex CLI | `~/.codex/config.toml` |
-## Конфигурация
+Значок `~` означает вашу домашнюю папку. В Claude Desktop файл можно открыть, не
+разыскивая вручную: **Settings → Developer → Edit Config**. Если файла нет,
+создайте пустой.
-Переменные окружения (см. `.env.example`):
+Для **Claude Code** файл не нужен — там всё делается одной командой, см. шаг 2.
-| Переменная | Обязательна | Описание |
-|---|---|---|
-| `HUBEX_ENV` | да | `dev`, `stg` или `prod` |
-| `HUBEX_APPLICATION_ID` | да | заголовок `X-Application-ID` (для dev-тенанта — `5`) |
-| `HUBEX_AUTH_MODE` | да | `token`, `login` или `service` |
-| `HUBEX_USERNAME` / `HUBEX_PASSWORD` | для `login` | учётные данные |
-| `HUBEX_SERVICE_TOKEN` | для `service` | долгоживущий интеграционный токен |
-| `HUBEX_TENANT_ID` | нет | tenant явно; иначе берётся из JWT (`TenantID`) |
-| `HUBEX_METHODS` | нет | список доступных HTTP-методов через запятую (по умолчанию — все шесть) |
-| `HUBEX_READONLY` | нет | `true` — эквивалент `HUBEX_METHODS=GET,HEAD` |
-| `HUBEX_MASK_PII` | нет | по умолчанию `true` — маскирует ПДн (ФИО, телефоны, email и т.п.) в ответах; `false` отключает маскирование |
-| `HUBEX_SERVICES` | нет | ограничить поиск и исполнение списком сервисов (по умолчанию — все 22) |
-| `HUBEX_DEFAULT_REQUEST_METHOD_ID` | нет | значение по умолчанию для тела write-запросов |
-| `HUBEX_DEFAULT_TASK_TYPE_ID` | нет | значение по умолчанию для тела write-запросов |
-| `HUBEX_DEFAULT_COMPANY_ID` | нет | значение по умолчанию для тела write-запросов |
-Режим `token` переменных не требует: при первом обращении сервер сам попросит
-access-токен (через MCP elicitation, а если клиент этого не умеет — через
-инструмент `hubex_set_token`). По введённому токену запрашивается refresh, и
-дальше сессия продлевается сама. Токены хранятся только в памяти процесса — после
-перезапуска сервер спросит токен заново.
-## Подключение
-Полное руководство для **Claude Code, Claude Desktop, Codex CLI и Cursor** — в [CONNECTING.md](CONNECTING.md).
-Кратко. Соберите пакет (`npm pack`) и установите его — появится команда `hubex-mcp`:
+---
-```bash
-npm install -g ./hubex-mcp-0.2.0.tgz
-```
+## Шаг 2. Вписать настройку
-Claude Desktop (`claude_desktop_config.json`):
+**Claude Desktop и Cursor.** Вставьте это в файл целиком. Если в файле уже
+что-то есть, добавьте только блок `"hubex": { ... }` внутрь существующего
+`"mcpServers"`:
 ```json
 {
   "mcpServers": {
     "hubex": {
-      "command": "hubex-mcp",
+      "command": "npx",
+      "args": ["-y", "@hubex/mcp"],
       "env": {
         "HUBEX_ENV": "dev",
         "HUBEX_APPLICATION_ID": "5",
@@ -127,140 +64,176 @@ Claude Desktop (`claude_desktop_config.json`):
 }
 ```
-Для Claude Code (во всех проектах): `claude mcp add hubex --scope user -- hubex-mcp`
-(переменные окружения задайте через `--env` или в `.env` окружении процесса).
+**Codex CLI** — формат другой:
-## Разработка
+```toml
+[mcp_servers.hubex]
+command = "npx"
+args = ["-y", "@hubex/mcp"]
+[mcp_servers.hubex.env]
+HUBEX_ENV = "dev"
+HUBEX_APPLICATION_ID = "5"
+HUBEX_AUTH_MODE = "token"
+```
+**Claude Code** — одна команда в Терминале, файл править не нужно:
 ```bash
-npm run generate          # перегенерировать оба индекса из swagger/{dev,prod}/*.json
-npm run refresh-swagger   # скачать swagger обоих контуров заново и перегенерировать индексы
-npm run check-swagger     # CI: обновить swagger и упасть, если индекс разошёлся
-npm run release-swagger   # обновить схемы и, при изменениях, выпустить релиз в npm
-npm run typecheck         # проверка типов (src, scripts и test)
-npm test                  # unit-тесты (vitest)
-npm run check-guides      # сверить источники гайдов с первоисточниками
-npm run dev               # запуск из исходников (tsx)
+claude mcp add hubex --scope user \
+  --env HUBEX_ENV=dev \
+  --env HUBEX_APPLICATION_ID=5 \
+  --env HUBEX_AUTH_MODE=token \
+  -- npx -y @hubex/mcp
 ```
-`npm run check-guides -- /path/to/HubEx.Wiki [/path/to/HubEx.Frontend.AdminApp]`
-сверяет `sources` во фронтматтере каждого гайда с первоисточником: страницы вики
-(`admin/...`) — по полю `content_hash` самой страницы, файлы AdminApp
-(`adminapp/...`) — по sha256 содержимого. Без второго пути источники AdminApp
-пропускаются. Ненулевой код возврата означает, что первоисточник изменился и
-гайд пора перечитать.
+### Что означают три строки в настройке
-### Контуры swagger: dev и prod
+| Строка | Что это |
+|---|---|
+| `HUBEX_ENV` | с каким контуром работать: `dev` — тестовый, `prod` — боевой |
+| `HUBEX_APPLICATION_ID` | номер приложения, для тестового контура — `5` |
+| `HUBEX_AUTH_MODE` | как входить: `token` — сервер сам попросит токен при первом обращении |
-Схемы хранятся раздельно, по каталогу на контур, и индекс собирается для каждого:
+Если работаете с боевым контуром, добавьте туда же `"HUBEX_READONLY": "true"` —
+тогда сервер сможет только читать данные и ничего не изменит.
-| Контур | Кэш схем       | Индекс                      | Источник                                                     |
-| ------ | -------------- | --------------------------- | ------------------------------------------------------------ |
-| `dev`  | `swagger/dev/`  | `generated/index.dev.json`  | `https://dev-api.hubex.ru/fsm/{SERVICE}/swagger/{версия}/swagger.json` |
-| `prod` | `swagger/prod/` | `generated/index.prod.json` | `https://api.hubex.ru/fsm/{SERVICE}/swagger/{версия}/swagger.json` (то же, что раздаёт [doc.hubex.ru](https://doc.hubex.ru/#/)) |
+Это необходимый минимум. Остальные настройки — ограничение прав, вход по логину,
+значения по умолчанию — собраны ниже в разделе [«Все настройки»](#все-настройки);
+для первого запуска они не нужны.
-Контур выбирается на старте сервера по `HUBEX_ENV`: `prod` читает prod-каталог,
-`dev` и `stg` — dev-каталог (отдельного стенда документации у stg нет). Поиск,
-`hubex_describe_endpoint` и валидация тел запросов работают по схемам выбранного
-контура, так что на проде агент не увидит эндпоинтов, которых там ещё нет.
+---
-`npm run generate` всегда пересобирает оба индекса — оба каталога должны быть на месте.
+## Шаг 3. Перезапустить программу
-Список сервисов берётся со страницы документации контура — `doc.hubex.ru` для prod
-и `dev-doc.hubex.ru` для dev. Каталог `swagger/` источником быть не может: по нему
-не узнать о сервисе, которого там ещё нет. Со страницы берутся только ссылки на
-хост своего контура — dev-страница перечисляет заодно и stg.
+Именно **полностью закрыть и открыть заново**, а не свернуть окно. Claude Desktop
+на macOS удобно закрывать через ⌘Q.
-`npm run refresh-swagger` без аргументов обновляет оба контура. Ограничения:
+---
-```bash
-npm run refresh-swagger -- --catalog=prod            # только prod
-npm run refresh-swagger -- --catalog=dev WORK ES ADM # отдельные сервисы одного контура
+## Шаг 4. Ввести токен
+При первом обращении к HubEx сервер попросит access-токен — появится поле ввода,
+куда его нужно вставить. Токен хранится только в памяти: после перезапуска
+программы сервер спросит его снова.
+Если вы предпочитаете входить по логину и паролю, замените в настройке строку
+`"HUBEX_AUTH_MODE": "token"` на три строки:
+```json
+"HUBEX_AUTH_MODE": "login",
+"HUBEX_USERNAME": "ваш@логин.ru",
+"HUBEX_PASSWORD": "ваш пароль"
 ```
-Список сервисов допустим только вместе с `--catalog`, а индекс после загрузки всё
-равно строится по всему каталогу контура. Версия схем — `v1.0.0.0`, меняется через
-`HUBEX_SWAGGER_VERSION`.
+Тогда ничего вводить не придётся — сервер получит и будет продлевать токен сам.
-### Проверка расхождений в пайплайне
+---
-`npm run check-swagger` обновляет схемы и сравнивает результат с тем, что лежит в
-репозитории. Сравнение идёт в два слоя, потому что индекс хранит только сигнатуры:
+## Шаг 5. Проверить, что всё работает
-- **файлы схем** — по sha256: какой `swagger/<контур>/*.json` появился, пропал или
-  изменился. Этот слой ловит правки внутри схем тел запросов и ответов — новое
-  поле, изменившийся тип, — которых в индексе нет вовсе;
-- **индекс** — какие эндпоинты появились, пропали и у каких изменилась сигнатура
-  (`summary`, `tags`, path/query-параметры, наличие и обязательность тела). Порядок
-  тегов и параметров сравнивается как множество, поэтому перестановка внутри
-  swagger расхождением не считается.
+Напишите в чате: **«Спроси у HubEx, кто я»**. В ответ придёт окружение, тенант и
+срок действия токена — значит, связь есть.
-Если файл изменился, а сигнатуры нет, отчёт говорит об этом прямо — значит правка
-внутри тела или ответа.
+В Claude Code то же самое проверяется командой `claude mcp list`: напротив
+`hubex` должно стоять `✓ connected`.
-Коды возврата разводят дрейф и поломку — пайплайну есть на что реагировать:
+---
-| Код | Значение                                                   |
-| --- | ---------------------------------------------------------- |
-| `0` | расхождений нет, индексы в репозитории актуальны            |
-| `1` | схемы разошлись: появились, пропали или изменились эндпоинты |
-| `2` | проверку выполнить не удалось: сеть, HTTP != 200, битый JSON |
+## Все настройки
-Если страница документации недоступна, `refresh-swagger` предупреждает и берёт
-список сервисов из каталога, а `check-swagger` завершается кодом `2`: запасной
-список вернул бы слепое пятно на новый сервис, ради которого проверка и нужна.
+Всё перечисленное вписывается в тот же блок `"env"` из шага 2 (в Codex — в секцию
+`[mcp_servers.hubex.env]`). Значения всегда пишутся в кавычках, даже числа.
-Как и `refresh-swagger`, принимает `--catalog=dev|prod|all` (по умолчанию оба).
-Схемы и индексы после запуска остаются **обновлёнными**, поэтому в пайплайне
-`git diff` можно опубликовать артефактом, а локально — сразу закоммитить.
-Загрузка атомарна: при обрыве сети рабочий каталог остаётся нетронутым, и код `2`
-не будет спутан с реальным расхождением.
+### Обязательная — одна
-### Ежедневная сборка
+| Настройка | Что делает |
+|---|---|
+| `HUBEX_APPLICATION_ID` | Номер приложения, который HubEx требует в каждом запросе. Для тестового контура — `5`. Без неё сервер не запустится. |
-Вся логика лежит в `scripts/release-swagger.ts` и запускается одной командой —
-`npm run release-swagger`. Пайплайн `azure-pipelines-swagger.yml` только вызывает
-её по расписанию, поэтому тот же сценарий целиком прогоняется локально:
+### Куда подключаться
-```bash
-npm run release-swagger -- --dry-run   # без коммита, push и публикации
+| Настройка | Что делает | По умолчанию |
+|---|---|---|
+| `HUBEX_ENV` | Контур: `dev` — тестовый, `stg` — предбоевой, `prod` — боевой | `dev` |
+| `HUBEX_TENANT_ID` | Номер тенанта. Обычно не нужен: сервер сам берёт его из вашего токена. Пригодится, только если у вас доступ сразу к нескольким тенантам | берётся из токена |
+### Как входить
+| Настройка | Что делает | По умолчанию |
+|---|---|---|
+| `HUBEX_AUTH_MODE` | Способ входа: `token` — сервер спросит токен при первом обращении, `login` — вход по логину и паролю, `service` — по долгоживущему служебному токену | `token` |
+| `HUBEX_USERNAME` | Логин. Нужен только при `HUBEX_AUTH_MODE=login` | — |
+| `HUBEX_PASSWORD` | Пароль. Нужен только при `HUBEX_AUTH_MODE=login` | — |
+| `HUBEX_SERVICE_TOKEN` | Служебный токен, который выдаёт администратор HubEx. Нужен только при `HUBEX_AUTH_MODE=service`. Удобен, когда сервер работает сам по себе и спросить токен не у кого | — |
+### Что помощнику разрешено делать
+| Настройка | Что делает | По умолчанию |
+|---|---|---|
+| `HUBEX_READONLY` | `"true"` — помощник может только смотреть данные и ничего не изменит. Самый простой способ обезопасить боевой контур | `"false"` |
+| `HUBEX_METHODS` | Точный список разрешённых действий через запятую: `GET` — чтение, `POST`/`PUT`/`PATCH` — создание и правка, `DELETE` — удаление, `HEAD` — проверка наличия. Например `"GET,POST,PUT"` — можно создавать и править, но не удалять. Запрещённое исчезает из списка инструментов, так что помощник об этом даже не узнает | все шесть |
+| `HUBEX_SERVICES` | Ограничить круг систем, с которыми работает помощник, например `"WORK,ES,ADM"` — заявки, объекты и администрирование | все 22 |
+| `HUBEX_MASK_PII` | Скрывает персональные данные (ФИО, телефоны, почту) в ответах. `"false"` отключает, если ПДн нужны в работе | `"true"` |
+### Чтобы меньше уточнять при создании заявок
+Эти три подставляются автоматически, когда помощник создаёт заявку и значение не
+указано явно. Полезно, если вы всегда работаете с одной компанией или одним типом
+заявок. Номера подскажет администратор HubEx.
+| Настройка | Что делает |
+|---|---|
+| `HUBEX_DEFAULT_COMPANY_ID` | Компания по умолчанию |
+| `HUBEX_DEFAULT_TASK_TYPE_ID` | Тип заявки по умолчанию |
+| `HUBEX_DEFAULT_REQUEST_METHOD_ID` | Способ обращения по умолчанию (например, «звонок» или «почта») |
+### Пример: строгая настройка для боевого контура
+Помощник видит только заявки и объекты, ничего не меняет, персональные данные
+скрыты:
+```json
+"env": {
+  "HUBEX_ENV": "prod",
+  "HUBEX_APPLICATION_ID": "5",
+  "HUBEX_AUTH_MODE": "token",
+  "HUBEX_READONLY": "true",
+  "HUBEX_SERVICES": "WORK,ES"
+}
 ```
-Скрипт обновляет схемы обоих контуров и, если что-то изменилось, прогоняет
-typecheck, тесты и сборку, поднимает версию, коммитит, пушит и публикует пакет.
-Работает **только в ветке `swagger-daily`**, `main` не трогает.
+Про `"true"` и `"false"`: сервер считает настройку выключенной, если написано
+`"false"`, `"0"`, `"no"` или пусто. Любое другое слово он поймёт как «включено»,
+поэтому пишите ровно `"true"` или `"false"`.
-Релиз выпускается только из чистого рабочего дерева: свои пути (`swagger/`,
-`generated/`, `package.json`) скрипт коммитит целиком, и чужая незакоммиченная
-правка в них уехала бы в автоматический коммит.
+---
-CI-триггера у пайплайна нет, только расписание: ручные слияния `main` →
-`swagger-daily` ничего не запускают, публикация происходит исключительно после
-автоматического обновления схем. Синхронизация ветки с `main` делается руками.
+## Если что-то пошло не так
-Версия релиза — `0.2.YYYYMMDD`. Если при повторном дрейфе за сутки такая версия
-уже в реестре, схемы коммитятся, а публикация пропускается: следующая уедет назавтра.
+| Что видите | Что делать |
+|---|---|
+| `command not found: npx` | Node.js не установлен — вернитесь к разделу «Что понадобится» |
+| Сервер не появился в списке | Программа не была перезапущена полностью; закройте её целиком и откройте снова |
+| Ошибка 401 или «токен истёк» | Введите токен заново либо перейдите на вход по логину и паролю |
+| Ошибка про JSON-файл | Скорее всего лишняя или пропущенная запятая; проверьте файл в любом онлайн-валидаторе JSON |
-Перед первым запуском нужно:
+Отдельная тонкость для разработчиков: внутри папки с исходниками самого проекта
+команда `npx @hubex/mcp` не сработает — запускайте её из любого другого каталога
+или используйте `npm run dev`.
-1. создать ветку `swagger-daily` из `main` — файл пайплайна должен быть в ней;
-2. дать Build Service право **Contribute** на репозиторий, иначе push не пройдёт;
-3. убедиться, что на `swagger-daily` нет branch policies;
-4. завести секретную переменную `NPM_TOKEN` с токеном публикации npm.
+---
-### Как добавить сервис
+## Что дальше
-1. Передайте новый сервис команде `npm run refresh-swagger -- --catalog=<dev|prod> <SERVICE>`
-   либо положите его swagger в `swagger/<dev|prod>/<SERVICE>.json`.
-2. `npm run generate` — индексы перестраиваются по всем файлам обоих каталогов
-   автоматически (при использовании `refresh-swagger` этот шаг уже выполнен),
-   курировать список эндпоинтов не нужно.
-3. `npm run build`.
+- [CONNECTING.md](CONNECTING.md) — подробные инструкции по каждой программе,
+  все способы входа, полный список настроек.
+- [DEVELOPMENT.md](DEVELOPMENT.md) — гайд для разработчика: устройство сервера,
+  список инструментов, кэш swagger, команды сборки и релиза.
 ## Безопасность
-- На проде используется отдельный кэш схем `swagger/prod/`: эндпоинты, которых на
-  проде ещё нет, агенту не видны.
-- Все мутационные инструменты помечены «(изменяет данные)» в описании.
-- `HUBEX_READONLY=true` полностью отключает изменение данных.
-- Тестовые заявки из `hubex_create_test_task` помечаются префиксом `[MCP-TEST]`.
+- Тестовые заявки, созданные помощником, помечаются префиксом `[MCP-TEST]`.
+- Персональные данные в ответах (ФИО, телефоны, почта) скрываются автоматически.
+- `HUBEX_READONLY=true` полностью запрещает любые изменения данных.
+- Не публикуйте файл настроек с паролем или токеном.

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@hubex/mcp",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "type": "module",
   "description": "MCP server for managing HubEx test data (tasks, assets, companies, users) via the HubEx REST API",
   "author": "HubEx Team",