Skip to main content
Glama
lupuletic
by lupuletic

Сервер Onyx MCP

Лицензия: Массачусетский технологический институт npm-версия npm-загрузки значок кузнеца PR-сотрудники приветствуются

Сервер протокола контекста модели (MCP) для бесшовной интеграции с базами знаний Onyx AI.

Этот сервер MCP подключает любой клиент, совместимый с MCP, к вашей базе знаний Onyx, позволяя вам искать и извлекать соответствующий контекст из ваших документов. Он обеспечивает мост между клиентами MCP и API Onyx, обеспечивая мощные возможности семантического поиска и чата.

Функции

  • Расширенный поиск : семантический поиск по всем наборам документов Onyx с фильтрацией по релевантности LLM

  • Извлечение контекстного окна : извлечение фрагментов выше и ниже соответствующего фрагмента для лучшего контекста.

  • Извлечение всего документа : возможность извлечения целых документов, а не только их частей.

  • Интеграция чата : используйте мощный API чата Onyx с LLM + RAG для получения исчерпывающих ответов

  • Настраиваемая фильтрация наборов документов : выбор определенных наборов документов для получения более релевантных результатов.

Related MCP server: atlas_mcp

Установка

Установка через Smithery

Чтобы автоматически установить Onyx MCP Server для Claude Desktop через Smithery :

npx -y @smithery/cli install @lupuletic/onyx-mcp-server --client claude

Предпосылки

  • Node.js (v16 или выше)

  • Экземпляр Onyx с доступом к API

  • Токен API Onyx

Настраивать

  1. Клонируйте репозиторий:

    git clone https://github.com/lupuletic/onyx-mcp-server.git
    cd onyx-mcp-server
  2. Установить зависимости:

    npm install
  3. Сборка сервера:

    npm run build
  4. Настройте свой токен API Onyx:

    export ONYX_API_TOKEN="your-api-token-here"
    export ONYX_API_URL="http://localhost:8080/api"  # Adjust as needed
  5. Запустите сервер:

    npm start

Настройка клиентов MCP

Для приложения Claude Desktop

Добавьте в ~/Library/Application Support/Claude/claude_desktop_config.json :

