Feedback for Claude Code / Anthropic — Limitations Found During Intensive MCP Development Session

Context

Issues and limitations found during an 8-hour continuous Claude Code session using the Cortex XSIAM MCP server to build playbooks, scripts, and automation workflows. These are about Claude Code's capabilities and MCP tool limitations, not the specific use case.

---

1. Cannot Programmatically Modify Playbook YAML

Problem: The get_playbook MCP tool returns YAML as a double-escaped string inside JSON. I could not save it to a local file for editing because:

• Content is double-escaped (\\n, \\") — standard file write produces corrupt YAML
• sdk_download requires a Packs directory structure and failed
• No save_to_file(content, path) capability exists for MCP tool responses

Impact: Every playbook modification (even changing one field) required the user to do it manually through the UI. This was the #1 time waster in the entire session.

Suggestion: Either add a save_playbook_to_file(name, path) MCP tool, or give Claude Code the ability to reliably unescape and save MCP tool responses to local files.

---

2. Context Window Exhaustion Loses Critical State

Problem: During a long session, context compressed multiple times. Each compression lost details about what was already tried, what failed, and what decisions were made. I repeated mistakes that had been fixed hours earlier.

Impact: The user had to re-explain the same things multiple times. Debugging loops that should have taken 1 iteration took 3-4.

Suggestion: Provide a mechanism to "checkpoint" key working state (current file versions, known bugs, agreed decisions) that survives context compression. The memory system helps but is designed for cross-session persistence, not intra-session state preservation.

---

3. Large MCP Tool Responses Overflow Context

Problem: Some MCP tool responses (like get_playbook with a complex playbook, or run_xql_query with many results) are extremely large (50K+ characters). These consume a huge portion of the context window and accelerate compression.

Impact: After reading a large playbook YAML or XQL result, the context was nearly full, forcing compression and losing earlier conversation details.

Suggestion: Allow Claude Code to stream large MCP responses to a file instead of loading them into context. A save_result_to_file option on MCP tool calls would help.

---

4. Cannot Run Shell Commands That Require gh CLI

Problem: When asked to submit a GitHub issue, gh CLI was not available (command not found: gh). Claude Code should either have gh pre-installed or detect its absence before attempting the command.

Suggestion: Check for tool availability before running commands, and suggest installation if missing.

---

5. File Editing Reliability with Escaped Content

Problem: When editing files that contain heavily escaped strings (like YAML with embedded HTML, or JSON with nested quotes), the Edit tool sometimes failed because the old_string didn't exactly match due to escaping differences between what I saw in context vs what's in the file.

Impact: Multiple failed edit attempts before finding the exact string match. Had to use Read with offset/limit to find the precise text.

Suggestion: Provide a line-number-based edit mode as an alternative to string matching, for cases where exact string matching is unreliable.

---

6. Parallel MCP Tool Calls Not Possible

Problem: When I needed to upload 3 scripts simultaneously, I had to do them sequentially (call 1, wait, call 2, wait, call 3). MCP tool calls cannot be parallelized.

Impact: Uploading 3 scripts took 3x the time it should have.

Suggestion: Allow parallel MCP tool calls when they are independent (e.g., uploading different files to the same server).

---

7. No Way to Save MCP API Response to File

Problem: When get_playbook returns the full YAML, I need to save it locally, edit it, and re-upload. But the response is in the conversation context — I cannot directly write it to a file because the escaping is wrong. Python scripts to unescape and save also failed because the tool result files weren't consistently saved to disk.

Impact: Spent 20+ minutes trying different approaches to save a playbook YAML to a file. Never succeeded. Had to ask the user to make changes via UI instead.

Suggestion: Add a built-in SaveToFile tool that takes a tool result ID and saves it to a specified path with proper unescaping.

---

8. Memory System Not Suitable for Active Session State

Problem: The memory system is designed for cross-session knowledge (user preferences, project info). But during a long session, what I needed was intra-session state tracking: "we already tried X and it failed because Y", "the current playbook has tasks A→B→C", "these 3 bugs are known and pending".

Impact: After context compression, I lost track of what was already tested and made the same suggestions the user had already rejected.

Suggestion: Introduce a "session scratchpad" — a structured, always-loaded working state that tracks current task progress, known issues, and decisions made. Separate from the memory system which is for long-term knowledge.

---

What Worked Well

1. MCP tool execution — reliable, fast, consistent error handling
2. File Read/Edit/Write — excellent for script development
3. Task tracking — TaskCreate/TaskUpdate helped organize complex work
4. Plan mode — useful for aligning on approach before implementation
5. Multi-tool calls in parallel — when tools were independent (Bash + Read), parallel execution was fast

---

Generated during an intensive Cortex XSIAM MCP development session, 2026-05-26