Fix typos and Markdown formatting in the explainer docs

README.md

@@ -334,7 +334,7 @@ By default, WebMCP is enabled in top-level `Window`s and its same-origin iframes
 
 Calls to `document.modelContext.registerTool()` will return a promise rejected with `NotAllowedError` DOMException when the permission is disabled, whether by the `allow` attribute or the `Permissions-Policy: tools=()` header. Handling of declarative tool registration errors, including when the permission is disabled is TBD; see [Issue #182](https://github.com/webmachinelearning/webmcp/issues/182).
 
-#### Cross-origin iframe exposure: `registerTool() and `exposedTo`
+#### Cross-origin iframe exposure: `registerTool()` and `exposedTo`
 
 By default, tools registered by a document are only exposed to itself, same-origin documents in the same tree, and built-in browser agents (see this <a href=#built-in-agent-default-exposure>discussion</a>). To support author-provided agents running in frames, developers can selectively share tools with specific secure origins via the `exposedTo` option:
 

declarative-api-explainer.md

@@ -88,8 +88,8 @@ await document.modelContext.registerTool({
 
 ```html
 <form toolname="search-cars" tooldescription="Perform a car make/model search" [...]>
- <input type=text name="make" toolparamdescription="The vehicle's make (i.e., BMW, Ford)" required>
- <input type=text name="model" toolparamdescription="The vehicle's model (i.e., 330i, F-150)" required>
+ <input type=text name="make" toolparamdescription="The vehicle's make (e.g., BMW, Ford)" required>
+ <input type=text name="model" toolparamdescription="The vehicle's model (e.g., 330i, F-150)" required>
  <button type=submit>Search</button>
 </form>
 ```
@@ -107,7 +107,7 @@ cancellation.
 
 TODO: The exact algorithms reducing a form, its form-associated elements, and *their* attributes
 like [`step`](https://html.spec.whatwg.org/C#the-step-attribute) and
-[`min`](https://html.spec.whatwg.org/C#attr-input-min) is TBD. We need to concretely specify how
+[`min`](https://html.spec.whatwg.org/C#attr-input-min) are TBD. We need to concretely specify how
 various form-associated elements like `<input>` and `<select>` reduce to a JSON Schema that includes
 `anyOf`, `oneOf`, and `maximum`/`minimum` declarations.
 
@@ -124,7 +124,7 @@ This topic is currently under debate; see https://github.com/webmachinelearning/
 When a form element performs a navigation, the first `<script type=application/ld+json>` tag on the
 target page is used as the cross-document tool's "response" that gets sent to the model.
 
-When no such a tag is present, probably we'll decide that the page's entire contents is sent to the
+When no such tag is present, probably we'll decide that the page's entire contents is sent to the
 model as the response, since that's an accurate semantic representation of the result of the tool.
 However, this is technically TBD at the moment.
 
@@ -156,7 +156,7 @@ element.
 
 **Additions to `SubmitEvent`**
 
-The `SubmitEvent` interface gets two new members, `agentInvoked` to let `submit` event handler react
+The `SubmitEvent` interface gets two new members, `agentInvoked` to let `submit` event handlers react
 to agent-invoked form submissions, and the `respondWith()` method.
 
 This method takes a `Promise<any>` that resolves to the response that the agent will consume. This
@@ -172,7 +172,7 @@ interface SubmitEvent : Event {
 };
 ```
 
-**`toolactivated` and `toolcanceled` events
+**`toolactivated` and `toolcanceled` events**
 
 We introduce these events that get fired at the `ModelContext` object when a WebMCP tool is run, and when
 its invocation is canceled.

docs/service-workers.md

@@ -14,7 +14,7 @@ Sometimes, an agent may require context and tools from a site that the user does
 
 ## TL;DR
 
-This explainer describes a means for web sites to register service workers as WebMCP providers. Tool calls are handled in the service worker script where the web developer can handle the call directly, without needing to open any browser windows. If a tool requires user interaction though, the web developer can have their tool's execute function open a browser window and communicate with it via postMessage; For example, to let the user take care of sensitive steps like payment, or to present purchase confirmation.
+This explainer describes a means for web sites to register service workers as WebMCP providers. Tool calls are handled in the service worker script where the web developer can handle the call directly, without needing to open any browser windows. If a tool requires user interaction though, the web developer can have their tool's execute function open a browser window and communicate with it via postMessage; for example, to let the user take care of sensitive steps like payment, or to present purchase confirmation.
 
 ## Use Cases
 
@@ -135,7 +135,7 @@ The output of this hypothetical discovery step is the URL of a web app manifest
 
 Service workers have a new `modelContext` object available in their global scope; the service worker counterpart of the `document.modelContext` object specified in the main WebMCP explainer. When the service worker is activated, the worker script can call the `modelContext` object's methods to register tools with the browser. These tools are then available for use by in-browser AI agents.
 
-Tools are scoped to the service worker and origin that created them, so it's not possible for a single app to squat common tool names like "search" or "add-to-cart". On the agent side, each conversation should have a limited set of WebMCP service workers connected which are relevant to the topic of the conversation. This prevents giving the agent more privileges than necessary and conserves the LLMs limited context window. Service worker selection may happen either automatically based on the agent's suggestions or manually based on user configuration. If two or more WebMCP service workers with similar tools and purposes are enabled in the same conversation, then agents may resolve the ambiguity by asking the user to pick one and remember their preference; much like how users choose a default browser for their OS. 
+Tools are scoped to the service worker and origin that created them, so it's not possible for a single app to squat common tool names like "search" or "add-to-cart". On the agent side, each conversation should have a limited set of WebMCP service workers connected which are relevant to the topic of the conversation. This prevents giving the agent more privileges than necessary and conserves the LLM's limited context window. Service worker selection may happen either automatically based on the agent's suggestions or manually based on user configuration. If two or more WebMCP service workers with similar tools and purposes are enabled in the same conversation, then agents may resolve the ambiguity by asking the user to pick one and remember their preference; much like how users choose a default browser for their OS. 
 
 The complete flow, including JIT installation of service workers, is illustrated below. The Discovery Layer is a placeholder for now. It represents some entity that can recommend apps. Some possibilities for the discovery layer are described in Appendix A.
 
@@ -216,7 +216,7 @@ In any case, a single tool call is never routed to more than one server, even if
 
 ## Session Management
 
-To implement certain kinds of multi-step workflows, it may be necessary for the service worker to maintain separate state for each client. For example, consider a user that has started two separate conversations with their browser's AI assistant; one to shop for birthday gifts, and one to shop for groceries. In both conversations, the assistant agent is interacting with the same shopping site through its service worker. Since tool calls from both conversations are handled centrally in the same service worker script context, the tool calls need to carry some kind of unique identifier (think session ID) so that the service worker can maintain two separate shopping carts and ensure that it reads/write to the correct one depending on which conversation (i.e. session) the tool request came from.
+To implement certain kinds of multi-step workflows, it may be necessary for the service worker to maintain separate state for each client. For example, consider a user that has started two separate conversations with their browser's AI assistant; one to shop for birthday gifts, and one to shop for groceries. In both conversations, the assistant agent is interacting with the same shopping site through its service worker. Since tool calls from both conversations are handled centrally in the same service worker script context, the tool calls need to carry some kind of unique identifier (think session ID) so that the service worker can maintain two separate shopping carts and ensure that it reads/writes to the correct one depending on which conversation (i.e. session) the tool request came from.
 
 A solution would be to add a Session ID to tool calls and include this information as a parameter to tools' execute functions. Now, when a tool call is handled, the function has both the input parameters of the tool call, and client info with a session ID which it can use to cache state unique to that session (i.e. the user's shopping cart in the example above).