MCP with Document Sets

[univeris-copilot]

I think that current MCP server doesn't allow it. We are using Document Sets as a way to "separate knowledge" for agents, for instance We have 2 confluence connectors with different confluence information (via workspace or pages trees) and I can create a document set with ConfluenceA and FIle1 and File2 and a different document set with ConfluenceB and File 3 and File 4 and assign to 2 different agents

My "problem" is that if i want to use Onyx MCP Server capabilities I can select source_types but i would need to be able to select a Documetn Set.

Thanks

[pauldev-hub]

Hi @univeris-copilot ,

The built-in Onyx MCP server only exposes source_types as a filter — Document Sets are not supported natively yet. But there's a working workaround.

Root cause

The official Onyx MCP server's search tool currently maps to the /search API endpoint which accepts source_types but doesn't pass document_set_names as a filter parameter in its tool schema.
Workaround — use the community MCP server

The lupuletic/onyx-mcp-server already supports documentSets as a first-class parameter in both search_onyx and chat_with_onyx: (GitHub)
{
"query": "your query",
"documentSets": ["ConfluenceA-Set", "ConfluenceB-Set"],
"maxResults": 5
}

Install it via:
npx -y @smithery/cli install @lupuletic/onyx-mcp-server --client claude

For your specific use case — 2 agents with isolated Document Sets
Run two separate MCP server instances, each scoped to a different Document Set by hardcoding the documentSets value in the tool call per agent.

This gives you clean knowledge isolation without cross-contamination between ConfluenceA and ConfluenceB data.
For the official Onyx MCP — open a feature request
The /api/search endpoint already supports document_set_names in its payload. This is purely a missing parameter exposure in the MCP tool schema — a small PR would fix it.