[FEATURE] Edit/Write tools should accept MCP tool reads to satisfy the prior-read requirement

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's Edit and Write tools require that a file has been read via the native Read tool before it can be modified. This is a sensible safety guard — but it creates unnecessary
friction when an MCP server has already read and returned the file's contents.

Concrete example: Indexer MCP

The Indexer MCP server is a code-navigation tool that provides several tools for reading file content:

• read_file — reads a file with line numbers (same output as the native Read tool)
• extract_chunk — returns the full source code of a named symbol (function, method, struct, etc.) from a file, without reading the whole file. This is particularly token-efficient

for large files where only a small function needs to be edited.

• find_symbol / semantic_search — locate and return relevant code snippets with file paths and line ranges

When Claude uses these tools to locate and read a function it needs to edit, it has already seen the file's current content. But the Edit tool then rejects the edit with:

This tool cannot be used without reading the file first via the Read tool.

This forces a redundant second read via the native Read tool, negating the token savings that motivated using the MCP tool in the first place.

What makes this especially wasteful

The extract_chunk tool can return just the 20-line function that needs changing, while the native Read tool reads the entire file (potentially thousands of lines) just to satisfy the
prior-read check. The safety intent (Claude should know what it's editing) is already fulfilled — but more tokens are consumed, not fewer.

Proposed Solution

Option A — Let MCP tools mark files as read

Expose a mechanism in the tool-call protocol (or a dedicated MCP tool) that allows an MCP server to signal: "I have returned the full, current contents of this file." The Edit/Write
tools would accept this signal as equivalent to a native Read.

Alternative Solutions

Option B — Accept any tool result that contains file contents

Heuristically detect when a tool result includes the current contents of a file (e.g. matched by path + line-numbered content) and mark it as satisfying the prior-read requirement.

Option C — Allow bypassPermissions or a new permission flag to opt out

For power users / agentic setups where double-reading is provably wasteful, provide a settings flag (e.g. "skipReadBeforeEditCheck": true) to disable the check.

Priority

Medium - Would be very helpful

Feature Category

File operations

Use Case Example

Any workflow that uses MCP tools for code navigation (semantic search, symbol extraction, fuzzy file search) and then wants to edit files is affected. The double-read is not just a
token cost — it also breaks the ergonomic promise of using a smarter MCP-based read in the first place.

Additional Context

_No response_