Proposal: bounded multi-file reads to reduce MCP round trips

[lhysin]

Problem

When an MCP host such as ChatGPT needs to inspect several known files, DevSpace currently requires one read tool call per file.

For example, inspecting package.json, a config file, and two related source files requires four separate MCP tool round trips even when all four files are already known in advance.

This can add noticeable host-side latency and orchestration overhead. The goal here is not to make file I/O itself faster, but to reduce unnecessary MCP round trips for bounded, already-known read operations.

Proposal

Would DevSpace benefit from a small read-only operation that can read several files in a single MCP tool call?

Conceptually, something like:

workspaceId
reads:
  - path
    offset?
    limit?
  - path
    offset?
    limit?

The existing read tool would remain unchanged.

The multi-file operation would reuse the same workspace path validation and read behavior as individual read calls.

Important constraints

I don't think this should be a generic batch executor.

A narrowly scoped read-only operation seems safer because it can preserve the existing tool semantics and security boundary.

A possible implementation could also:

• impose a small maximum number of reads per request;
• preserve the existing per-file truncation behavior;
• impose an aggregate output budget so batching cannot produce an excessively large model context;
• return success or failure per requested file rather than failing the entire operation;
• preserve ordering where reads have stateful semantics, such as reading a SKILL.md before files that become readable after that skill is activated.

I would also avoid unbounded Promise.all() concurrency initially. The current underlying read implementation loads file contents before truncating output, so unrestricted concurrent reads of large files could increase memory use without helping the primary goal, which is reducing MCP round trips.

Why this seems useful

This would let hosts turn a sequence such as:

read A
read B
read C
read D

into one bounded MCP request when the required files are already known.

It would not replace normal iterative reading. If the result of reading A determines whether B or C should be inspected, individual tool calls would still be preferable.

Before implementing this, I'd like to check whether this direction fits DevSpace's intended tool surface, and whether a separate read-only tool or an extension of the existing read tool would be preferred.

[Waishnav]

wrong archiecture design, i prefer giving minimal choices expose to model and current SOTA model are already trained on single read tool call so this doesn't make sense and if considered it will bloats the design, so closing this