[kenchris]

Adds openWorldHint, which is asked for in #53 (and in #119, closed as a duplicate). MCP has the annotation, but commenters found its wording vague, so this defines it: the tool may send data to, or read data from, parties other than the origin of the page that registered it.

An agent can use it before a call, for example to decide whether the arguments get checked for secrets because they might leave the origin. It can use it after a call too, because the result may carry content from a third party.

Unlike the other hints it defaults to true, as it does in MCP, so a tool that doesn't declare it is treated as open to the world. That default is the part most likely to change. #53 is discussing whether hints should have defaults at all, and if they go, this one goes with them.

This used to be two commits. The note about omitted hints is split out into #358, since the defaults question is still open.

Not included: destructiveHint (consequentialHint covers much of it, see #331) and a retry safety hint (still open in #53).

Built locally with Bikeshed with no warnings.

---

Preview | Diff

[jpagnucco]

Hi Ken, a couple of questions:

1. What does destructiveHint provide us that consequentialHint does not? Consequential hint is basically our version of destructive hint, but extended a bit since every consequential action is not necessarily destructive. See Hint for reversible or consequential actions #176

2. I believe open world hint could be covered by consequential + untrusted content hint? Trying to reason about additional mitigations an agent would take with openWorld that it would not with these two other hints.

[kenchris]

Thanks for looking at it. On the first one, destructiveHint is an official MCP annotation, which is why it came up. I left it out of this PR because I agree consequentialHint covers most of what it says, and I didn't want to add two hints for nearly the same thing. The one place it matters is agents or extensions that bridge WebMCP tools into MCP clients, since they would have to map consequentialHint onto destructiveHint and that mapping loses a bit (consequential is wider). I think a note in the spec on how they map would be enough, and I don't think we need a second hint.

For openWorldHint I think it's only partly covered by the other two. The direction where it's the same is what comes back. If a tool reads from other parties, untrustedContentHint already tells the agent to treat the result carefully, so there I don't think open world adds anything.

The part I don't see covered is data going out. Take a read-only search tool that sends the query to a third party API. It has no side effects, so I wouldn't expect it to be marked consequential, and its output being untrusted says nothing about what the arguments can leak. What an agent or a guardrail would do differently with open world is check the arguments before the call, for secrets or for data that came from another origin, because they leave the page's origin. That check is a different mitigation from asking the user before something with side effects, and from sanitizing the result.

It also helps to know which calls to check. Exfiltration checks on arguments are not free and they produce false alarms, so being able to run them only on tools that can reach other parties is a real difference in practice. Without the hint a guardrail has to check everything, or guess.

A page can of course lie about it, but I think it still works. If a site says a tool may talk to third parties, you can always act on that. If a site you already trust, say Shopify, says it doesn't, that is a statement you can reasonably rely on. For a site you know nothing about, "closed" would just not lower the checks.

So if it stays, I think it should be narrowed to that outbound meaning, and maybe renamed to say so. If people feel that is too small to justify a new hint, I'm fine with dropping the second commit and keeping just the note about omitted hints.

[kenchris]

@jpagnucco regarding the destructiveHint. It is used in MCP and I expect some developers to add it to their definitions just due to that, but WebIDL will ignore it and that information is then lost. Maybe we should add a note instead:

Note: Tools that were first written for MCP can carry a destructiveHint. It is not a member of {{ToolAnnotations}}, so it is dropped when the dictionary is converted and no [=agent=] sees it. A [=user agent=] that wants to keep what the author meant can read a true destructiveHint as a true {{ToolAnnotations/consequentialHint}}, which is the wider of the two. Hosts that bridge these tools back to MCP lose a little the other way, since a consequential tool is not always destructive.

I can do that in a separate PR if you would want that.

Or, do you want me to file an issue about it?