Xafari

MCP-сервер для внутренней документации построенной на основе Markdown-документации. Строит легковесный индекс и предоставляет инструменты для поиска и объяснений. Так же включает crawler, который может скачивать документацию Xafari с официального сайта, извлекать чистый текст и примеры кода.

Зачем нужен MCP

MCP (Model Context Protocol) позволяет IDE и агентам обращаться к локальным данным как к «инструментам». Вместо ручного поиска по сайту документации, ассистент вызывает методы search_docs, get_page и get_examples, а сервер отвечает структурированными данными. Это ускоряет работу, дает воспроизводимые ответы и снижает зависимость от внешних источников.

Как MCP ускоряет работу:

• Меньше ручного поиска: вместо переходов по сайту и копипасты — один вызов search_docs/get_page.
• Мгновенная выборка: локальный индекс и кэш дают ответы быстрее, чем браузер + поиск.
• Точнее ответы: инструменты возвращают структуру (заголовки, ссылки, код), а не разрозненный текст.
• Повторяемость: один и тот же запрос даёт одинаковый результат — удобно для командной работы.
• Автодогрузка: если страницы нет в кэше, get_page может скачать её автоматически.
• Офлайн-режим: можно работать без доступа к сайту после первичного краула.

Как работает MCP в этом проекте

• Краулер
  • Скачивает HTML, извлекает читабельный markdown и сохраняет в data/pages.
  • Кэширует страницы и использует ETag/Last-Modified при повторных запусках.
  • Из markdown строится индекс pages.json + index.json для быстрого поиска.
• MCP-сервер читает индекс и отвечает на вызовы инструментов через stdio/http.
• IDE подключается к серверу и использует инструменты прямо в чате.

Быстрый старт

1. Запустить краулер и собрать локальный индекс:
   • npm run crawl
2. Запустить MCP-сервер (stdio):
   • npm run start
3. Запустить HTTP-режим (опционально):
   • npm run start:http
4. Пересобрать индекс без краулинга:
   • npm run reindex

Переменные окружения

