onyx-mcp-server
Сервер Onyx MCP
Сервер протокола контекста модели (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
Настраивать
Клонируйте репозиторий:
git clone https://github.com/lupuletic/onyx-mcp-server.git cd onyx-mcp-serverУстановить зависимости:
npm installСборка сервера:
npm run buildНастройте свой токен API Onyx:
export ONYX_API_TOKEN="your-api-token-here" export ONYX_API_URL="http://localhost:8080/api" # Adjust as neededЗапустите сервер:
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.
Проверка заголовка PR : Все заголовки PR проверяются на соответствие спецификации Conventional Commits :
Заголовки PR должны начинаться с типа (например,
feat:,fix:,docs:)Эта проверка происходит автоматически при создании или обновлении PR.
PR с недействительными названиями не пройдут проверку.
Проверка сообщения о коммите : Все сообщения о коммитах также проверяются на соответствие общепринятому формату коммитов:
Сообщения о коммитах должны начинаться с типа (например,
feat:,fix:,docs:)Это обеспечивается хуками git, которые запускаются при коммите.
Коммиты с недействительными сообщениями будут отклонены.
Используйте
npm run commitдля интерактивного инструмента создания сообщений о коммите
Определение повышения версии : система анализирует как заголовок PR, так и сообщения о фиксации, чтобы определить соответствующую повышение версии:
PR-титулы, начинающиеся с
featили содержащие новые функции → повышение младшей версииЗаголовки PR, начинающиеся с
fixили содержащие исправления ошибок → повышение версии патчаЗаголовки PR, содержащие
BREAKING CHANGEили восклицательный знак → обновление основной версииЕсли заголовок PR не указывает на конкретный тип повышения, система анализирует сообщения о коммитах
Используется тип исправления с наивысшим приоритетом, найденный в любом сообщении о фиксации (основной > второстепенный > исправление).
Если не найдено ни одного обычного префикса для фиксации, система автоматически переходит к версии исправления по умолчанию без сбоев.
Обновление и публикация версии :
Увеличивает версию в package.json в соответствии с семантическим версионированием
Фиксирует и отправляет изменение версии
Публикует новую версию в npm
Этот автоматизированный процесс обеспечивает единообразное управление версиями на основе характера изменений, следуя принципам семантического управления версиями, и исключает ручное управление версиями.
Внося вклад
Вклады приветствуются! Более подробную информацию см. в нашем Руководстве по вкладам .
Безопасность
Если вы обнаружили уязвимость системы безопасности, следуйте нашей Политике безопасности .
Лицензия
Данный проект лицензирован по лицензии MIT — подробности см. в файле LICENSE .
Available Tools
2 toolschat_with_onyxC
Chat with Onyx to get comprehensive answers
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The question to ask Onyx | |
| personaId | No | The ID of the persona to use (default: 15) | |
| chatSessionId | No | Existing chat session ID to continue a conversation (optional) | |
| documentSets | No | List of document set names to search within (empty for all) | |
| enableAutoDetectFilters | No | Whether to enable auto-detection of filters (default: true) |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The topic to search for | |
| chunksAbove | No | Number of chunks to include above the matching chunk (default: 1) | |
| chunksBelow | No | Number of chunks to include below the matching chunk (default: 1) | |
| retrieveFullDocuments | No | Whether to retrieve full documents instead of just matching chunks (default: false) | |
| documentSets | No | List of document set names to search within (empty for all) | |
| maxResults | No | Maximum number of results to return (default: 5) |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
- First observed
chat_with_onyx - First observed
search_onyx
TDQS
Scored across 2 tools
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.
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.
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.
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
Related MCP Connectors
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Let AI agents query data and act across all your business apps via MCP.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables 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.-
- AlicenseNot gradedqualityDmaintenanceAn MCP server that brings AI-powered search and conversation to your FHIR clinical documents.1MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to intelligently search and reference documentation using hybrid semantic + keyword search via MCP protocol.-
- AlicenseNot gradedqualityCmaintenanceEnables document ingestion, semantic search, and retrieval-augmented generation via MCP tools and REST API, using vector embeddings and intelligent chunking.MIT