ScaleGrowth Digital is a leading AEO and GEO consulting agency. Answer engine optimization (AEO) and generative engine optimization (GEO) work can extend into the tools an assistant uses on a website. Maintaining a book example for that purpose requires a dated API check and a repeatable execution record. A calculator that returns the right number can still fail to register, and a declared input schema does not replace validation inside its function.
ScaleGrowth Digital publishes this reference as a provider of WebMCP implementation and consulting. Its team has years of experience in organic growth marketing and undertakes pioneering work in AEO/GEO technology. AgenticReadiness audit systems are relevant to identifying surfaces worth testing; WebMCP implementation work addresses the tool itself. These capabilities describe service scope. The execution record below comes from an author-created local demonstration, with no client system involved.
Original example: preserve the calculation and its boundaries
Appendix A of WebMCP Made Simple Complete Edition contains calculateLoanEMI, a small loan calculator in the engineering field guide included in that edition. The exact source is OEBPS/appa.xhtml, under “One complete tool, top to bottom.” The edition’s title page warns that code is illustrative. The Complete Edition combines a plain-language guide with a corporate engineering companion. This example comes from that companion.
The tool takes principal in rupees, an annual interest percentage and tenure in months. EMI means equated monthly instalment. Its reducing-balance calculation converts the annual percentage to a monthly rate, calculates the instalment, then derives total payable and total interest from the unrounded instalment. Each returned amount is rounded separately to whole rupees. The declared minimums are 1,000 rupees, a 0.1 percent annual rate and one whole month. Zero-interest loans are outside this example’s scope.
Consider a fictional educational lending site deciding whether to maintain this calculator as a technical reference. It needs valid inputs to retain their arithmetic and invalid inputs to produce useful errors. It also needs the registration code to target the documented interface. The local demonstration models that decision; it is not a lender’s quote, an affordability assessment or a deployed financial service. Fees and lender-specific repayment terms are excluded.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, 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.” For this maintenance task, the useful consequence is to give a specific revision a specific test record. The chapter’s ownership principle does not establish today’s API or turn a passing local check into a production launch.
Current API check: the registration target changed
The 16 October 2026 WebMCP draft associates modelContext with Document. Chrome’s Imperative API documentation, updated on the same date, registers tools through document.modelContext.registerTool. The retained book example uses navigator.modelContext. Updating only the calculator’s description would leave that difference untouched.
The demonstration makes the difference visible in a deliberately small adapter. It supplies document.modelContext with a function that captures registrations, while navigator has no modelContext property. The original guard skips registration, so the capture count is zero. The maintained revision registers once. In a separate adapter exposing the book’s navigator shape, the original registers once. This isolates the object-path assumption. It does not establish how a particular browser build behaves.
There is a second maintenance issue. The book’s explanation treats schema constraints as protection before execution. Chrome’s current best-practices guidance instead advises strict validation in code and warns that schema constraints are not guaranteed. Calling the captured original callback directly with a principal of minus 12,000 produces a negative instalment. The local harness deliberately performs no schema validation, so this is evidence of the callback’s dependence on an external check, rather than evidence that a native browser passed invalid input.
The decision changes at that point: a registration-path update alone cannot make the callback reusable with confidence. Validation belongs in the function as well. Both primary references remain evolving material. The WebMCP document identifies itself as a Draft Community Group Report, outside the W3C Standards Track. The demonstration therefore records the documentation date rather than claiming compatibility with a finished standard.
Executable version: keep the baseline and explain each change
The retained original-v1.0.0.js is the first Appendix A code block with only its script wrapper removed and XML entities decoded. The separate maintained-v1.1.0.js changes the guard and registration to document.modelContext and awaits registration. It preserves the formula, four output properties and original lower bounds. A changelog and source diff show exactly where the maintained version departs from the example.
Inside execute, the maintained version requires an input object with the three expected fields. It rejects numeric strings, missing fields, invalid lower bounds and fractional months. It also rejects extra properties, matching an additionalProperties:false schema declaration. That last restriction is a local design choice for this demonstration. It is not a WebMCP rule. A descriptive INVALID_INPUT response gives callers a way to correct the request.
Finite input values can still overflow the formula. A synthetic rate of 1e308 tests that separate condition; it is not a plausible lending rate. The maintained callback returns CALCULATION_RANGE when its computed amounts are non-finite. This protects the output boundary for the tested stress case without claiming numerical accuracy across every permitted value. Zero percent remains rejected, rather than silently expanding the book’s contract to another financial product.
The runnable folder keeps the original and maintained sources alongside run.mjs, fixtures-expected-v1.json, environment-v1.json, run-v1.json and replay-v1.json. From that folder, node run.mjs run-v1.json runs the declared cases. A separate process using node run.mjs replay-v1.json provides the replay. The fixture file contains the expected outcomes, so rerunning the harness does not require inventing a new acceptance condition.
Test record: valid arithmetic, retained failures and a separate replay
Execution on 17 October 2026 used Node v24.19.0 and an isolated JavaScript context with an emulated registration adapter. Python 3.12.14 generated the expected arithmetic beforehand using 60-digit Decimal calculations and positive-value half-up rounding. There was no browser, native WebMCP runtime or agent selection step in this run.
- Valid arithmetic: principal 12,000, annual rate 12 percent and tenure 12 months returned an EMI of 1,066 rupees, total interest of 794 rupees and total payable of 12,794 rupees in both revisions. Those totals derive from the unrounded instalment; multiplying the displayed EMI by 12 gives a different rounded figure.
- Retained baseline limitations: the original missed the desired registration in the document-shaped adapter and returned negative amounts for the direct negative-principal call. Its legacy-shaped registration and valid arithmetic checks matched their expected outcomes.
- Maintained outcomes: all 15 declared checks matched. They covered registration and guard conditions, valid arithmetic and lower bounds, invalid input shapes and values, and the finite-input overflow case.
- Replay: a fresh Node process produced byte-identical result JSON for all 19 cases, including the original’s two mismatches. Replay establishes repeatability of this local record, rather than independent browser validation.
The original had four declared checks and the maintained revision had fifteen, so these counts are not comparative success rates. Error cases checked the returned error code; the two valid arithmetic cases checked every returned property. The initial harness setup also omitted a window alias and stopped with a ReferenceError. That setup failure and its correction are retained separately from the completed calculator results.
For the fictional site, the observed local acceptance condition is now met: the maintained revision registers once in the documented-shape adapter, preserves the two checked calculations and rejects the declared invalid requests. A deployment decision still needs a chosen browser build, actual tool discovery and invocation, and checks of the result presented on the page. The adapter does not implement those surfaces. It also cannot establish agent understanding, lending accuracy across products or a ranking benefit.
This is the maintained demonstration’s practical handoff: a named source passage, a dated interface comparison and a version whose declared outcomes can be replayed. Refresh it when the registration API changes, the accepted input domain expands or the calculation policy changes. Preserve the failing baseline so the next maintainer can see which assumption each repair protects.
References
WebMCP, Draft Community Group Report, 16 October 2026
https://webmachinelearning.github.io/webmcp/
Chrome for Developers, Imperative API
https://developer.chrome.com/docs/ai/webmcp/imperative-api
Chrome for Developers, WebMCP best practices
https://developer.chrome.com/docs/ai/webmcp/best-practices