[FEATURE] Skill-Driven On-Demand MCP & Tool Loading

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Currently, any MCP server added via a plugin is "always on." Even with the new "Tool Search" feature, the model still suffers from "Context Noise" because all tool schemas are typically registered at the start of a session.

• Context Bloat: Heavy MCPs (e.g., Kubernetes, AWS, or complex DB schemas) eat 30k+ tokens just for tool definitions.
• Ambiguity: Having 100+ tools available globally increases the chance of the model choosing the wrong tool for a simple task.
• Skill/MCP Gap: Skills are "light" (loaded on demand), but if a Skill depends on a "heavy" MCP, that MCP must currently be loaded globally, defeating the purpose of the Skill's efficiency.

Proposed Solution

Introduce a "Lazy/On-Demand" loading strategy for MCP servers defined in plugins, and allow Skills to explicitly "request" these servers (or specific tools within them) via YAML frontmatter. This allows the main context to remain lightweight while providing Skills with full, dynamic access to heavy MCP toolsets only when invoked.

1. Plugin Manifest Change (plugin.json / MCP Config)

Add a loadingStrategy field to the mcpServers definition. When set to on_demand, the CLI registers the existence of the server but does not initialize the process or inject any tool schemas into the system prompt at startup.

{
  "mcpServers": {
    "cloud-ops-server": {
      "command": "npx",
      "args": ["cloud-mcp"],
      "loadingStrategy": "on_demand"
    }
  }
}

1. Skill Frontmatter Change (SKILL.md)

Update the Skill frontmatter to support an mcp field. This allows the Skill to act as the "gatekeeper." When Claude triggers this Skill, the CLI dynamically loads the specified MCP(s).

• Server-level loading: Loads all tools from the server.
• Tool-level loading: Loads only specific tools to keep context even tighter.

---
name: k8s-logs
description: Fetches and analyzes kubernetes logs for a specific pod.
mcp:
  - server: "cloud-ops-server"
    tools: ["get_pod_logs", "list_pods"] # Optional: only load these specific tools
  - server: "slack-notifications" # Load entire server
---
# Skill content here...

Alternative Solutions

Alternatively, on-demand functionality could be implemented right into the MCP spec.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

• Startup: Claude Code starts with 0 MCP tokens. It only knows the "Skill" exists (minimal footprint).
• Trigger: The user asks a question that triggers the k8s-logs skill.
• Activation: Claude Code sees the mcp requirements in the Skill's frontmatter.
• Injection: The CLI starts the cloud-ops-server, fetches only the get_pod_logs and list_pods schemas, and injects them into the current conversation turn.
• Session End: (Optional) The tools are purged from context when the task is marked as complete, returning to a "clean" state.

A developer has a "DevOps" plugin with 5 different MCP servers (K8s, AWS, Azure, GCP, Terraform). Instead of 200+ tools bloating every prompt, the developer uses five different Skills. Each Skill only pulls in the specific cloud provider's tools needed for that specific workflow.

Additional Context

This addresses the "O(n) injection" problem (Issue #28660) and builds upon the existing Skill discovery mechanism to solve the MCP bloat issue. It moves control from the CLI's automated heuristics to the Plugin Developer's explicit architectural design.