Problem
The store today exposes a single MCP endpoint: the full MCP at /control_sse, auto-generated from every FastAPI route by fastapi-mcp. That surface is ~40 tools with HTTP-style machine names (e.g. list_tools_tools_get) and includes a lot of operations an agent should not be handed — admin/health/broken-state/tool-health endpoints, dependency-management routes, etc. It's too token-heavy and too broad for agents that struggle with large tool lists.
We need a smaller, curated MCP that exposes only the handful of tools an agent actually needs, with clean LLM-friendly names — not everything the REST API happens to expose.
Proposal
A curated Agent MCP server on its own port (default 9999, SBS_AGENT_MCP_PORT), running alongside the existing full MCP.
- Hand-picked ~13-tool set with LLM-friendly names and docstrings:
- Tools:
list_tools, get_tool, get_tool_code, create_tool, execute_tool, search_tools
- Skills:
list_skills, get_skill, create_skill (resolves tool names → UUIDs), search_skills
- VMCP:
list_vmcp_servers, create_vmcp_server (resolves skill name → UUID), delete_vmcp_server
- Every curated tool is a thin HTTP proxy to the local FastAPI backend (3–10 lines over
httpx). No reimplemented business logic — validation, observability counters, and persistence stay in the REST layer. The curation value is the smaller surface and better names, not new logic.
- Explicitly excludes the health/broken-state/admin/dependency tooling that the full MCP exposes — agents that genuinely need those can still reach the full MCP at
/control_sse.
- Startup banner prints the curated MCP URL on
make run.
Acceptance criteria
Context
Split out of the combined issue #76 and the (closed) PR #77. Reference implementation: fast_api/curated_mcp_server.py in PR #77.
Problem
The store today exposes a single MCP endpoint: the full MCP at
/control_sse, auto-generated from every FastAPI route byfastapi-mcp. That surface is ~40 tools with HTTP-style machine names (e.g.list_tools_tools_get) and includes a lot of operations an agent should not be handed — admin/health/broken-state/tool-health endpoints, dependency-management routes, etc. It's too token-heavy and too broad for agents that struggle with large tool lists.We need a smaller, curated MCP that exposes only the handful of tools an agent actually needs, with clean LLM-friendly names — not everything the REST API happens to expose.
Proposal
A curated Agent MCP server on its own port (default
9999,SBS_AGENT_MCP_PORT), running alongside the existing full MCP.list_tools,get_tool,get_tool_code,create_tool,execute_tool,search_toolslist_skills,get_skill,create_skill(resolves tool names → UUIDs),search_skillslist_vmcp_servers,create_vmcp_server(resolves skill name → UUID),delete_vmcp_serverhttpx). No reimplemented business logic — validation, observability counters, and persistence stay in the REST layer. The curation value is the smaller surface and better names, not new logic./control_sse.make run.Acceptance criteria
SBS_AGENT_MCP_PORT(default 9999) and advertises exactly the curated tool set./control_sseand all REST endpoints remain unaffected.Context
Split out of the combined issue #76 and the (closed) PR #77. Reference implementation:
fast_api/curated_mcp_server.pyin PR #77.