Skip to content

WIP: BYOK via MCP — knowledge-type MCP servers#2920

Draft
onmete wants to merge 1 commit into
openshift:mainfrom
onmete:byok-mcp-knowledge-type
Draft

WIP: BYOK via MCP — knowledge-type MCP servers#2920
onmete wants to merge 1 commit into
openshift:mainfrom
onmete:byok-mcp-knowledge-type

Conversation

@onmete
Copy link
Copy Markdown
Contributor

@onmete onmete commented May 7, 2026

Summary

POC / draft exploring BYOK (Bring Your Own Knowledge) through MCP as an alternative to the current file-based FAISS index approach.

What this adds:

  • type: knowledge on MCPServerConfig — marks an MCP server as a knowledge source
  • retrieval_mode: always — forced retrieval on every query, results injected as RAG context (same pattern as current reference_content)
  • retrieval_mode: on_demand — exposed as regular LLM tool, with knowledge_description augmenting the tool description so the model knows when to use it
  • search_tool, max_chunks, priority — control levers for retrieval behavior
  • POC setup scripts (poc/byok-mcp/) demonstrating the end-to-end flow with Qdrant + mcp-server-qdrant

Config example:

mcp_servers:
  - name: byok-docs
    url: http://qdrant-mcp:8000/mcp/
    type: knowledge
    retrieval_mode: always        # or on_demand
    search_tool: qdrant-find
    knowledge_description: "Company incident response runbooks"
    max_chunks: 5
    priority: 1

What this proves:

  • Customers can bring knowledge via any MCP server — no need for our ingestion pipeline
  • Zero OLS code changes needed for the basic MCP tool path; small, scoped changes for forced/on-demand retrieval modes
  • The architecture supports N knowledge sources, each with its own MCP server and retrieval policy
  • Same MCP server works with other AI tools (Claude, Cursor, etc.) — not locked to OLS

What this does NOT do:

  • Replace the current BYOK file-based approach
  • Ship production-ready code (this is a POC/discussion starter)
  • Include tests (WIP)

Context

Related to the OKP integration proposal (#2914) and ongoing BYOK architecture discussions.

Test plan

  • POC tested locally with Qdrant + mcp-server-qdrant + Sherlock Holmes corpus
  • Unit tests for new config fields
  • Unit tests for retrieve_from_knowledge_mcps
  • Integration test with mock MCP server

Made with Cursor

…retrieval

Add support for MCP servers as knowledge sources (BYOK) with two
retrieval modes:

- `retrieval_mode: always` — forced retrieval on every query, results
  injected as RAG context (like current reference_content pipeline)
- `retrieval_mode: on_demand` — exposed as LLM tool with augmented
  description via knowledge_description config field

Config changes (MCPServerConfig):
- type: tool (default) | knowledge
- retrieval_mode: always | on_demand
- search_tool: which MCP tool to call for retrieval
- knowledge_description: context for on_demand mode
- max_chunks, priority: retrieval control levers

Includes POC setup with Qdrant + mcp-server-qdrant demonstrating
the end-to-end flow.

Co-authored-by: Cursor <cursoragent@cursor.com>
@openshift-ci openshift-ci Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 7, 2026
@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented May 7, 2026

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented May 7, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign blublinsky for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant