Skip to main content
Glama
lupuletic
by lupuletic

Onyx MCP Server

License: MIT npm version npm downloads PRs Welcome

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 claude

Prerequisites

  • Node.js (v16 or higher)

  • An Onyx instance with API access

  • An Onyx API token

Setup

  1. Clone the repository:

    git clone https://github.com/lupuletic/onyx-mcp-server.git
    cd onyx-mcp-server
  2. Install dependencies:

    npm install
  3. Build the server:

    npm run build
  4. Configure your Onyx API Token:

    export ONYX_API_TOKEN="your-api-token-here"
    export ONYX_API_URL="http://localhost:8080/api"  # Adjust as needed
  5. Start 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_TOKEN and ONYX_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 for

  • documentSets (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 Onyx

  • personaId (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 dev

Committing Changes

This project enforces the Conventional Commits specification for all commit messages. To make this easier, we provide an interactive commit tool:

npm run commit

This 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 build

Testing

Run the test suite:

npm test

Run tests with coverage:

npm run test:coverage

Linting

npm run lint

Fix linting issues:

npm run lint:fix

Continuous 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.

  1. 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

  2. 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 commit for an interactive commit message creation tool

  3. Version Bump Determination: The system analyzes both the PR title and commit messages to determine the appropriate version bump:

    • PR titles starting with feat or containing new features → minor version bump

    • PR titles starting with fix or containing bug fixes → patch version bump

    • PR titles containing BREAKING CHANGE or with an exclamation mark → major version bump

    • If 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

  4. 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 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. Dates show when Glama detected each change.

  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

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

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.
    -

Latest Blog Posts

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