Option / Feature to toggle MCP responses to be stored as files

[SuperSecureHuman]

There are some usecases where the remote MCP may (or may want to) return a file or large chunk of text. Most coding agents have a cutoff on tokens.

There are 2 types of cases --

1. The LLM needs to know the file content to be able to do some task
2. The LLM uses this file as a input to do some task, does not necessarily have to know whats inside in depth.

All SOTA models are very good at grepping through the files and trying to understand whats in it, without having to read the entire file. Having this toggle for MCP servers (per server or per tool level) will allow for more complex usecases.

I am happy to work on this feature :)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 26, 2026, 12:03 AM ET / 04:03 UTC.

Summary
Keep open. Current main supports normal response rendering, MCP resource reads, and opt-in saving for image content blocks, but I did not find a per-server or per-tool policy that stores large text/tool responses as files.

Reproducibility: not applicable. this is a feature request for new configurable output behavior rather than a report of broken existing behavior.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
This needs maintainer product/API direction before it becomes a narrow implementation task.

Review details

Best possible solution:

Design an explicit response-spill policy that preserves existing stdout and CallResult contracts while letting selected tools return file references for large text or resource payloads.

Do we have a high-confidence way to reproduce the issue?

Not applicable; this is a feature request for new configurable output behavior rather than a report of broken existing behavior.

Is this the best way to solve the issue?

Unclear; adding this directly is plausible, but maintainers need to choose the file-reference contract and config/API surface before implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The right contract for generated file paths, stdout shape, cleanup, and per-server versus per-tool configuration is still a product/API decision.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 1c5e96483e68.

Label changes

Label changes:

• add P3: This is a useful ergonomics feature for large MCP outputs, but it is not an urgent broken workflow.
• add impact:other: The reported impact is model-context pressure from large MCP responses, which is maintainer-visible but outside the more specific owned impact labels.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a useful ergonomics feature for large MCP outputs, but it is not an urgent broken workflow.
• impact:other: The reported impact is model-context pressure from large MCP responses, which is maintainer-visible but outside the more specific owned impact labels.

Evidence reviewed

What I checked:

• Repository policy: AGENTS.md was read fully; its triage guidance says to ask first for new features, broad behavior changes, or new config/API surface, which applies to this requested response-storage toggle. (AGENTS.md:126, 1c5e96483e68)
• Vision fit: VISION.md frames MCPorter around making MCP servers practical for scripts and agent workflows, while asking first when a change adds product direction or complexity. (VISION.md:3, 1c5e96483e68)
• Current call rendering path: The call command wraps the raw tool result, prints it through the normal output formatter, then only invokes image saving and optional log tailing; there is no text-response spill-to-file step here. (src/cli/call-command.ts:183, 1c5e96483e68)
• Available call flags: The call argument parser has handlers for output formatting, tail logs, and --save-images, but no response/file storage toggle. (src/cli/call-arguments.ts:56, 1c5e96483e68)
• Image-only persistence: The only response-file helper saves wrapped.images() to disk when an output directory is supplied, so it does not cover large text or resource payloads. (src/cli/image-output.ts:5, 1c5e96483e68)
• Config surface: The server config schema covers transport, auth, lifecycle, logging, and tool allow/block lists; it does not currently define a response-storage policy field. (src/config-schema.ts:82, 1c5e96483e68)

Likely related people:

• Peter Steinberger: Git history shows he introduced the CallResult helpers and the current opt-in image-saving path that govern how tool responses are rendered or persisted. (role: feature-history owner; confidence: high; commits: d86d4c5f6c9a, 7ff297ef2eb9, 94e65ba0572e; files: src/result-utils.ts, src/cli/call-command.ts, src/cli/call-arguments.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[SuperSecureHuman]

The flow could be something like this

mcp client call via mcporter
    ↓
mcp server returns:
{
  "summary": "...",
  "logs": "...very large...",
  "generated_code": "...very large...",
  "metadata": {...}
}
    ↓
mcporter intercepts response
    ↓
based on config:
- inline some keys to LLM
- store some keys externally
- optionally split large keys into separate files
    ↓
return transformed response:
{
  "summary": "...",
  "metadata": {...},
  "logs": {
    "bypassed": true,
    "filepath": "/tmp/logs.txt"
  },
  "generated_code": {
    "bypassed": true,
    "filepath": "/tmp/generated_code.ts"
  }
}