Problem
Even once MCP servers are spawned and tools discovered, fighters will not see them unless tools are injected into the LLM tool list.
Token Bloat Problem
This is the #1 complaint about MCP in 2026. 10 servers x 5 tools = 50 tool definitions consuming 30K+ tokens before the user says anything. OpenClaw has no solution. Perplexity CTO publicly abandoned MCP over this.
Proposed Solution
Lazy tool loading (like Claude Code Tool Search):
- On first message, inject a
discover_tools meta-tool that lists available MCP servers + tool summaries
- Fighter calls
discover_tools("gmail") to load Gmail tools into context on-demand
- Only actively-used tools consume context window tokens
- Estimated 40-50% token reduction vs naive loading
Implementation
- Convert MCP tool schemas to OpenAI-compatible function definitions
- When LLM calls an MCP tool, route to the correct server via
tools/call
- Return result back to the LLM conversation
- Cache tool schemas to avoid repeated
tools/list calls
Problem
Even once MCP servers are spawned and tools discovered, fighters will not see them unless tools are injected into the LLM tool list.
Token Bloat Problem
This is the #1 complaint about MCP in 2026. 10 servers x 5 tools = 50 tool definitions consuming 30K+ tokens before the user says anything. OpenClaw has no solution. Perplexity CTO publicly abandoned MCP over this.
Proposed Solution
Lazy tool loading (like Claude Code Tool Search):
discover_toolsmeta-tool that lists available MCP servers + tool summariesdiscover_tools("gmail")to load Gmail tools into context on-demandImplementation
tools/calltools/listcalls