onyx-mcp-server
Hosted on GitHub with contribution guidelines and continuous integration through GitHub Actions
Runs as a Node.js-based MCP server to connect Onyx knowledge bases to MCP clients, enabling document search and retrieval functionality
Available as an npm package for easy installation and integration with Onyx knowledge bases
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@onyx-mcp-serversearch for customer onboarding documentation in our training materials"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Onyx MCP Server
A Model Context Protocol (MCP) server for seamless integration with Onyx AI knowledge bases.
This MCP server connects any MCP-compatible client to your Onyx knowledge base, allowing you to search and retrieve relevant context from your documents. It provides a bridge between MCP clients and the Onyx API, enabling powerful semantic search and chat capabilities.
Features
Enhanced Search: Semantic search across your Onyx document sets with LLM relevance filtering
Context Window Retrieval: Retrieve chunks above and below the matching chunk for better context
Full Document Retrieval: Option to retrieve entire documents instead of just chunks
Chat Integration: Use Onyx's powerful chat API with LLM + RAG for comprehensive answers
Configurable Document Set Filtering: Target specific document sets for more relevant results
Related MCP server: atlas_mcp
Installation
Installing via Smithery
To install Onyx MCP Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @lupuletic/onyx-mcp-server --client claudePrerequisites
Node.js (v16 or higher)
An Onyx instance with API access
An Onyx API token
Setup
Clone the repository:
git clone https://github.com/lupuletic/onyx-mcp-server.git cd onyx-mcp-serverInstall dependencies:
npm installBuild the server:
npm run buildConfigure your Onyx API Token:
export ONYX_API_TOKEN="your-api-token-here" export ONYX_API_URL="http://localhost:8080/api" # Adjust as neededStart the server:
npm start
Configuring MCP Clients
For Claude Desktop App
Add to ~/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": []
}
}
}For Claude in VSCode (Cline)
Add to your Cline MCP settings file:
{
"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": []
}
}
}For Other MCP Clients
Consult your MCP client's documentation for how to add a custom MCP server. You'll need to provide:
The command to run the server (
node)The path to the built server file (
/path/to/onyx-mcp-server/build/index.js)Environment variables for
ONYX_API_TOKENandONYX_API_URL
Available Tools
Once configured, your MCP client will have access to two powerful tools:
1. Search Tool
The search_onyx tool provides direct access to Onyx's search capabilities with enhanced context retrieval:
<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>Parameters:
query(required): The topic to search fordocumentSets(optional): List of document set names to search within (empty for all)maxResults(optional): Maximum number of results to return (default: 5, max: 10)chunksAbove(optional): Number of chunks to include above the matching chunk (default: 1)chunksBelow(optional): Number of chunks to include below the matching chunk (default: 1)retrieveFullDocuments(optional): Whether to retrieve full documents instead of just chunks (default: false)
2. Chat Tool
The chat_with_onyx tool leverages Onyx's powerful chat API with LLM + RAG for comprehensive answers:
<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>Parameters:
query(required): The question to ask OnyxpersonaId(optional): The ID of the persona to use (default: 15)documentSets(optional): List of document set names to search within (empty for all)chatSessionId(optional): Existing chat session ID to continue a conversation
Chat Sessions
The chat tool supports maintaining conversation context across multiple interactions. After the first call, the response will include a chat_session_id in the metadata. You can pass this ID in subsequent calls to maintain context.
Choosing Between Search and Chat
Use Search When: You need specific, targeted information from documents and want to control exactly how much context is retrieved.
Use Chat When: You need comprehensive answers that combine information from multiple sources, or when you want the LLM to synthesize information for you.
For the best results, you can use both tools in combination - search for specific details and chat for comprehensive understanding.
Use Cases
Knowledge Management: Access your organization's knowledge base through any MCP-compatible interface
Customer Support: Help support agents quickly find relevant information
Research: Conduct deep research across your organization's documents
Training: Provide access to training materials and documentation
Policy Compliance: Ensure teams have access to the latest policies and procedures
Development
Running in Development Mode
npm run devCommitting Changes
This project enforces the Conventional Commits specification for all commit messages. To make this easier, we provide an interactive commit tool:
npm run commitThis will guide you through creating a properly formatted commit message. Alternatively, you can write your own commit messages following the conventional format:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]Where type is one of: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
Building for Production
npm run buildTesting
Run the test suite:
npm testRun tests with coverage:
npm run test:coverageLinting
npm run lintFix linting issues:
npm run lint:fixContinuous Integration
This project uses GitHub Actions for continuous integration and deployment. The CI pipeline runs on every push to the main branch and on pull requests. It performs the following checks:
Linting
Building
Testing
Code coverage reporting
Automated Version Bumping and Publishing
When a PR is merged to the main branch, the project automatically determines the appropriate version bump type and publishes to npm. The system analyzes both PR titles and commit messages to determine the version bump type.
PR Title Validation: All PR titles are validated against the Conventional Commits specification:
PR titles must start with a type (e.g.,
feat:,fix:,docs:)This validation happens automatically when a PR is created or updated
PRs with invalid titles will fail the validation check
Commit Message Validation: All commit messages are also validated against the conventional commits format:
Commit messages must start with a type (e.g.,
feat:,fix:,docs:)This is enforced by git hooks that run when you commit
Commits with invalid messages will be rejected
Use
npm run commitfor an interactive commit message creation tool
Version Bump Determination: The system analyzes both the PR title and commit messages to determine the appropriate version bump:
PR titles starting with
feator containing new features → minor version bumpPR titles starting with
fixor containing bug fixes → patch version bumpPR titles containing
BREAKING CHANGEor with an exclamation mark → major version bumpIf the PR title doesn't indicate a specific bump type, the system analyzes commit messages
The highest priority bump type found in any commit message is used (major > minor > patch)
If no conventional commit prefixes are found, the system automatically defaults to a patch version bump without failing
Version Update and Publishing:
Bumps the version in package.json according to semantic versioning
Commits and pushes the version change
Publishes the new version to npm
This automated process ensures consistent versioning based on the nature of the changes, following semantic versioning principles, and eliminates manual version management.
Contributing
Contributions are welcome! Please see our Contributing Guide for more details.
Security
If you discover a security vulnerability, please follow our Security Policy.
License
This project is licensed under the MIT License - see the LICENSE file for details.
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. Dates show when Glama detected each change.
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
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
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.-
- FlicenseNot gradedqualityCmaintenanceEnables querying company knowledge base using RAG, providing accurate answers from internal documents via MCP.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lupuletic/onyx-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server