Summary

The current web_fetch tool returns an inline body preview capped by MAX_BODY_LENGTH. Even after raising that limit, large HTML and JSON responses are still too easy to truncate, and increasing the inline cap further will just bloat model context.

Problem

Today the tool only returns a bounded string body in its output. That makes large fetches hard to inspect because:

10k is still small for many HTML and JSON payloads
increasing the limit keeps pushing more raw response data into model context
there is no way to inspect the full payload in chunks after truncation

Proposed approach

Change web_fetch to use a file-backed response model:

keep a small inline preview in the tool output
save the full response body to a sandbox file
return metadata such as status, contentType, bytes, truncated, and savedBodyPath
let the agent inspect the saved file through the existing read flow when needed

Why this is better

preserves access to full responses without flooding model context
scales better for HTML, JSON, and other large payloads
keeps the default fetch output concise while still debuggable

Suggested follow-up scope

update packages/agent/tools/fetch.ts to persist large bodies and return preview + metadata
update the fetch renderer to show the preview and saved path
add tests covering large-body persistence and preview behavior
optionally consider inputs like headersOnly, saveBody, or configurable preview length

Acceptance criteria

fetching a large response stores the complete body in the sandbox
the tool output includes a bounded preview plus the path to the saved body
the UI renders the preview and the saved-path metadata clearly
automated tests cover successful large-response handling without requiring oversized inline output

note: should only be for search results that are larger than our max chars thresholds

Activity

No activity yet.