• DOCS_BASE_URL (например: https://documentation.galaktika-soft.com/xafari/)
• MAX_PAGES_PER_SESSION (по умолчанию: 10000)
• FETCH_ON_MISS (по умолчанию: true, только если задан DOCS_BASE_URL)
• DATA_DIR (по умолчанию: ./data)
• REQUEST_TIMEOUT_MS (по умолчанию: 15000)
• USER_AGENT
• LOG_FILE (по умолчанию: logs/mcp.jsonl, путь относительно DATA_DIR)
• LOG_STDOUT (по умолчанию: false) — если true, логи дублируются в stdout (удобно в Docker)
• CODE_LANGUAGES (по умолчанию: cs,js,ts,json,yaml,xml,html,css)
• HTTP_PORT (по умолчанию: 3333)
• TOOLS_PREFIX — если задана (непустая), инструменты будут иметь имена вида ${TOOLS_PREFIX}search_docs, ${TOOLS_PREFIX}get_page, ...

Примеры кода

• Примеры сохраняются только для языков из CODE_LANGUAGES.
• Языки нормализуются: c#/csharp → cs, javascript → js, typescript → ts, yml → yaml.
• Если язык не разрешен — блок кода не сохраняется.

Fetch on miss

get_page может автоматически догружать страницу, если ее нет в кэше. Управляется флагом FETCH_ON_MISS (по умолчанию true если задан DOCS_BASE_URL).

Подключение MCP в IDE на примере Cursor

stdio-режим (локальный запуск)

1. Откройте настройки MCP в Cursor.
2. Добавьте новый сервер со следующими параметрами:
   • name: custom-framework-mcp
   • command: node
   • args: ["C:\\Projects\\custom-framework-mcp\\src\\index.js"]
   • cwd: C:\\Projects\\custom-framework-mcp

Пример ~/.cursor/mcp.json

{
  "mcpServers": {
    "custom-framework-mcp": {
      "command": "node",
      "args": ["C:\\Projects\\custom-framework-mcp\\src\\index.js"],
      "cwd": "C:\\Projects\\custom-framework-mcp"
    }
  }
}

stdio-режим (через Docker)

Если сервис запущен в Docker, можно использовать docker exec:

{
  "mcpServers": {
    "custom-framework-mcp": {
      "command": "docker",
      "args": ["exec", "-i", "mcp-service", "node", "/app/src/index.js"]
    }
  }
}

HTTP-режим (SSE)

Если сервис запущен в HTTP-режиме (например, через docker compose), используйте SSE transport:

{
  "mcpServers": {
    "custom-framework-mcp": {
      "url": "http://localhost:3333/sse"
    }
  }
}

Примечание: HTTP-режим требует, чтобы сервис был запущен с npm run start:http или через docker compose (который автоматически запускает HTTP-сервер).

3. Перезапустите MCP-сервер в Cursor.

Чтобы проверить в окне чата напишите

list tools

Запросите какую-либо документацию с источника

Запуск через docker compose

git clone https://github.com/QuAzI/custom-framework-mcp.git
cd custom-framework-mcp
docker compose up -d

Запуск через npx

Локально в репозитории:

• npm install
• npx . — запустит MCP-сервер (stdio) через src/index.js.

Чтобы запускать из любого каталога:

• npm link
• npx --no-install custom-framework-mcp

Запуск прямо из GitHub (без публикации в npm):

• npx github:QuAzI/custom-framework-mcp

Опции краулера:

• npm run crawl — по умолчанию скачивает только новые страницы.
• npm run crawl -- --force — перекачать все страницы.
• npm run crawl -- --no-only-new — отключить режим "только новые".

Примечание:

• --no-only-new делает полный обход с кешем (ETag/Last-Modified), а --force перекачивает все без учета кеша.

GitLab CI/CD (внешний репозиторий документации → индекс → деплой на VM)

В репозитории есть пример пайплайна .gitlab-ci.yml для сценария:

• скачать документацию из внешнего git-репозитория
• собрать индекс из markdown (npm run reindex, данные в DATA_DIR/pages)
• задеплоить на VM по SSH и перезапустить docker compose, чтобы HTTP-сервер поднялся с актуальными pages.json/index.json

CI/CD variables (настраиваются в GitLab → Settings → CI/CD → Variables)

Переменные для скачивания документации:

• DOCS_REPO_URL — URL внешнего репозитория документации (SSH или HTTPS)
• DOCS_REF — ветка/тег (по умолчанию: main)
• DOCS_SUBDIR — подкаталог в репозитории документации с markdown-деревом (по умолчанию: docs)
• DOCS_SSH_PRIVATE_KEY — опционально, SSH ключ для доступа к docs repo (если DOCS_REPO_URL по SSH)
• DOCS_HTTP_TOKEN — опционально, токен для доступа по HTTPS (используется через ~/.netrc)
• DOCS_HTTP_USER — опционально, логин для ~/.netrc (по умолчанию: oauth2, удобно для GitLab)

Переменные для деплоя на VM:

• DEPLOY_HOST — хост VM (DNS/IP)
• DEPLOY_USER — пользователь на VM
• DEPLOY_PATH — каталог на VM, где лежит сервис
• DEPLOY_SSH_PRIVATE_KEY — SSH ключ для деплоя
• DEPLOY_SSH_PORT — опционально, порт SSH (по умолчанию: 22)
• DEPLOY_COMPOSE_SERVICE — опционально, имя сервиса compose (по умолчанию: mcp-service)
• DEPLOY_HEALTHCHECK_URL — опционально, URL для проверки после деплоя (например http://<host>:3333/health)

Ожидаемая структура на VM (DEPLOY_PATH)

Пайплайн предполагает, что на VM уже есть каталог сервиса с docker-compose.yml и исходниками (а CI обновляет только data/):

DEPLOY_PATH/
  docker-compose.yml
  package.json
  src/
  data/              # обновляется из CI (pages/, pages.json, index.json, assets/)

После доставки data.tgz CI выполняет:

• docker compose up -d --remove-orphans
• docker compose restart mcp-service (чтобы сервер перечитал индекс, т.к. он кэшируется в памяти процесса)

Расписание (Schedule)

Чтобы документация/индекс обновлялись регулярно:

1. GitLab → CI/CD → Schedules → Create a new schedule
2. Выберите ветку master
3. Добавьте нужные variables (например DOCS_REPO_URL, DOCS_REF, DOCS_SUBDIR)

Job deploy_vm в .gitlab-ci.yml уже настроен так, чтобы запускаться только для master и schedule (и не запускаться в Merge Request pipeline).

MCP-инструменты

• search_docs(query, limit?)
  • Ищет по индексу документации и возвращает список результатов с title, url, excerpt, headings.
  • limit ограничивает количество результатов (1–20, по умолчанию 5).
• get_page(slug | url)
  • Возвращает полный контент страницы (markdown-текст, headings, codeBlocks, links, breadcrumbs).
  • slug — короткая форма (например, doc_recursive_helper).
  • url — полный адрес страницы документации.
• get_examples(topic, limit?)
  • Ищет страницы по теме и извлекает фрагменты кода.
    • Делает search_docs(topic, limit) по индексу.
    • Берёт первые подходящие страницы и вытаскивает их codeBlocks.
    • Возвращает список примеров с slug, title, url, code.
  • limit ограничивает количество примеров (1–20, по умолчанию 5).
• explain_concept(name)
  • Возвращает краткое описание концепта и ссылку на наиболее релевантную страницу.
    • Делает search_docs(name, 3).
    • Берёт самый релевантный результат и возвращает:
      • summary — это excerpt из результата,
      • page — основная ссылка,
      • related — оставшиеся 1–2 страницы.
  • В related добавляет похожие разделы документации.

stdio-режим

stdio — MCP-сервер общается с IDE через стандартные потоки ввода/вывода. Это нативный режим MCP: быстрее, проще в настройке, без сети и портов. Подходит для локального использования.

Транспорт и формат обмена:

• Общение по stdin/stdout.
• Формат: JSON-RPC 2.0, построчно или через Content-Length.
  • Построчно — каждое сообщение это одна JSON-строка, разделенная \n. Сервер читает строки и парсит каждую как отдельный JSON-RPC запрос.
  • Через Content-Length — перед сообщением идут заголовки (как в LSP). Сервер сначала читает длину, потом ровно столько байт JSON-тела.

Использовать можно не только из IDE, но и как локальную сервис-утилиту:

• CLI/скрипты: можно запускать сервер и слать ему JSON-RPC из скриптов (например, на CI или для массового прогрева кэша).
• Мост/прокси: stdio удобнее как backend для собственного HTTP-прокси — он проще, чем держать внутри сервера HTTP-слой.
• Интеграции: другой агент/процесс может общаться с MCP через pipe/stdin-stdout, без открытого порта.
• Безопасность: нет открытых портов, меньше требований к сетевой конфигурации.

Примеры stdio-запросов

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
        "name": "search_docs",
        "arguments": {
            "query": "Performance Enhancement"
        }
    }
}

