Skills with context: fork still inject all MCP tool definitions into subagent, ignoring allowed-tools
Problem
When a skill uses context: fork with a smaller model (e.g., model: haiku), the subagent's system prompt includes all MCP tool definitions from the parent session — even when allowed-tools explicitly restricts the skill to only basic tools like Bash, Read, Edit, etc.
This causes "Prompt is too long" errors when the user has many MCP servers connected (e.g., PostHog, Stripe, Notion, Vercel, Sentry, etc. — 200+ tools), as the tool definitions alone can exceed Haiku's context window.
Reproduction
- Connect several MCP servers (cloud-hosted ones like PostHog, Stripe, Notion add up fast)
- Create a skill with this frontmatter:
```yaml
---
name: my-skill
context: fork
model: haiku
allowed-tools:
- Bash
- Read
- Edit
- Write
- Glob
- Grep
---
```
- Invoke the skill via
/my-skill - Result: "Prompt is too long" — the subagent can't start because MCP tool definitions overflow Haiku's context
Expected behavior
allowed-tools should control which tool definitions are injected into the subagent's system prompt, not just which tools the subagent is allowed to call. If a skill only needs Bash, Read, Edit, Write, Glob, Grep, MCP tool definitions should be excluded from the prompt entirely.
Alternatively, a new frontmatter field like exclude-mcp-tools: true or inherit-mcp: false would let skill authors opt out of MCP tool injection.
Workaround
Change model: haiku to model: sonnet (larger context window). This works but wastes tokens and costs more for skills that don't need MCP tools at all.
Environment
- Claude Code CLI (macOS)
- ~200 MCP tools connected via claude.ai integrations + local MCP servers
- Skill using
context: fork+model: haiku
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