onyx-mcp-server
Servidor MCP de Onyx
Un servidor de Protocolo de Contexto de Modelo (MCP) para una integración perfecta con las bases de conocimiento de Onyx AI.
Este servidor MCP conecta cualquier cliente compatible con MCP a su base de conocimientos de Onyx, lo que le permite buscar y recuperar contexto relevante de sus documentos. Proporciona un puente entre los clientes MCP y la API de Onyx, lo que permite potentes funciones de búsqueda semántica y chat.
Características
Búsqueda mejorada : Búsqueda semántica en sus conjuntos de documentos Onyx con filtrado de relevancia LLM
Recuperación de ventana de contexto : recupera fragmentos por encima y por debajo del fragmento coincidente para un mejor contexto
Recuperación completa de documentos : opción para recuperar documentos completos en lugar de solo fragmentos
Integración de chat : utilice la potente API de chat de Onyx con LLM + RAG para obtener respuestas completas
Filtrado de conjuntos de documentos configurables : seleccione conjuntos de documentos específicos para obtener resultados más relevantes
Related MCP server: atlas_mcp
Instalación
Instalación mediante herrería
Para instalar Onyx MCP Server para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @lupuletic/onyx-mcp-server --client claudePrerrequisitos
Node.js (v16 o superior)
Una instancia de Onyx con acceso a API
Un token API de Onyx
Configuración
Clonar el repositorio:
git clone https://github.com/lupuletic/onyx-mcp-server.git cd onyx-mcp-serverInstalar dependencias:
npm installConstruir el servidor:
npm run buildConfigura tu token API de Onyx:
export ONYX_API_TOKEN="your-api-token-here" export ONYX_API_URL="http://localhost:8080/api" # Adjust as neededIniciar el servidor:
npm start
Configuración de clientes MCP
Para la aplicación de escritorio de Claude
Agregar a ~/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": []
}
}
}Para Claude en VSCode (Cline)
Agregue a su archivo de configuración de 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": []
}
}
}Para otros clientes de MCP
Consulta la documentación de tu cliente MCP para saber cómo agregar un servidor MCP personalizado. Necesitarás proporcionar:
El comando para ejecutar el servidor (
node)La ruta al archivo del servidor creado (
/path/to/onyx-mcp-server/build/index.js)Variables de entorno para
ONYX_API_TOKENyONYX_API_URL
Herramientas disponibles
Una vez configurado, su cliente MCP tendrá acceso a dos potentes herramientas:
1. Herramienta de búsqueda
La herramienta search_onyx proporciona acceso directo a las capacidades de búsqueda de Onyx con recuperación de contexto mejorada:
<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>Parámetros:
query(obligatoria): El tema a buscardocumentSets(opcional): lista de nombres de conjuntos de documentos para buscar (vacío para todos)maxResults(opcional): Número máximo de resultados a devolver (predeterminado: 5, máximo: 10)chunksAbove(opcional): Número de fragmentos a incluir encima del fragmento correspondiente (predeterminado: 1)chunksBelow(opcional): Número de fragmentos a incluir debajo del fragmento correspondiente (predeterminado: 1)retrieveFullDocuments(opcional): si se deben recuperar documentos completos en lugar de solo fragmentos (valor predeterminado: falso)
2. Herramienta de chat
La herramienta chat_with_onyx aprovecha la potente API de chat de Onyx con LLM + RAG para obtener respuestas completas:
<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>Parámetros:
query(obligatoria): La pregunta que debes hacerle a OnyxpersonaId(opcional): El ID de la persona a utilizar (predeterminado: 15)documentSets(opcional): lista de nombres de conjuntos de documentos para buscar (vacío para todos)chatSessionId(opcional): ID de sesión de chat existente para continuar una conversación
Sesiones de chat
La herramienta de chat permite mantener el contexto de la conversación en múltiples interacciones. Tras la primera llamada, la respuesta incluirá un chat_session_id en los metadatos. Puedes pasar este ID en llamadas posteriores para mantener el contexto.
Elegir entre búsqueda y chat
Utilice la búsqueda cuando : necesite información específica y dirigida de los documentos y desee controlar exactamente cuánto contexto se recupera.
Utilice el chat cuando : necesite respuestas completas que combinen información de múltiples fuentes o cuando desee que el LLM sintetice la información para usted.
Para obtener mejores resultados, puede utilizar ambas herramientas en combinación: buscar detalles específicos y chatear para obtener una comprensión completa.
Casos de uso
Gestión del conocimiento : acceda a la base de conocimientos de su organización a través de cualquier interfaz compatible con MCP
Atención al cliente : Ayude a los agentes de soporte a encontrar rápidamente información relevante
Investigación : Realice una investigación profunda de los documentos de su organización.
Capacitación : Proporcionar acceso a materiales de capacitación y documentación.
Cumplimiento de políticas : garantizar que los equipos tengan acceso a las políticas y procedimientos más recientes
Desarrollo
Ejecutando en modo de desarrollo
npm run devConfirmando cambios
Este proyecto aplica la especificación de confirmaciones convencionales a todos los mensajes de confirmación. Para facilitarlo, ofrecemos una herramienta interactiva de confirmación:
npm run commitEsto te guiará en la creación de un mensaje de confirmación con el formato correcto. Como alternativa, puedes escribir tus propios mensajes de confirmación siguiendo el formato convencional:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]Donde type es uno de los siguientes: hazaña, corrección, documentación, estilo, refactorización, rendimiento, prueba, compilación, ci, tarea, reversión
Edificio para la producción
npm run buildPruebas
Ejecute el conjunto de pruebas:
npm testEjecutar pruebas con cobertura:
npm run test:coveragePelusa
npm run lintSolucionar problemas de pelusa:
npm run lint:fixIntegración continua
Este proyecto utiliza GitHub Actions para la integración y el despliegue continuos. La canalización de CI se ejecuta con cada envío a la rama principal y con las solicitudes de extracción. Realiza las siguientes comprobaciones:
Pelusa
Edificio
Pruebas
Informes de cobertura de código
Aumento y publicación de versiones automatizadas
Cuando un PR se fusiona con la rama principal, el proyecto determina automáticamente el tipo de actualización de versión adecuado y lo publica en npm. El sistema analiza tanto los títulos del PR como los mensajes de confirmación para determinar el tipo de actualización de versión.
Validación del título de PR : todos los títulos de PR se validan según la especificación de confirmaciones convencionales :
Los títulos de PR deben comenzar con un tipo (por ejemplo,
feat:,fix:,docs:)Esta validación ocurre automáticamente cuando se crea o actualiza un PR
Las solicitudes de relaciones públicas con títulos no válidos no pasarán la comprobación de validación
Validación de mensajes de confirmación : todos los mensajes de confirmación también se validan con el formato de confirmación convencional:
Los mensajes de confirmación deben comenzar con un tipo (por ejemplo,
feat:,fix:,docs:)Esto se aplica mediante ganchos git que se ejecutan cuando se confirma.
Las confirmaciones con mensajes no válidos serán rechazadas.
Utilice
npm run commitpara una herramienta interactiva de creación de mensajes de confirmación
Determinación de aumento de versión : el sistema analiza tanto el título de la PR como los mensajes de confirmación para determinar el aumento de versión adecuado:
Títulos de relaciones públicas que comienzan con
feato que contienen nuevas características → aumento de versión menorTítulos de relaciones públicas que comienzan con
fixo que contienen correcciones de errores → actualización de la versión del parcheTítulos de relaciones públicas que contienen
BREAKING CHANGEo con un signo de exclamación → aumento de versión principalSi el título de PR no indica un tipo de confirmación específico, el sistema analiza los mensajes de confirmación.
Se utiliza el tipo de actualización con mayor prioridad que se encuentre en cualquier mensaje de confirmación (mayor > menor > parche)
Si no se encuentran prefijos de confirmación convencionales, el sistema pasa automáticamente a una actualización de la versión del parche sin fallar.
Actualización y publicación de la versión :
Aumenta la versión en package.json según el control de versiones semántico
Confirma y envía el cambio de versión
Publica la nueva versión en npm
Este proceso automatizado garantiza un control de versiones consistente según la naturaleza de los cambios, siguiendo los principios de control de versiones semántico y elimina la gestión manual de versiones.
Contribuyendo
¡Agradecemos sus contribuciones! Consulte nuestra Guía de Contribución para más detalles.
Seguridad
Si descubre una vulnerabilidad de seguridad, siga nuestra Política de seguridad .
Licencia
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
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