Raw-JSON tool arguments are still coerced by the schema before they are sent

[cliffhall]

Summary

SchemaForm's Edit as JSON switch (#2151, PR #2170) lets the whole arguments object be written as JSON. What the user writes is not always what goes on the wire, because the dispatch still applies the coercion the widget form needs.

InspectorClient.callTool runs every string-valued argument through convertStringToolArgs → convertToolParameters, which converts it to the type the tool's inputSchema declares. That exists for a good reason: the widget form hands everything over as text. But a raw-JSON draft already carries real JSON types, so the conversion is applied to values that never needed it.

Reproduce

1. Connect a server with a tool whose schema declares a numeric argument — test-servers/configs/structured-output-http.json's get_temp, or any add-style tool.
2. Tools tab → select the tool → Edit as JSON.
3. Enter an argument as a string where the schema says number, e.g. {"count":"01"}.
4. Execute, and read the request in the Protocol or Network tab.

Expected: the wire carries {"count":"01"} — what the editor showed.
Actual: the wire carries {"count":1}.

Two consequences, and the second is the more interesting one:

• The editor displays one payload and the Inspector sends another, which is the property Use the Ace JSON editor everywhere JSON is edited, and restore the v1 raw-JSON toggle on tool forms #2151's raw mode exists to provide.
• A schema-invalid argument cannot be sent at all, so the Inspector cannot be used to check how a server handles one — which is a thing an inspector should be able to do, and part of why a raw-JSON escape hatch is wanted.

Why it was not fixed in #2170

Copilot raised it on review round 12 of that PR. The fix is not local to the web client:

• Core. InspectorClient.callTool (and callToolStream, and the task path) would need an option to skip argument coercion — its options?: { skipOutputValidation?: boolean } bag is the natural home. That is shared code: the CLI and TUI call the same methods, so the change wants its own tests.
• Web. "This came from raw mode" has to travel from SchemaForm through ToolDetailPanel / AppDetailPanel, their screens, and App.tsx's two callTool call sites plus the open-app path. SchemaForm.onChange currently reports values only, with nothing to say where they came from.

There is also a product question underneath, which is the real reason this deserves its own issue rather than a late round of an already-large PR: should the Tools tab be able to send arguments the schema says are invalid? Raw mode's purpose argues yes. If the answer is no, the fix is the opposite one — detect the coercion and refuse it, the way PR #2170's Edit-and-replay modal already does for the same conversion (reshapedReplayParam) — and the two paths should then agree.

Acceptance

• A decision recorded on whether raw-mode arguments bypass schema coercion or are refused when they would be coerced.
• Whichever it is, tools/call from raw mode sends exactly what the editor shows, or says why it will not.
• The same answer applies to the Apps tab's tool arguments and to the "Run as task" path, not just the plain call.
• Consistency with the Edit-and-replay modal, which detects the identical conversion today.
• Tests, including one that pins the wire payload rather than the form value.

[cliffhall]

Acceptance checked off against #2175 (open, not yet merged). What satisfies each:

1. A decision recorded. Maintainer call: refused, not bypassed — the second of the two directions this issue names. Recorded in the PR body, in SchemaFormProps.enforceToolArgumentTypes, and in the web README.

2. Sends exactly what the editor shows, or says why it will not. The second branch. A draft the conversion would touch is refused with `count` would be converted to the type the schema declares — write the value with that type instead, and Execute / Open App are disabled. What does get sent is what was shown, because the check guarantees the conversion is a no-op on anything submittable.

3. Apps tab and the "Run as task" path. Apps opts in through AppDetailPanel and has its own tests. "Run as task" needs no separate handling because of where the gate sits: the panel has one Execute button whose disabled state does not depend on the toggle, and the plain-vs-task split happens later, in App.tsx, downstream of onCallTool. Stopping the callback stops both.

4. Consistency with Edit-and-replay. Stronger than parity: both now read one predicate (coercedArgumentNames) and one sentence (coercedArgumentsError) from core/json/jsonUtils.ts. The modal’s private copy of the check is deleted. Its behavior is unchanged — it is the surface the other two were brought into line with.

5. A test that pins the wire rather than the form value. Worth stating precisely, since the refusal answer changes what "the wire payload" means: there is no payload to pin, so the tests pin the absence of a dispatch. ToolsScreen and AppsScreen assert onCallTool / onOpenApp are not called for a refused draft, and are called once the value is rewritten with the declared type — so the draft is demonstrably what blocks it, not an inert screen. That is the dispatch boundary in the web client; nothing reaches the transport because nothing reaches the client, and InspectorClient is unmodified by this PR.

One consequence of the chosen direction, recorded here rather than buried in the PR: the Inspector can no longer send a deliberately schema-invalid argument from the UI. That was the second consequence in this issue’s repro and is what the other direction would have bought. If checking a server’s handling of a bad argument is wanted later, it needs its own affordance rather than the raw editor’s silence.