[Feature] Introduce a lightweight routing layer between main model and tool execution

Problem

As Claude Code users accumulate more tools — MCP servers, Skills, local CLI tools — the main model carries all tool descriptions, signatures, and context into every prompt. This causes:

1. Context pollution: Token budget is consumed by tool inventory, not by reasoning about the actual problem
2. Decision degradation: The model gets worse at selecting the right tool as the list grows, especially when Skills have overlapping or ambiguous boundaries
3. Skill is a dead artifact: Skills are currently "stored" in the main context with no lifecycle — no usage telemetry, no self-evolution

Observation

Claude Code already has a Tool Search tool that does something similar in spirit: it queries an external index and returns results back to the main model, keeping the main context clean. The same pattern could be generalized.

Proposed Architecture

Introduce a lightweight routing Agent between the main planning model and tool execution:

User Request
    ↓
Main Model (intention + planning)
    ↓ "do I need a tool?"
Routing Agent ←→ Unified Tool Index (Skill/MCP/CLI metadata)
    ↓ returns: [tool_pointer + confidence + one-line rationale]
Main Model executes with the selected tool

Routing Agent's job is only: given a user intent, search the index and return the top-N matched tools with reasons. It does NOT solve the problem.

Tool metadata (Skill) lives here: SKILL.md files become "usage manuals" for specific tools — not objects to be searched, but guides to be consulted after a tool is selected.

Benefits:

• Main context no longer grows linearly with tool count
• Skill evolves from "isolated knowledge artifact" → "tool metadata layer"
• Routing Agent can run on a smaller model (cheap, fast)
• MCP/CLI/Skill responsibilities become naturally scoped: Skill = tool's manual, MCP/CLI = executor
• Usage telemetry from the routing layer enables Skill self-evolution (e.g., which Skills are triggered most, where they fail, which compete)

Why This Is Different from MCP

MCP attempts to standardize tool connectivity but faces a mature ecosystem (CLI, HTTP API) that already solves that problem well. This proposal does not replace any execution layer — it adds a decision/routing layer on top, which is a different problem with no good existing solution at this layer of abstraction.

Priority Signal

If this resonates, :+1: on this issue. I'd like to know if this is already under consideration or if there are architectural blockers.