Remove `maxChars` and `maxChunks` from `scrape` arguments?

[quackerd]

Problem Description

Would it make sense to remove maxChars and maxChunks from scrape arguments and treat the corresponding values in the config file as the authoritative policy? Rather than a real bug report, perhaps this is better framed as a discussion because the reported behavior might be intentional. So I'm only giving my 2 cents here.

Right now the tool exposes (src/tools/scrape.ts):

maxChars: z
  .number()
  .int()
  .min(200)
  .max(20000)
  .optional()
  .describe("Per-URL character budget."),

maxChunks: z
  .number()
  .int()
  .min(1)
  .max(20)
  .optional()
  .describe("Per-URL evidence chunk cap."),

and runScrapeTool() passes those through:

maxCharsPerUrl: args.maxChars,
maxChunksPerUrl: args.maxChunks,

The scrape pipeline then resolves them as:

const maxChars = options.maxCharsPerUrl ?? config.maxCharsPerUrl;
const maxChunks = options.maxChunksPerUrl ?? config.maxChunksPerUrl;

So a value supplied by the MCP caller replaces the server configuration rather than being bounded by it.

Motivation

I think there is a useful distinction between arguments required to express retrieval intent and implementation/resource policy controls.

For example, url and query make sense as model visible inputs as they tell the server what the caller wants. However maxChars and maxChunks tell the server how much it should return.

The model generally has no additional knowledge that lets it choose a better budget than the user/admin. From my tests, most deepseek-flash scrape calls omit these parameters, but it does occasionally decide to supply them, at which point they can unexpectedly change retrieval behavior. This is particularly noticeable in a quality first deployment. For example, a user may deliberately configure very generous limits because they prefer preserving max source content.

Proposed behavior

I think the public scrape interface can remain roughly:

{
  "urls": ["..."],
  "query": "..."
}

while the server owns the limits:

scrape:
  maxCharsPerUrl:
  maxChunksPerUrl: 
  chunkChars: 
  maxEvidenceChars: 
  maxResponseBytes: 

Conceptually, the server owns the policy whereas the user/model owns the query content.

Why not expose the limits so the model can optimize?

I can see the appeal for giving agents control over context usage, especially for smaller models. But my concern is that the model is usually not in the best position to make this policy decision. Models sometimes proactively optimize token/context usage even when the user or deployment explicitly prefers retrieval completeness. Exposing maxChars gives models an opportunity to make a bad call and discard complete content. If context efficiency is the goal, it might be cleaner for the server to enforce policy.