Bug: skill name + MCP server name collision causes silent server drop (no error, no warning)

Summary

When a Claude Code skill (in .claude/skills/<name>/) shares its name with an MCP server registered in ~/.claude.json mcpServers, the harness silently fails to enumerate the server at session startup. No error, no warning — the server simply doesn't appear in the deferred tools list, and ToolSearch returns No matching deferred tools found.

claude mcp list (the CLI subcommand) shows ✔ Connected because it tests a direct handshake — but the harness session itself never loads the server.

Environment

• Claude Code: v2.1.227
• OS: macOS Darwin 25.5.0
• Config scope: user-level ~/.claude.json + project-level .claude/skills/

Reproduction

1. Have an MCP server named, e.g., graphify in ~/.claude.json:

``json
{"mcpServers": {"graphify": {"type": "stdio", "command": "/path/to/graphify-mcp"}}}
``

1. Verify it works: launch claude, run ToolSearch query=\"graphify\" — should return deferred tools like mcp__graphify__query_graph.
2. Create a skill with the same name at .claude/skills/graphify/SKILL.md with frontmatter name: graphify.
3. Relaunch claude.
4. claude mcp list still shows graphify: ✔ Connected.
5. ToolSearch query=\"graphify\" now returns No matching deferred tools found.

Expected behavior

Either:

• (a) Both the skill and the MCP server load — they live in different namespaces (Skill(<name>) vs mcp__<server>__<tool>) and there is no actual ambiguity, OR
• (b) The harness logs a warning at startup: skill 'graphify' shadows MCP server 'graphify'; rename one to disambiguate.

Actual behavior

The MCP server is dropped from enumeration with **zero diagnostic output. The startup log (~/.claude/debug/auto/<timestamp>.log) shows the harness successfully connecting 8 other MCP servers but never even attempts to start the colliding one — no Starting connection, no Connection established`, no error. The skill loads normally.

Diagnostic recipe that uncovered this

# List servers the harness actually established connections with
grep 'Connection established' ~/.claude/debug/auto/20260811-082331-88882.log | \
  sed -E 's/.*MCP server "([^"]+)".*/\1/' | sort -u
# If your server is missing here but 'claude mcp list' shows ✔ Connected → name collision with a skill.

Timeline of logs was decisive: pre-skill-install log showed graphify: Successfully connected (transport: stdio) in 836ms; post-skill-install log had zero graphify mentions.

Impact

This is a footgun for anyone using <tool> install --project-style installers (graphify, sentry, etc.) that scaffold both a skill AND an MCP server under the same canonical name. The MCP server silently disappears and the user attributes it to wrapper/env/config issues — my own diagnosis wandered through several wrong hypotheses (wrapper vs bare session, zombie process, config drift) before the log timeline made the collision obvious.

Suggested fix

At minimum: emit a startup warning when a skill name and MCP server name collide. Ideally: load both — they are different namespace prefixes (Skill(name) vs mcp__<server>__<tool>) and there is no real disambiguation needed.

Workaround

Rename one of them. Renaming the MCP server in ~/.claude.json preserves the canonical skill trigger and is the cleanest local fix.