{
  "mcpServers": {
    "onyx-search": {
      "command": "node",
      "args": ["/path/to/onyx-mcp-server/build/index.js"],
      "env": {
        "ONYX_API_TOKEN": "your-api-token-here",
        "ONYX_API_URL": "http://localhost:8080/api"
      },
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

Для Клода в VSCode (Cline)

Добавьте в файл настроек Cline MCP:

{
  "mcpServers": {
    "onyx-search": {
      "command": "node",
      "args": ["/path/to/onyx-mcp-server/build/index.js"],
      "env": {
        "ONYX_API_TOKEN": "your-api-token-here",
        "ONYX_API_URL": "http://localhost:8080/api"
      },
      "disabled": false, 
      "alwaysAllow": []
    }
  }
}

Для других клиентов MCP

Обратитесь к документации вашего клиента MCP, чтобы узнать, как добавить пользовательский сервер MCP. Вам нужно будет предоставить:

  • Команда для запуска сервера ( node )

  • Путь к файлу собранного сервера ( /path/to/onyx-mcp-server/build/index.js )

  • Переменные среды для ONYX_API_TOKEN и ONYX_API_URL

Доступные инструменты

После настройки ваш клиент MCP получит доступ к двум мощным инструментам:

1. Инструмент поиска

Инструмент search_onyx обеспечивает прямой доступ к возможностям поиска Onyx с улучшенным контекстным поиском:

<use_mcp_tool>
<server_name>onyx-search</server_name>
<tool_name>search_onyx</tool_name>
<arguments>
{
  "query": "customer onboarding process",
  "documentSets": ["Company Policies", "Training Materials"],
  "maxResults": 3,
  "chunksAbove": 1,
  "chunksBelow": 1,
  "retrieveFullDocuments": true
}
</arguments>
</use_mcp_tool>

Параметры:

  • query (обязательно): Тема для поиска

  • documentSets (необязательно): список названий наборов документов для поиска (пусто для всех)

  • maxResults (необязательно): максимальное количество возвращаемых результатов (по умолчанию: 5, максимум: 10)

  • chunksAbove (необязательно): количество фрагментов, которые следует включить выше соответствующего фрагмента (по умолчанию: 1)

  • chunksBelow (необязательно): количество фрагментов, которые следует включить под соответствующим фрагментом (по умолчанию: 1)

  • retrieveFullDocuments (необязательно): следует ли извлекать полные документы, а не только фрагменты (по умолчанию: false)

2. Инструмент чата

Инструмент chat_with_onyx использует мощный API чата Onyx с LLM + RAG для получения исчерпывающих ответов:

<use_mcp_tool>
<server_name>onyx-search</server_name>
<tool_name>chat_with_onyx</tool_name>
<arguments>
{
  "query": "What is our company's policy on remote work?",
  "personaId": 15,
  "documentSets": ["Company Policies", "HR Documents"],
  "chatSessionId": "optional-existing-session-id"
}
</arguments>
</use_mcp_tool>

Параметры:

  • query (обязательно): Вопрос, который нужно задать Ониксу

  • personaId (необязательно): идентификатор персоны для использования (по умолчанию: 15)

  • documentSets (необязательно): список названий наборов документов для поиска (пусто для всех)

  • chatSessionId (необязательно): существующий идентификатор сеанса чата для продолжения разговора

Чат-сессии

Инструмент чата поддерживает сохранение контекста разговора в нескольких взаимодействиях. После первого вызова ответ будет включать chat_session_id в метаданных. Вы можете передавать этот идентификатор в последующих вызовах для сохранения контекста.

Выбор между поиском и чатом

  • Используйте поиск, когда : вам нужна конкретная, целевая информация из документов, и вы хотите точно контролировать объем извлекаемого контекста.

  • Используйте чат, когда : Вам нужны исчерпывающие ответы, объединяющие информацию из нескольких источников, или когда вы хотите, чтобы LLM синтезировал информацию для вас.

Для достижения наилучших результатов вы можете использовать оба инструмента одновременно — ищите конкретные детали и общайтесь в чате для получения всестороннего понимания.

Варианты использования

  • Управление знаниями : доступ к базе знаний вашей организации через любой совместимый с MCP интерфейс.

  • Поддержка клиентов : помогите агентам службы поддержки быстро найти нужную информацию.

  • Исследование : проведите глубокое исследование документов вашей организации.

  • Обучение : Предоставить доступ к учебным материалам и документации.

  • Соблюдение политик : обеспечьте командам доступ к последним политикам и процедурам.

Разработка

Работа в режиме разработки

npm run dev

Внесение изменений

Этот проект обеспечивает спецификацию Conventional Commits для всех сообщений о коммитах. Чтобы сделать это проще, мы предоставляем интерактивный инструмент для коммитов:

npm run commit

Это поможет вам создать правильно отформатированное сообщение о коммите. В качестве альтернативы вы можете написать свои собственные сообщения о коммите, следуя общепринятому формату:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Где type может быть одним из: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert

Здание для производства

npm run build

Тестирование

Запустите тестовый набор:

npm test

Запустите тесты с покрытием:

npm run test:coverage

Линтинг

npm run lint

Исправление проблем с линтингом:

npm run lint:fix

Непрерывная интеграция

Этот проект использует GitHub Actions для непрерывной интеграции и развертывания. CI-конвейер запускается при каждом push-е в основную ветку и при pull-запросах. Он выполняет следующие проверки:

  • Линтинг

  • Здание

  • Тестирование

  • Отчетность о покрытии кода

Автоматизированное обновление и публикация версий

Когда PR объединяется с основной веткой, проект автоматически определяет соответствующий тип версии bump и публикует в npm. Система анализирует как заголовки PR, так и сообщения о коммитах, чтобы определить тип версии bump.

  1. Проверка заголовка PR : Все заголовки PR проверяются на соответствие спецификации Conventional Commits :

    • Заголовки PR должны начинаться с типа (например, feat: , fix: , docs: )

    • Эта проверка происходит автоматически при создании или обновлении PR.

    • PR с недействительными названиями не пройдут проверку.

  2. Проверка сообщения о коммите : Все сообщения о коммитах также проверяются на соответствие общепринятому формату коммитов:

    • Сообщения о коммитах должны начинаться с типа (например, feat: , fix: , docs: )

    • Это обеспечивается хуками git, которые запускаются при коммите.

    • Коммиты с недействительными сообщениями будут отклонены.

    • Используйте npm run commit для интерактивного инструмента создания сообщений о коммите

  3. Определение повышения версии : система анализирует как заголовок PR, так и сообщения о фиксации, чтобы определить соответствующую повышение версии:

    • PR-титулы, начинающиеся с feat или содержащие новые функции → повышение младшей версии

    • Заголовки PR, начинающиеся с fix или содержащие исправления ошибок → повышение версии патча

    • Заголовки PR, содержащие BREAKING CHANGE или восклицательный знак → обновление основной версии

    • Если заголовок PR не указывает на конкретный тип повышения, система анализирует сообщения о коммитах

    • Используется тип исправления с наивысшим приоритетом, найденный в любом сообщении о фиксации (основной > второстепенный > исправление).

    • Если не найдено ни одного обычного префикса для фиксации, система автоматически переходит к версии исправления по умолчанию без сбоев.

  4. Обновление и публикация версии :

    • Увеличивает версию в package.json в соответствии с семантическим версионированием

    • Фиксирует и отправляет изменение версии

    • Публикует новую версию в npm

Этот автоматизированный процесс обеспечивает единообразное управление версиями на основе характера изменений, следуя принципам семантического управления версиями, и исключает ручное управление версиями.

Внося вклад

Вклады приветствуются! Более подробную информацию см. в нашем Руководстве по вкладам .

Безопасность

Если вы обнаружили уязвимость системы безопасности, следуйте нашей Политике безопасности .

Лицензия

Данный проект лицензирован по лицензии MIT — подробности см. в файле LICENSE .

Available Tools

2 tools
chat_with_onyxC

Chat with Onyx to get comprehensive answers

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe question to ask Onyx
personaIdNoThe ID of the persona to use (default: 15)
chatSessionIdNoExisting chat session ID to continue a conversation (optional)
documentSetsNoList of document set names to search within (empty for all)
enableAutoDetectFiltersNoWhether to enable auto-detection of filters (default: true)

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'comprehensive answers' but fails to describe key traits such as whether this is a read-only operation, if it requires authentication, rate limits, or how chat sessions are managed. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, clearly stating the tool's core function without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a chat tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It does not explain return values, error handling, or how the tool integrates with the sibling 'search_onyx', leaving the agent with insufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or their practical use. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as 'Chat with Onyx to get comprehensive answers', which identifies the action (chat) and resource (Onyx) but is vague about what distinguishes it from the sibling tool 'search_onyx'. It lacks specificity on how chatting differs from searching, leaving the purpose unclear in context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the sibling 'search_onyx'. The description does not mention alternatives, exclusions, or contextual usage, leaving the agent without direction on tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_onyxC

Search the Onyx backend for relevant documents

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe topic to search for
chunksAboveNoNumber of chunks to include above the matching chunk (default: 1)
chunksBelowNoNumber of chunks to include below the matching chunk (default: 1)
retrieveFullDocumentsNoWhether to retrieve full documents instead of just matching chunks (default: false)
documentSetsNoList of document set names to search within (empty for all)
maxResultsNoMaximum number of results to return (default: 5)

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching for 'relevant documents' but doesn't describe what constitutes relevance, how results are ranked, whether there are rate limits, authentication requirements, or what the output format looks like. For a search tool with 6 parameters and no annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with a clear primary function and is front-loaded with the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what 'relevant' means, how results are returned, or provide any behavioral context. For a search tool that likely returns structured data, more completeness is needed to help an agent use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain how 'chunksAbove' and 'chunksBelow' work together or what 'documentSets' represent). Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search') and target ('the Onyx backend for relevant documents'), providing a specific verb+resource combination. However, it doesn't differentiate from its sibling tool 'chat_with_onyx', which appears to be a related but distinct functionality, so it doesn't fully distinguish from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the sibling 'chat_with_onyx' or any other alternatives. It lacks context about appropriate use cases, exclusions, or prerequisites, offering only a basic functional statement without usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • First observedchat_with_onyx
    • First observedsearch_onyx

TDQS

C2.9/5.0

Scored across 2 tools

Disambiguation4/5

The two tools have distinct purposes: one is for interactive chat to get answers, and the other is for searching documents. While both involve querying the Onyx backend, the descriptions clarify that 'chat_with_onyx' provides comprehensive answers through conversation, whereas 'search_onyx' focuses on retrieving relevant documents, reducing ambiguity. However, an agent might still confuse them if the distinction between 'answers' and 'documents' is not clear in practice.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern with 'chat_with_onyx' and 'search_onyx', using snake_case throughout. The naming is predictable and readable, with no deviations or mixed conventions, making it easy for agents to understand the action and target.

Tool Count2/5

With only 2 tools, the server feels thin for a general-purpose 'onyx-mcp-server', as it likely covers a limited scope of interaction with the Onyx backend. This minimal set may not support complex workflows or comprehensive operations, suggesting an under-scoped tool surface that could hinder agent capabilities.

Completeness2/5

Inferring the domain as interacting with the Onyx backend, the tool set has significant gaps. It lacks CRUD operations (e.g., create, update, delete documents), management functions, or advanced querying beyond basic search and chat. This incomplete coverage will likely cause agent failures when tasks require more than simple retrieval or conversation.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI applications to access and contextualize organizational knowledge sources including GitHub repositories and internal documentation through standardized MCP protocol integration. Features OAuth 2.1 authentication, vector-based semantic search, and optimized context chunking for enterprise development workflows.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to intelligently search and reference documentation using hybrid semantic + keyword search via MCP protocol.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables document ingestion, semantic search, and retrieval-augmented generation via MCP tools and REST API, using vector embeddings and intelligent chunking.
    MIT