Repository navigation
feat: add outputSchema and infer execute output from it - #16
Open
beaufortfrancois wants to merge 2 commits into
Open
beaufortfrancois wants to merge 2 commits into
beaufortfrancois wants to merge 2 commits into
Conversation
Collaborator
Author
|
@MiguelsPizza Please review |
This was referenced Nov 4, 2026
Kulikowski
approved these changes
Nov 4, 2026
beaufortfrancois
added a commit
to GoogleChromeLabs/webmcp-extension
that referenced
this pull request
Nov 4, 2026
Follows webmachinelearning/webmcp#254, which adds an optional outputSchema to ModelContextTool and RegisteredTool. The content script forwards RegisteredTool.outputSchema to the side panel, which checks every result of that tool against it, before the result is truncated or spotlighted. A result that does not match goes back to the model as a tool error saying where it differs, as MCP clients do with structured content. A schema that cannot be used is the page's mistake, so the result is then passed on unchecked. The check is done in the side panel, so it holds for the backend server and the on-device Prompt API alike. The schema is not sent to any model: only Gemini has a field for it, and the model is better served by results known to match than by a description of what they should look like. Results are validated with @cfworker/json-schema, which never evaluates code, as the extension's content security policy requires. webmcp-types does not declare outputSchema yet (webmachinelearning/webmcp-types#16), so RegisteredTool is augmented locally until it does.
Contributor
|
LGTM! do we want output type inference on this one? I can follow up on it if so @beaufortfrancois |
beaufortfrancois
changed the title
beaufortfrancois
force-pushed
the
output-schema
branch
from
November 5, 2026 08:14
cd40ccf to
ab64976
Compare
Collaborator
Author
I was unsure yesterday... I've added it today. Please review ;) |
MiguelsPizza
reviewed
Nov 9, 2026
Contributor
|
@beaufortfrancois just one non-blocking question. Otherwise, really nice work! |
MiguelsPizza
approved these changes
Nov 9, 2026
MiguelsPizza
approved these changes
Nov 9, 2026
MiguelsPizza
left a comment
MiguelsPizza
left a comment
Contributor
There was a problem hiding this comment.
LGTM. Non-blocking: could ModelContextToolFromSchemas be exposed in the WebMCP namespace (or the old ModelContextToolFromSchema name kept as an alias) so consumers can still name the inferred tool type?
`registerTool()` now has a single generic signature that infers both the input and the return type of `execute` from `inputSchema` and `outputSchema`. Tools without schemas, or with schemas typed as a plain `object`, keep a `Record<string, unknown>` input and an `unknown` output. `WebMCP.ModelContextToolFromSchema` gains an optional `TOutputSchema` parameter, and its `inputSchema` is now optional. Also renames the `ToolExecuteCallback` generic parameter to `TInput`, adds a `TOutput` parameter, and documents schema-based inference in the README.
beaufortfrancois
force-pushed
the
output-schema
branch
from
November 9, 2026 08:27
ab64976 to
cf3599d
Compare
beaufortfrancois
changed the title
Contributor
|
We good to release this one? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds support for webmachinelearning/webmcp#254.
Changes
outputSchema?: objecttoModelContextTool(accepted byregisterTool()) andRegisteredTool(returned bygetTools()).registerTool()now has a single generic signature that infers both the input and the return type ofexecutefrominputSchemaandoutputSchema. Tools without schemas, or with schemas typed as a plainobject, keep aRecord<string, unknown>input and anunknownoutput.WebMCP.ModelContextToolFromSchema<TInputSchema, TOutputSchema>: gains an optionalTOutputSchemaparameter (defaulted, non-breaking), and itsinputSchemais now optional.ToolExecuteCallback<TInput, TOutput>: the generic is renamed fromTand aTOutputparameter is added (both defaulted, non-breaking).Compatibility
The untyped
registerTool(tool: ModelContextTool)overload was folded into the generic one; otherwise a return value disagreeing withoutputSchemawould silently fall through to it. PrebuiltModelContextToolvalues, widened schemas, separately declaredToolExecuteCallbacks, and explicitregisterTool<TInputSchema>()calls are still accepted.Known limitation
When
executedeclares no parameters (e.g.() => ({ status: 'ok' })), TypeScript checks it before inferringoutputSchema, so returnedenum/constliterals are widened and rejected. Declaring the input parameter ((input) => ...) avoids this. Documented in the JSDoc and README.