Clean MCP architecture: shrimp direct spawning, aibroker as pure LLM proxy #36
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
With #34 adding MCP endpoints to all services and #27 standardizing server lifecycle via
HeroRpcServer, the MCP client-side architecture needs cleanup.Problem
Today there are two parallel MCP paths from the AI Assistant to services:
/tools→ aibroker spawns bridges → servicesThis creates:
mcp_servers.jsonarray vsmcp.jsonobject)HERO_CONTEXT?)Proposed Architecture
Server-side (covered by #27 + #34)
POST /mcp(auto-generated from OpenRPC byHeroRpcServer)_contextparameter in JSON-RPCClient-side (this issue)
mcp.jsonin Claude Desktop object formatHERO_CONTEXTinto system prompt; LLM passescontextparam to toolsWhat changes
mcp_manager.tsmcp.jsonmcp.ts/tools/toolsRESTmcp_servers.jsonmcp.jsonmcp.jsonBenefits
Dependencies
HeroRpcServerauto-generates/mcpfrom OpenRPC (proposed)Non-blocking
Both paths work today. This is a cleanup for architectural clarity, not a blocker.
mik-tf referenced this issue2026-03-18 19:42:53 +00:00
mik-tf referenced this issue2026-03-18 20:13:52 +00:00
mik-tf referenced this issue2026-03-18 22:06:25 +00:00
mik-tf referenced this issue2026-03-18 22:37:34 +00:00
mik-tf referenced this issue2026-03-18 22:52:15 +00:00
mik-tf referenced this issue2026-03-18 22:55:28 +00:00
Implemented — MCP architecture cleaned up
hero_shrimp (branch
development_mik_6_1):src/core/mcp.ts(aibroker REST /tools discovery)discoverMCPTools()fromloader.tsmcp_manager.ts(direct bridge spawning frommcp.json)hero_aibroker (branch
development_mik_6_1):src/mcp/module (client, config, manager, server, types) — ~1000 linesmain.rsmcp_servers.jsonResult: Single MCP path — shrimp spawns bridges directly via
mcp.json. No aibroker intermediary.Commits:
development_mik_6_1(PR #11)development_mik_6_1(PR #27)mik-tf referenced this issue2026-03-18 23:16:26 +00:00
mik-tf referenced this issue2026-03-18 23:28:29 +00:00
mik-tf referenced this issue2026-03-18 23:33:28 +00:00
mik-tf referenced this issue2026-03-19 00:06:50 +00:00
mik-tf referenced this issue2026-03-19 00:17:18 +00:00
mik-tf referenced this issue2026-03-19 00:26:50 +00:00
mik-tf referenced this issue2026-03-19 02:54:39 +00:00