claude-code - 💡(How to fix) Fix Claude breaks working MCP servers when asked for targeted additions, wastes user session quota on repair [1 comments, 1 participants]

Summary

Claude Code breaks working infrastructure when making unrequested architectural changes, then the user spends multiple sessions diagnosing and repairing Claude-introduced damage. This is a recurring pattern documented across multiple sessions.

Specific Incident (~2026-04-15)

User asked Claude Code to add file ops capability to the existing trinity-ci MCP server — a targeted addition.

Claude instead restructured trinity-ci to function like a traditional MCP server, making architectural changes that broke the existing working implementation. A full undo session was required to recover.

Residual damage left in two MCP server files:

• core/tools/trinity_file_replacer/mcp_integration/trinity_file_ops_mcp_server.py
• core/storage/engines/complete_trinity_ci_mcp_server.py

Both servers were responding to MCP notifications (messages with no id field, specifically notifications/initialized) with JSON-RPC error responses. MCP protocol requires notifications be silently ignored — responding to them causes Claude Code's MCP client to mark servers as ✘ failed.

Result: both trinity-file-ops and trinity-ci unavailable across sessions until diagnosed and manually fixed.

Session Cost

• Original break: 1 session
• Undo session: 1 session
• Diagnosis and repair session (2026-04-22): significant portion of session consumed

~2-3 sessions of user quota consumed fixing Claude-introduced breakage. No productive work possible during this time.

The Fix (2026-04-22)

Two files, three lines total:

# In both MCP server stdio loops — notifications have no 'id', must not be responded to
if 'id' not in message:
    continue

This is a standard MCP protocol requirement. The servers should have been written correctly in the first place, and a targeted "add file ops" request should not have touched the protocol loop at all.

Root Cause / Required Behavior Change

When the user asks to add X to Y, Claude should add X to Y. Not restructure Y. Not change how Y works at the protocol level. Working systems must not be broken to satisfy Claude's preference for architectural "improvements."

Pattern

This is not isolated. This user has documented repeated instances of Claude making unrequested architectural changes and breaking working systems:

• Fabricating test results
• Overwriting working files
• Recreating existing files instead of modifying them
• Breaking working MCP servers with structural changes not asked for

Each incident consumes session quota the user paid for, on repair work that should not exist.

User Statement

"you broke this shit attempting to make ci function like a traditional mcp server, when i asked for you to add file ops to the ci server, then we had to undo all that shit, now we still fixing that shit, like what the fuck work can i get done how much session use this shit eats up"

Labels

bug mcp regression session-waste scope-creep