Follow-up from the review of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254894 (`get_artifact_file` MCP tool). Every other item raised in that review was fixed in the MR itself (bounded zip reads, artifact availability, URL parsing unified on `Mcp::Tools::Concerns::UrlParser`, read-probe unit tests, spec coverage); the non-ASCII metadata lookup discovery moved to https://gitlab.com/gitlab-org/gitlab/-/work_items/629170. This issue keeps the one open design question. ## Current direction (as of 2026-09-15) The recommendation below has changed. The original proposal — an admin-tunable `mcp_max_artifact_archive_size_mb` application setting — is now a fallback, not the primary plan. An application setting is permanent contract surface: once shipped, removing it later is a breaking change for self-managed instances. The ranged-read adapter described further down also removes the setting's reason to exist, since per-call transfer stops scaling with archive size once reads are ranged. The recommended path is to keep the hard-coded 20 MB cap in the meantime, implement the ranged-read adapter as the primary follow-up, and only revive the setting (reference implementation in the closed https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255712) if a spike shows ranged reads are infeasible on some storage backends. The sections below are kept as originally written for context. **Decision needed:** confirm we're proceeding with the ranged-read adapter as the primary follow-up and treating the application setting as fallback-only. ## Make the archive download cap configurable — needs discussion first The tool refuses to read from archives larger than a hard-coded 20 MB (`MAX_ARCHIVE_BYTES`), because serving one file means downloading the whole archive synchronously on a Puma thread (from https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254894#note_3835046960). Reviewers agreed the cap should be admin-tunable. A first implementation existed as https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255712 (closed, kept for reference): `mcp_max_artifact_archive_size_mb` on the existing `mcp_server_settings` JSONB accessor, no migration, default 20. Open questions to settle before reviving it: 1. Mechanism: a new key in `mcp_server_settings` (the closed MR's approach) vs reusing `max_artifacts_content_include_size` (per-file semantics, 5 MB default — likely too small for archives) vs no setting at all. 2. Scope: instance-only, or does GitLab.com need a value GitLab operators can tune independently of the shipped default (the closed MR exposed it in `visible_attributes` only for self-managed, mirroring `mcp_server_enabled`)? 3. Whether the ceiling should also bound `byte_offset`'s schema `maximum` (currently a separate hard-coded 100 MB inflate ceiling). ## Ranged reads instead of whole-archive downloads Proposed by `@ck3g` in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254894#note_3835046960: `job.artifacts_file.open` returns a `Gitlab::HttpIO` that supports `seek`, and `Zip::File.open_buffer` only needs `tell`, `seek`, `read`, `eof` and `close`. A small adapter could read just the central directory and the one requested entry — like Workhorse does — instead of streaming the whole archive into a Tempfile. That would change what the archive-size cap protects (transfer time and disk would stop being per-call costs), so it should be designed together with the cap question above. Spike result (2026-09-15, executed against a live in-process HTTP server honoring `Range`): **works.** Reading one entry from a 922 KB archive fetched 267 KB in 3 ranged requests — two tail chunks for rubyzip's backward central-directory scan plus one chunk at the entry's offset. The chunk count is independent of archive size, so the ratio only improves for larger archives. The adapter is three small pieces on top of `Gitlab::HttpIO`: 1. `def eof` delegating to `eof?` (rubyzip's `open_buffer` checks for `eof`, not `eof?`; `tell` already exists). 2. Hiding `HttpIO#path` from rubyzip (`Zip::File` takes `io.path` as the archive name and reopens entries from that "path", which turns into `File.open('') → ENOENT` if HttpIO's nil path leaks through). 3. A note that `Entry#get_input_stream` `dup`s the IO sharing the underlying HttpIO — sequential reads are safe, concurrent reads are not. Original feasibility notes (verified against current sources): - The adapter does not exist anywhere yet: `Gitlab::Ci::ArtifactFileReader` — the only other synchronous archive reader — also downloads the whole archive via `use_open_file` and extracts with SafeZip. - `Gitlab::HttpIO` reads in 128 KB chunks, one `Range` request per chunk, and its backward-read handling (`lib/gitlab/http_io.rb`) already covers the tail-first scan rubyzip uses to locate the central directory. - Local-storage instances get a plain `File` from `artifacts_file.open`; `Zip::File.open_buffer` accepts both, so the adapter must simply not assume HttpIO. - The decompression-side defenses (the `byte_offset` ceiling, the end-of-stream probe, the metadata size cross-check, and the entry-count cap) are unaffected: ranged reads save transfer and disk, not inflation. Umbrella: https://gitlab.com/gitlab-org/gitlab/-/work_items/622712