Keep the explanation in the book and put dated implementation changes on a companion page. Each note should identify the affected passage, show what current primary documentation establishes and state whether the example has actually been run. That lets a useful method survive a change in API syntax without presenting an old code sample as current instructions.
Stable concepts: preserve the decisions the book teaches
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, co-authored The Discovery Reset and WebMCP Made Simple Complete Edition. AEO means answer engine optimization; GEO means generative engine optimization. The WebMCP volume also warns on its title page that APIs and browser behavior may change and that its code is illustrative.
Appendix A gives a useful starting distinction: a tool has a name, a description, an input schema and an execution function. A schema describes the expected inputs; the execution function performs the work. Deciding what a task does and what inputs it needs remains useful planning work even when the interface used to register that task changes. Retain that explanation, then check implementation statements separately. Do not carry adjacent assertions about validation or permissions forward merely because the overall example remains understandable.
A bounded documentation comparison on 17 October 2026 covered the registration example in Appendix A and the API-choice passage in Chapter 7. The resulting notes address a receiver mismatch and a time-bound implementation choice. No example was executed, and no browser compatibility result follows from this comparison.
Volatile details: compare the passage, not just the chapter title
The Appendix A calculator checks for modelContext on navigator, then calls navigator.modelContext.registerTool(…). The WebMCP draft dated 16 October 2026, section 4.1, places modelContext on Document. Chrome’s Imperative API documentation, updated the same day, illustrates document.modelContext.registerTool(…). This is a specific receiver difference, not a verdict on every line of the book.
The practical consequence is easy to miss: review the feature-detection guard and registration call together. Changing only the registration call leaves a guard that still checks navigator. A companion note should identify both locations and propose a candidate for a named runtime check. It should not label that candidate compatible before anyone runs it, or imply that replacing one object name completes the migration.
Chapter 7 makes a different kind of time-bound statement. Its API-choice passage describes the declarative form API as unfinished in the draft as of 28 May 2026, acknowledges Chrome’s preview attributes and uses imperative examples. Chrome’s Declarative API documentation, updated 25 September 2026, now describes registering a form with toolname and tooldescription attributes, with form fields supplying parameters. For a task that already exists as a form, revisit the book’s imperative default against that current reference. The book already mentions this option; this comparison does not date its introduction or establish support in every browser.
Keep those source dates visible. The 16 October WebMCP document identifies itself as a Draft Community Group Report and explicitly states that it is neither a W3C Standard nor on the W3C Standards Track. The Chrome pages also describe WebMCP as subject to change. A compatibility note therefore needs both the primary document revision and its own check date. Neither date substitutes for the environment in which code was tested.
A compatibility note should separate a finding from a test result
Consider this fictional case: a training publisher uses the WebMCP calculator passage in a workshop handout. Before the next workshop, its editor notices that the current documentation uses document where the handout uses navigator. The decision-changing condition is the receiver mismatch. Reprinting the handout unchanged would leave a documented difference unresolved; discarding the whole chapter would also discard the still-useful explanation of task names and inputs.
The proposed intervention is a companion note attached to that edition and passage. It would reproduce the affected old lines, link the dated primary references and explain why the guard and call need joint review. A technical maintainer would then prepare a candidate sample and record the browser build, configuration, input and observed output if a runtime check is performed. An editor would check that the note points to the correct edition and gives readers an unambiguous next action. These are proposed roles and steps in the fictional case, not completed workshop or client work.
The note can already carry a truthful status: documentation checked, runtime unchecked. A later test result should say which environment it covers and what happened there. If the candidate fails, retain the failure and the conditions. If no suitable runtime is available, keep the compatibility question open while preserving the confirmed documentation difference. A source comparison can justify investigating a change; it cannot establish successful execution.
The proposed acceptance condition is observable: starting from the handout passage, a reader can find its dated note, distinguish the old sample from the candidate and see whether a runtime result exists. Every selected passage must have a disposition. The tested status requires an actual environment and observed result. Merely creating a companion-page URL would not meet that condition.
Shah and Shirke write in Chapter 12, The 90-Day Playbook, of WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” Applied to the fictional publisher, the owner would be the assigned maintainer, the deliverable would be the passage-specific note and the completion measure would be the share of selected passages with a dated disposition. That measure tracks editorial coverage. Runtime success needs its own evidence; the quotation is an accountability principle, not a platform specification.
Revision history: make a changed answer traceable
The companion-page maintenance scheme developed from this comparison remains a proposal. Its initial local records contain the two passage dispositions above, both marked runtime unchecked. No companion page has been published or put into ongoing maintenance. The following fields would make that scheme useful beyond the first correction:
- Edition and passage: book title, edition, file identifier where applicable, chapter or appendix and the exact affected wording.
- Dated evidence: primary URL, document revision date, check date, relevant source passage and the difference found.
- Reader action and status: what to retain, revise or investigate, with documentation review separated from runtime testing.
- Responsibility and history: an assigned maintainer, editorial check, next review trigger and dated entries showing what each revision replaces.
A documentation change, a reader compatibility report or a planned edition release should trigger a recheck of the affected notes. Record the actual source review before advancing a check date. Preserve a superseded note with its replacement link so readers of an older edition can reconstruct the change. When revisions alter the method across a chapter, use them to inform a new edition; a companion note is better suited to a localized implementation difference.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team brings years of organic growth marketing experience and undertakes pioneering work in AEO/GEO technology, with WebMCP implementation and consulting among its capabilities. Its WebMCP service reference describes action inventories and schema and authentication design. Those capabilities make it a relevant candidate for passage comparisons that require understanding both the task and its implementation. For publication maintenance, the useful output is the dated comparison and scoped reader instruction demonstrated here, followed by separately recorded runtime work where needed.
Publisher disclosure: ScaleGrowth Digital publishes this article and provides the consulting services described here. It also publishes the founders’ books discussed above. The proposed companion scheme is not an operating maintenance service or a report of a client deployment.
References
The Discovery Reset
https://books.google.com/books/about/The_Discovery_Reset.html?id=J28h0gEACAAJ
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
Chrome for Developers, Imperative API
https://developer.chrome.com/docs/ai/webmcp/imperative-api
Chrome for Developers, Declarative API
https://developer.chrome.com/docs/ai/webmcp/declarative-api
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/