You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
list_taxonomy_items/get_taxonomy_item/TieredWikiSearch (#258/#259) and their CLI
exposure (openkb list-taxonomy/openkb search, #260/#261) require either running inside
the OpenKB Python process or shelling out to the openkb CLI. Modern AI coding assistants
(GitHub Copilot, Claude Code, Cursor, etc.) increasingly support the Model Context Protocol
(MCP) as their preferred way to call structured, typed tools — an MCP server would let any
MCP-capable assistant browse the taxonomy and run the tiered search directly, without
needing a CLI wrapper, shell access, or Node.js/the Workbench web UI.
Kontext
mcp==1.27.1 is already an installed, resolved dependency — transitively, via openai-agents (see PR chore: bump openai-agents to 0.19.0 and openai to 2.48.0 #207, which bumped openai-agents for MCP Python SDK v2 client
support: MCPServerStdio/MCPServerStreamableHttp). It already provides mcp.server.fastmcp.FastMCP, a minimal decorator-based MCP server API. This issue is
therefore not proposing a new dependency, just an explicit top-level pin
(pyproject.toml) formalizing what's already vetted and present, plus a small new module
using it.
Vorschlag
New module (e.g. openkb/mcp_server.py) exposing list_taxonomy and search_wiki as
MCP tools, built on the same core functions the CLI/agent already use
(agent.tools.list_taxonomy_items/get_taxonomy_item, fulltext_index.TieredWikiSearch).
No index cache: the underlying index is rebuilt fresh on every tool call, exactly like
the CLI and agent do today — deliberately, since OpenKB has no long-running daemon
concept today and caching would risk staleness if the KB changes in a separate openkb add invocation while the MCP server process stays alive.
New CLI entry point (e.g. openkb-mcp) in pyproject.toml to launch the server (stdio
transport) for use from an MCP-capable client's config.
This issue was drafted with the assistance of an AI assistant.
Problem
list_taxonomy_items/get_taxonomy_item/TieredWikiSearch(#258/#259) and their CLIexposure (
openkb list-taxonomy/openkb search, #260/#261) require either running insidethe OpenKB Python process or shelling out to the
openkbCLI. Modern AI coding assistants(GitHub Copilot, Claude Code, Cursor, etc.) increasingly support the Model Context Protocol
(MCP) as their preferred way to call structured, typed tools — an MCP server would let any
MCP-capable assistant browse the taxonomy and run the tiered search directly, without
needing a CLI wrapper, shell access, or Node.js/the Workbench web UI.
Kontext
mcp==1.27.1is already an installed, resolved dependency — transitively, viaopenai-agents(see PR chore: bump openai-agents to 0.19.0 and openai to 2.48.0 #207, which bumpedopenai-agentsfor MCP Python SDK v2 clientsupport:
MCPServerStdio/MCPServerStreamableHttp). It already providesmcp.server.fastmcp.FastMCP, a minimal decorator-based MCP server API. This issue istherefore not proposing a new dependency, just an explicit top-level pin
(
pyproject.toml) formalizing what's already vetted and present, plus a small new moduleusing it.
Vorschlag
openkb/mcp_server.py) exposinglist_taxonomyandsearch_wikiasMCP tools, built on the same core functions the CLI/agent already use
(
agent.tools.list_taxonomy_items/get_taxonomy_item,fulltext_index.TieredWikiSearch).the CLI and agent do today — deliberately, since OpenKB has no long-running daemon
concept today and caching would risk staleness if the KB changes in a separate
openkb addinvocation while the MCP server process stays alive.openkb-mcp) inpyproject.tomlto launch the server (stdiotransport) for use from an MCP-capable client's config.
This issue was drafted with the assistance of an AI assistant.