Conversation
domfarolino
force-pushed
the
declarative-api-explainer
branch
from
b03b258 to
f8a6998
Compare
domfarolino
force-pushed
the
declarative-api-explainer
branch
from
f8a6998 to
77553aa
Compare
|
The proposal looks great! its exactly what i have in mind to support as additional tools via |
|
@bwalderman, @mfreed7, and @bvandersloot, could you take a look? |
|
|
||
| ### Getting the form response to the agent | ||
|
|
||
| TODO: Mention application/json-ld responses, and so on. |
There was a problem hiding this comment.
I'm curious for more info on how you envision this. If you mean dropping additional information into a <script type="application/ld+json"> on the form navigation's result, I think that is a good direction.
|
|
||
| It is TBD how *declarative* WebMCP tools will be exposed to any interface that exposes a site's | ||
| tools to JavaScript. See https://github.com/webmachinelearning/webmcp/issues/51 for context. Should | ||
| a declarative WebMCP tool be able to be invoked from such an interface, should it exist in the |
There was a problem hiding this comment.
Probably? But I understand the caution.
|
|
||
| It's an open question as to whether [an | ||
| `outputSchema`](https://github.com/webmachinelearning/webmcp/issues/9) makes sense for declarative | ||
| WebMCP tools, and therefore if the `agentResponse` Promise passed to `SubmitEvent#respondWith()` |
There was a problem hiding this comment.
This also relates to the issue of who owns schema validation.
Inferring the output schema is impossible? So we'd have to permit it in the form attribute. Not impossible, but potentially very bulky.
| while `tooldescription` is analogous to | ||
| [`ModelContextTool#description`](https://webmachinelearning.github.io/webmcp/#dom-modelcontexttool-description). | ||
|
|
||
| The `toolautosubmit` [boolean attribute](https://html.spec.whatwg.org/C#boolean-attribute), lets the |
There was a problem hiding this comment.
I like this.
Here is where integration with visibility of form elements could also be interesting. If you require the user to review a form before clicking submit, why do you let agent fill things in that the user could not see.
Being in the control of the site, it can't be a prompt injection protection, but we can help a site build tools that an agent is less likely to misuse, and this fits that well.
|
|
||
| ### Input schema synthesis | ||
|
|
||
| TODO: The exact algorithms reducing a form, its form-associated elements, and *their* attributes |
There was a problem hiding this comment.
Devil is in the details here, but careful specification/testing should be sufficient to get something right.
| creates a new declarative WebMCP tool whose input schema is generated according to | ||
| [Input schema synthesis](#input-schema-synthesis). | ||
|
|
||
| We also introduce the new `toolparamname` and `toolparamdescription` attributes, which apply to form |
There was a problem hiding this comment.
Chromium currently uses toolparamtitle, not toolparamname
|
|
||
| ```html | ||
| <form toolname="search-cars" tooldescription="Perform a car make/model search" [...]> | ||
| <input type=text toolparamname="make" toolparamdescription="The vehicle's make (i.e., BMW, Ford)" required> |
There was a problem hiding this comment.
FYI Here's what Chromium currently have:
- The optional
toolparamtitleattribute maps to the json-schema property key. If omitted, the browser defaults to the input element’s name. - The optional
toolparamdescriptionattribute maps to the property description within the json-schema. In its absence, the browser uses the textContent of the associated HTML element but skips descendants that are labelable or, if no label exists, the aria-description.
|
|
||
| ```html | ||
| <form toolname="search-cars" tooldescription="Perform a car make/model search" [...]> | ||
| <input type=text toolparamname="make" toolparamdescription="The vehicle's make (i.e., BMW, Ford)" required> |
There was a problem hiding this comment.
I think you'd want to remove toolparamname for now, and use name="model" and name="make" instead.
5 participants
This is a follow-up of #26 to address #22. Note that #26 has been superseded by this PR, per #26 (comment).