Allow skills to declaratively start/stop MCP servers they depend on
Problem
Platform-managed MCP integrations (Atlassian, Slack, etc.) inject their full tool definitions into every session's context, even when unused. This wastes context on tool definitions that are only relevant during specific workflows.
Proposed Solution
Let skills declare MCP server dependencies and manage their lifecycle. A skill that needs Slack or Atlassian would start the server when invoked and stop it when finished, keeping the tool definitions out of context for the rest of the session.
Example skill frontmatter:
---
name: closeout
mcpServers:
- slack
- atlassian
mcpLifecycle: skill # start on invoke, stop on completion
---
This would:
- Start the declared MCP servers when the skill is invoked
- Make their tools available during skill execution
- Stop the servers and remove tool definitions from context when the skill completes
Why This Approach
- Explicit over implicit — no heuristics or lazy-load guessing; the skill author knows exactly what integrations they need
- Self-contained — the skill owns its dependencies end-to-end
- Zero overhead when idle — MCP tools only exist in context during the workflow that needs them
- Scales naturally — as more MCPs become available, context cost stays proportional to what's actually being used, not what's connected
- User doesn't manage anything — no manual toggling, no predicting what they'll need
Use Case
A consultant has Atlassian and Slack connected for daily closeout and weekly review skills, but spends most sessions on development. Today, those 50+ tool definitions are loaded into every session. With this feature, they'd only appear during /closeout and /weekly-review, then disappear.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