Registering a tool and subscribing to tool changes arrive on the same object, so they read as one capability. They are not. `addEventListener` comes from `EventTarget`, and whether a client's `modelContext` inherits from `EventTarget` is an implementation decision separate from whether it implements `registerTool` and `getTools` [4]. Nothing in the shape of the returned object records which choices were made. The line most people will write, `!!(modelContext && 'registerTool' in modelContext)`, tests one property and generalises past it not at all [3].
The cost of getting that wrong is set by where the throw lands. In the write-up's app, `boot()` awaited `start()`, so the TypeError arrived after the page had painted: a fully rendered page that then announced it had failed to start [5]. That is the one bug shape a screenshot cannot explain.
The timing lesson is harder to design around. WebMCP has a declarative form, where `toolname` on a `<form>` makes the browser adopt the form as a tool, and removing the attribute removes the tool [7]. Adoption happens when the browser notices the DOM change, and there is no promise to await [8]. Where `toolchange` fires, the event tells you the surface has settled and you re-render [8]. Where it does not, the render triggered by a state change reads a surface that is still moving. In this app one state change drops eight tools at once, seven by aborting an `AbortSignal` and one by dropping an attribute [7][17], so the window is wide enough to be visible on screen.
Twelve ticks at 50 ms is a 600 ms worst case before the poll gives up, which matches the roughly 600 ms bound the author quotes [11][12]. A tick that finds a count different from what was rendered re-renders instead of sleeping, and that render re-arms the poll [11].
The verification is the part worth reproducing before trusting it. According to the post, the local build was served under the live origin so the origin-trial token still applied, with `addEventListener` stripped off `modelContext` to imitate the client's shape, and both shapes returned 5 / 17 / 15 / 9 tools at four checkpoints with zero divergences and zero page errors [13]. That result transfers only if the missing `EventTarget` is the only relevant difference between the real client and the local mock. If ChatGPT's browser also adopts declarative tools on a slower schedule than Chrome does, a 600 ms ceiling tuned against a stripped local object is a guess about someone else's scheduler.
There is one more default to read before shipping. Passing `executeTool` the object the IDL specifies returns `UnknownError: Failed to parse input arguments` on Chrome 151 [14]. The author's rule is to send the string and keep the object path as a fallback, which is correct today and on the day Chrome converges [16].
The product's claim was that the panel cannot disagree with the API, because the left column is rendered from `getTools()` [10]. In one client they disagreed [10], and the response was to scope the claim in the UI rather than delete it: the banner now states that tools registered, that this client's `modelContext` is not an `EventTarget`, and that there are therefore no `toolchange` events [6]. Naming the mechanism that is carrying you is cheap, and it is the only part of this that survives the next client.
