Clarification: RegisteredTool.inputSchema / executeTool input / result types — string vs object

[arnabwithab]

Context

Chrome origin-trial implementation (chrome://flags/#enable-webmcp-testing, document.modelContext, 149+) and the CG draft diverge on I/O shapes. This causes the same tool registration to be green in a headless stub and red in flagged Chrome (and vice versa).

Observed in Chrome native vs a postMessage test stub that follows the draft IDL literally:

Surface	getTools() RegisteredTool.inputSchema	executeTool arg	executeTool result
Draft (index.bs / webmcp.d.ts literal)	object (JSON Schema)	object via tool.execute(object)	object
Chrome native (document.modelContext.getTools() / executeTool(tool, inputJson:string)) — see implementation-status.md	string (stringified JSON Schema) — TueJon/webmcpify skills/webmcpify/templates/webmcp.d.ts:97, skills/webmcpify/templates/webmcp.spec.ts:67 JSON.parse(tool.inputSchema)	string (JSON.stringify(args)) — webmcp.spec.ts:95 mc.executeTool(tool, JSON.stringify(args))	string ("{\"ok\":true,…}") or null on navigation

Specifics:

• RegisteredTool.inputSchema is string on native (TueJon/webmcpify templates/webmcp.d.ts:97 comment: "NOTE inputSchema is a STRINGIFIED JSON Schema") but object in the draft IDL.
• executeTool(RegisteredTool, inputJson:string) (Chrome-only, not yet in draft per webmcp.d.ts:62) takes a JSON string; the draft-era stub exposes tool.execute(object). Mismatch throws UnknownError: Failed to parse input arguments one way, type error the other.
• Result is string | null on native (webmcp.d.ts:65 + webmcp.spec.ts:83), object on stub.

Request

Norm one of:

1. Keep draft object and note Chrome's stringified wire format as impl detail with a recommended typeof === 'string' ? JSON.parse : id + JSON.stringify before executeTool compat shim, or
2. Norm the stringified form (inputSchema: string, executeTool(tool, string), result string|null) and update index.bs accordingly.

Either way, explicit guidance that consumers should handle both shapes (parse inputSchema if string, accept result as string or object, stringify args for native with fallback) would prevent every kit (e.g. TueJon/webmcpify) from rediscovering this independently.

Happy to PR the explainer note once direction is set.

[arnabwithab]

Downstream kit fix: TueJon/webmcpify#12 — backwards-compat handling of both shapes (stringified inputSchema, JSON.stringify for executeTool, string-or-object result) in TueJon/webmcpify templates/docs.

[mlmrx]

This appears to be the same implementation/spec mismatch tracked in #278, for which #279 is already open.

One correction to the draft row in the table: the current draft does not return an object from executeTool(). Its WebIDL is Promise<DOMString> with an object inputObject, and the execution steps JSON-serialize the callback's fulfilled value before resolving the caller's promise (serialization). The normative JS-facing shapes are therefore:

• RegisteredTool.inputSchema: parsed object
• executeTool() input: object
• executeTool() result: JSON string

#279 adds focused prose and an example for the first two points. Chrome exposing a string schema and requiring a string input is implementation lag relative to that contract, as #278 also observed.

I would avoid recommending a permanent "handle both shapes" shim in the standard's explainer: that risks turning an origin-trial implementation mismatch into a second de facto API contract. Downstream libraries can temporarily feature-detect or version-gate compatibility behavior, while the WebMCP documentation should state the normative shape unambiguously. This issue could likely be treated as a duplicate of #278/#279, with any Chrome conformance bug tracked against the implementation.