Define the declarative input-schema synthesis algorithm (#declarative-api is currently a TODO)

Summary

The declarative API needs a deterministic way to turn a <form> and its form-associated elements into a JSON Schema inputSchema, so agents can reliably fill out and submit declarative tools. Today this is unspecified in two places:

In the spec, #declarative-api — the synthesize a declarative JSON Schema object algorithm is just 1. TODO: Derive a conformant JSON Schema object from |form| and its form-associated elements.
In the explainer, the "Input schema synthesis" section is also marked TBD, noting we need to specify how elements like <input> and <select> reduce to a JSON Schema.

I've joined the Web Machine Learning Community Group and would like to contribute a concrete proposal for this algorithm. I've also written a reference implementation that passes 11 test cases (details at the bottom). Sharing here for feedback before opening any PRs. It's intentionally conservative and aligned with the attribute model already in the explainer (toolname, tooldescription, name, toolparamdescription).

Proposed top-level shape

A <form> reduces to:

{
  "type": "object",
  "properties": { /* one entry per included, named control */ },
  "required": [ /* names of controls carrying the `required` constraint */ ]
}

Only named controls are included; submit/reset/button/image and unnamed/disabled controls are skipped.
Property key = the control's name; description comes from toolparamdescription; a control's value maps to default.
Controls sharing one name (radio groups, multi-checkboxes) are merged into a single property.

Proposed control → schema mapping

Control	JSON Schema	Constraints
`text` / `search` / `tel` / `password`	`{"type":"string"}`	`minlength`→`minLength`, `maxlength`→`maxLength`, `pattern`→`pattern`
`email`	`{"type":"string","format":"email"}`	`multiple` → array of email strings
`url`	`{"type":"string","format":"uri"}`
`number`	`{"type":"number"}`	`min`→`minimum`, `max`→`maximum`, numeric `step`→`multipleOf` (omit for `any`)
`range`	`{"type":"number"}`	`minimum` default 0, `maximum` default 100
`date` / `datetime-local` / `time`	`{"type":"string","format":"date" \| "date-time" \| "time"}`
`month` / `week` / `color`	`{"type":"string","pattern": …}`	no standard `format` exists
`checkbox` (single)	`{"type":"boolean"}`
`radio` group	`{"type":"string","enum":[values]}`	required if any member is required
`checkbox` group	`{"type":"array","items":{"enum":[values]},"uniqueItems":true}`
`<select>` / `<select multiple>`	`{"type":"string","enum":[…]}` / `{"type":"array",…}`	option text used when `value` absent
`<textarea>`	`{"type":"string"}`	`minlength`/`maxlength`

Algorithm (sketch)

Two algorithms, mirroring the split of concerns:

synthesize a declarative JSON Schema object (form-level): collect submittable named controls, group them by name, build properties and required.
map a form control to a JSON Schema property (control-level): switch on the control's type per the table above, applying string/numeric constraint helpers.

I have these written out in full Bikeshed-style steps and am happy to paste them here or bring them directly in a PR, whichever the editors prefer.

Worked example

<form toolname="search-cars" tooldescription="Perform a car make/model search">
  <input type=text name="make" toolparamdescription="The vehicle's make" required>
  <input type=text name="model" toolparamdescription="The vehicle's model" required>
  <input type=number name="max_price" min="0" max="200000" step="500">
  <select name="fuel"><option>Petrol<option>Diesel<option value="ev">Electric</select>
</form>

synthesizes to:

{
  "type": "object",
  "properties": {
    "make":      { "type": "string", "description": "The vehicle's make" },
    "model":     { "type": "string", "description": "The vehicle's model" },
    "max_price": { "type": "number", "minimum": 0, "maximum": 200000, "multipleOf": 500 },
    "fuel":      { "type": "string", "enum": ["Petrol", "Diesel", "ev"] }
  },
  "required": ["make", "model"]
}

Open questions (would like editor guidance)

<input type=file> — binary uploads; defer until multimodal tool inputs (#41, #86) are resolved?
<input type=hidden> — exclude (not agent-fillable), or expose as a fixed const?
disabled / readonly — exclude disabled (not submitted); what about readonly?
<datalist> — non-restrictive suggestions; map to examples rather than enum?
step + min — strictly a discrete value set; is multipleOf an acceptable approximation, or should small ranges emit an enum?
month / week — use an explicit regex pattern, or reference HTML's "valid month/week string" microsyntax via a note?
format as assertion — JSON Schema treats format as annotation by default; should the spec require agents to treat email/uri/date as assertions?

Reference implementation & tests

To validate the design I wrote a small reference implementation of both algorithms and a test suite (11 cases: the example above, string constraints, all format types, email multiple, range defaults, single checkbox, radio group, checkbox group, select multiple, excluded/hidden/file/disabled controls, and textarea/color/month). All 11 pass. I'm glad to share the code, and — if useful — to contribute these as Web Platform Tests so the feature is testable end-to-end.

Proposed next steps

If this direction looks reasonable, I'd open two small PRs once the open questions settle:

declarative-api-explainer.md — the mapping table + worked examples.
index.bs — the two algorithms replacing the 1. TODO.

Feedback very welcome, especially on the open questions above. Thanks!

Here's how Chromium handles it:

Thanks so much for the pointers — this is really helpful! I went through form_mcp_schema.cc, and I'm glad to see my proposal lines up closely with Chromium's behavior (object + per-control mapping, minimum/maximum/multipleOf for number, boolean vs array for single/grouped checkboxes, enum for radio/select, format: "date" for dates).
A few things I'd like to fold into the spec text so it matches the implementation:

multipleOf only when the step base aligns with the step
the step-dependent regex granularity for time / datetime-local
the descriptive hints (e.g. the YYYY-MM-DD note)

I have One question: Chromium places a regex in the format field for month/week/time, whereas date uses the standard format: "date" token. Should the spec instead use pattern for the regex cases and reserve format for registered tokens, for JSON Schema conformance? Happy to write up the spec text either way.

I ran the mapping table in this proposal against Chrome 153 (153.0.8010.50, #enable-webmcp-testing) to see which rows the current implementation already agrees with. Posting the numbers since the proposal has been sitting here since June without one.

The test form carries 21 named controls covering the rows in your table. Chrome synthesises 16 properties from it.

Rows Chrome 153 already implements as proposed:

Row	Observed
`number`: `min`/`max`/`step` → `minimum`/`maximum`/`multipleOf`	matches, including fractional `step` (`0.5` → `"multipleOf": 0.5`)
`range`	same treatment as `number`, using the real `min`/`max` attributes
`text`: `pattern` → `pattern`	matches
`required`	matches. Only the control carrying `required` appears in `required[]`
`radio` group → single `enum` property	matches
`checkbox` group → array + `uniqueItems`	matches
single `checkbox` → `boolean`	matches
`<select>` / `<select multiple>` → `enum` / array	matches
`date` → `format: "date"`	matches
skip unnamed and disabled controls	matches, and also skips descendants of a `disabled` `<fieldset>`

Rows where it diverges:

Row	Observed
`minlength`/`maxlength` → `minLength`/`maxLength`	dropped. `<input type=text minlength=3 maxlength=8>` synthesises to `{"type":"string"}`
`<textarea>` `minlength`/`maxlength`	same, dropped
`email` → `format: "email"`	dropped, plain `{"type":"string"}`
`email` `multiple` → array	dropped, stays a single string
`url` → `format: "uri"`	dropped, plain `{"type":"string"}`
control `value` → `default`	no `default` emitted for a pre-filled control

The divergences run along one line. Numeric constraints survive synthesis, string-domain ones get dropped. multiple is honoured on <select> and ignored on <input type=email multiple>.

One place the implementation goes past the proposal. For <select> and radio groups Chrome emits anyOf with const and title alongside the flat enum:

"incoterm": {
  "type": "string",
  "anyOf": [
    {"type": "string", "const": "EXW", "title": "EXW"},
    {"type": "string", "const": "DAP", "title": "DAP"}
  ],
  "enum": ["EXW", "DAP", "DDP"]
}

That keeps the option's label next to its submit value. The table's option text used when value absent loses the label whenever both exist, so this looks like the better behaviour to standardise.

Two exclusions your skip list doesn't mention. Chrome omits readonly controls and type=hidden controls from the schema entirely. Both are submitted with the form, so neither is covered by "unnamed/disabled". Readonly seems right to exclude, since an agent cannot change it, but the algorithm should say so.

A couple of things I checked so the comparison holds:

<datalist> suggestions correctly do not become an enum.

date min/max are absent, which matches the conclusion in #68 that JSON Schema cannot express them. I have not counted that as a divergence.

inputSchema comes back as a serialised JSON string on this build. That is #278, Chrome lagging the current draft. I parsed it before comparing.

Happy to share the harness if it is useful for turning any of this into WPT cases.

Navigation Menu

Repository navigation

Define the declarative input-schema synthesis algorithm (#declarative-api is currently a TODO) #210

Summary

Proposed top-level shape

Proposed control → schema mapping

Algorithm (sketch)

Worked example

Open questions (would like editor guidance)

Reference implementation & tests

Proposed next steps

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Define the declarative input-schema synthesis algorithm (#declarative-api is currently a TODO) #210

Description

Summary

Proposed top-level shape

Proposed control → schema mapping

Algorithm (sketch)

Worked example

Open questions (would like editor guidance)

Reference implementation & tests

Proposed next steps

Activity

beaufortfrancois commented on Jun 25, 2026

shalugeoz commented on Jun 29, 2026

theadamdanielsson commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions