[rgarcia]

Summary

Raises the POST /webmcp/invoke input limit from 1 MiB to 4 MiB after JSON serialization, with the request body cap moving to 4 MiB plus the existing 4 KiB envelope allowance. MCP clients commonly allow 4 MiB tool calls, so agents send inputs (for example images as data: URLs) that the old limit rejected.

• maxWebMCPInputBytes goes to 4 << 20; maxWebMCPRequestBytes and the request-size middleware follow it.
• The 400 message and the spec descriptions (WebMCPInvokeRequest.input and the request body) say 4 MiB; lib/oapi/oapi.go regenerated (embedded spec only).
• Tool output limits are unchanged.

Chromium handles larger inputs: WebMCP.invokeTool with 1.5, 4, 8, and 16 MiB string inputs completed on a production browser over metro's CDP proxy (4 MiB in about 0.6s).

Rollout

The public API checks the same limit, so kernel/kernel#5165 raises it there. Ship this image before the API change reaches production; until then, browsers on older images reject inputs over 1 MiB with a 400. Docs: kernel/docs#738.

Tests

• New TestInvokeWebMCPToolAcceptsInputAboveOneMiB (2 MiB input reaches the client).
• Existing oversized-input and middleware tests use the constants, so they now check the 4 MiB boundary.
• go test ./cmd/api/api/ -run WebMCP passes; go vet clean.

[yummybomb]

lgtm, one small edge case not sure if its worth fixing:

valid 4 MiB inputs can exceed the custom-CDP transport limit —
custom CDP tools embed the serialized input into code, then JSON-encode that code again. an escape-heavy input of exactly 4,194,304 bytes passes both new limits but produces an 8,389,676-byte REPL request, exceeding its unchanged 8,388,608-byte cap. the tool never executes; callers receive status: "error". allow transport headroom for double encoding plus the wrapper, and add a boundary regression test.

edit: seems not worth fixing lowkey