HTTP-режим

http — режим, в котором MCP-сервер поднимает HTTP-endpoint и принимает запросы по сети. Удобно для внешних клиентов и инструментов (например, HTTPYac), но требует поднять отдельный процесс и порт.

• Сервер поднимается командой npm run start:http (порт HTTP_PORT, по умолчанию 3333).
• Каждый инструмент доступен через POST /tools/{toolName} с JSON-телом аргументов.
• Для проверки доступен GET /health.

Примеры HTTP-запросов

Подходят для инструментов типа HTTPYac, плагинов HTTP Request в IDE.

POST http://localhost:3333/tools/search_docs
Content-Type: application/json

{
  "query": "Как работает модуль Performance Enhancement?",
  "limit": 5
}

POST http://localhost:3333/tools/search_docs
Content-Type: application/json

{
  "query": "подключение к DevExpress XAF",
  "limit": 5
}

POST http://localhost:3333/tools/get_page
Content-Type: application/json

{
  "slug": "doc_recursive_helper"
}

POST http://localhost:3333/tools/get_page
Content-Type: application/json

{
  "url": "https://documentation.galaktika-soft.com/xafari/doc_recursive_helper"
}

POST http://localhost:3333/tools/get_examples
Content-Type: application/json

{
  "topic": "Business Components",
  "limit": 5
}

POST http://localhost:3333/tools/explain_concept
Content-Type: application/json

{
  "name": "Security System"
}

Формат хранения

• Сырые страницы сохраняются в data/pages/*.md с метаданными в заголовке.
• pages.json формируется из markdown-файлов после завершения краулинга (по умолчанию это NDJSON: один JSON-объект на строку, чтобы файл можно было читать потоково даже при больших объёмах).
• При сохранении учитываются breadcrumbs: страницы попадают в поддиректории по темам.
• Ассеты (PDF/картинки) сохраняются в data/assets, ссылки в markdown остаются абсолютными.

Ручное пополнение документации

1. Создайте .md в data/pages (подкаталоги = breadcrumbs).
2. Добавьте YAML-front-matter с минимумом полей:

   ---
   slug: my_custom_doc
   url: https://example.local/my_custom_doc
   title: Мой документ
   breadcrumbs:
     - Custom
     - Docs
   ---
   

3. Добавьте тело документа ниже фронт-маттера.
4. Пересоберите индекс без краулинга:
   • npm run reindex

Логи

Структурированные логи пишутся в data/logs/mcp.jsonl (JSON Lines) при DATA_DIR=./data и дефолтном LOG_FILE=logs/mcp.jsonl.