Set tool controls according to what a call can expose and what it can change. A read-only tool needs limits on data access and disclosure. A transaction tool needs those limits plus authorization for the specific change, protection against duplicate execution, and a recovery path. Asking for confirmation on every call does not establish any of these boundaries.
Start with the read-only task
Illustrative use case: a repair-estimate portal. A workshop wants an assistant to explain a customer’s estimate and, separately, authorize the repair. The two proposed owned tools are read_estimate and approve_repair. This is a design example, not a reported customer implementation.
read_estimate would accept an estimate identifier and return the permitted repair items, estimate version, total, currency, expiry and approval status. It would leave approval state unchanged and create no work order. The customer could compare the scope and price without committing to the repair.
Read-only does not mean public. An estimate can reveal private vehicle and service information. The backend should establish which customer is making the request, check access to that particular estimate, and return only the fields needed for the explanation. Passing another customer’s estimate identifier must not reveal their record. OWASP’s Authorization Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege and permission checks on every request, including checks for the specific object being accessed.
The implementation work starts inside the callback and its downstream services. Trace which records it reads and which functions it invokes. If a supposed preview also reserves a workshop slot or changes approval status, its name does not make it read-only. Either remove that effect from the preview or classify and control the effect explicitly.
Find the point where the task changes business state
approve_repair would move an eligible estimate from awaiting approval to approved and create a work order. Its description should state both effects. A vague label such as “finish estimate” obscures the moment when looking at a price becomes authorizing work.
The decision-changing fact in this example is that the workshop can revise an estimate before approval. Permission to read the estimate therefore cannot stand in for permission to approve whichever version happens to exist later. The approval must identify the customer, estimate version, agreed repair scope and total.
Chrome’s WebMCP tool security guidance (https://developer.chrome.com/docs/ai/webmcp/secure-tools) recommends readOnlyHint for tools that do not change state and consequentialHint for significant or non-reversible actions, so the agent or browser can request confirmation. It also warns that read-only tools can reveal user information. These annotations communicate behavior; the backend still needs to enforce access and approval rules.
The WebMCP draft (https://webmachinelearning.github.io/webmcp/) explicitly identifies a gap between declared tool intent and actual behavior. Its text dated 16 October 2026 is a Draft Community Group Report, not a W3C Standard. Document the API revision and runtime used when implementing these hints, rather than assuming identical behavior across browsers and agents.
Build a control matrix around the two tools
A useful control matrix maps the same control dimensions to each tool. For the repair portal, its proposed entries would be:
- Data access: read_estimate reads the customer’s permitted estimate fields. approve_repair reads that estimate plus the authorization record needed to approve it. Neither tool accepts a caller-supplied customer identity as proof of access.
- Business effects: read_estimate leaves approval and work-order state unchanged. approve_repair changes the estimate status and creates one work order for the authorized version.
- Confirmation: read_estimate needs an allowed purpose and data access. approve_repair additionally requires explicit approval of the displayed repair scope, version and total before commitment.
- Retries: read_estimate can fetch the latest permitted view again. approve_repair must recognize a retry of the same operation and return its recorded outcome without creating another work order.
- Recovery: a failed read must not expose another estimate or trigger approval. An approval needs an operation-status record and a defined route to request cancellation, subject to whether workshop work has begun.
These entries would need to be checked against the real implementation. If read_estimate reaches a broader customer record, or approve_repair also sends a notification, the matrix must record that behavior. Leaving out a downstream effect makes the controls narrower than the action they are supposed to govern.
Confirm the exact repair that will be authorized
The confirmation view should be generated from the server’s estimate record and identify the repair scope, total and currency, estimate version, and consequence of approval. “Continue” does not tell the customer whether the next call will merely display an estimate or release work to the workshop.
OWASP’s Transaction Authorization Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) recommends server-side enforcement, acknowledgement of significant transaction details, and a final authorization check tied to execution. It also describes invalidating authorization when transaction data changes. Applied here, an approval for an earlier estimate must not authorize revised work.
For example, if the workshop adds a repair item after the customer sees the estimate, approve_repair should reject the stale version and return a changed-estimate result. The portal would then show the revised scope and request fresh approval. This prevents the customer’s agreement to one repair from being applied to a different repair.
Keep a time-limited approval record on the server, bound to the customer and estimate version. A parameter such as confirmed=true is a statement from the caller, not sufficient proof that the required approval occurred. The backend should check the current version, validate the approval record and commit the permitted state transition together, so an estimate revision cannot slip between the check and approval.
Permissions must survive retries and recovery
The same backend rules should govern the human interface and the tool callback. Hiding the approval button or omitting the tool from a menu cannot be the decisive access check. A customer allowed to read an estimate might still lack authority to approve it, for example where a separate account holder must authorize work. That distinction belongs in the permission rules for the example.
Design the approval operation to handle an uncertain response. Suppose the server creates the work order but the connection closes before the assistant receives the result. Starting a new approval could create duplicate work. For this portal, save a unique operation identifier, its bound request details and its outcome atomically with the approval transition and work-order creation. Enforce a unique work order for the estimate. A matching retry would return that outcome. Reuse of the identifier with different details should be rejected. The Amazon Builders’ Library guide to idempotent APIs (https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) describes this request-identifier and atomic-write pattern. Here it remains proposed backend work, not behavior supplied automatically by WebMCP.
Stopping the assistant also needs a precise meaning. The WebMCP draft describes an AbortSignal that communicates cancellation of tool execution. Treat that signal separately from undoing a business action. In this example, a recorded approval would remain approved until an authorized cancellation changes its state. If work has started, the recovery route might require workshop intervention because completed labor cannot be undone by closing a browser.
Check state changes, not just return messages
The proposed verification environment for this example is isolated staging, synthetic customer accounts and a stubbed workshop queue that cannot release real repairs. Record the application revision, browser build, WebMCP settings and agent or client version actually used. The findings would apply to those recorded paths and versions; they would not establish production behavior.
The observable conditions follow directly from the matrix. Reading an allowed estimate must return its permitted fields while leaving approval and work-order records unchanged. Reading another customer’s estimate must reveal none of its protected fields. Approval without valid authority, with an expired approval record, or against a changed estimate must create no work order. A valid approval must produce the expected approved version and one work order, including after a matching retry.
Exercise the callback directly to check backend rejection, then run the assistant task to check selection and confirmation. Chrome’s WebMCP debugging documentation (https://developer.chrome.com/docs/devtools/application/webmcp) notes that manual tool invocation can bypass agent decision logic. A successful direct call therefore cannot establish that the assistant chose the right tool or requested the required approval.
Retain dated inputs, outputs, confirmation details, redacted authorization decisions and before-and-after state records for each case. Add the operation identifier and work-order reference so a lost-response retry can be reconciled. A “success” message without the matching state record would leave the central question unanswered: what did the call actually change?
Give the boundary an accountable owner
ScaleGrowth Digital publishes this article and provides WebMCP implementation and consulting (https://scalegrowth.digital/services/webmcp/), alongside AgenticReadiness audit systems. Its team has years of experience in organic growth marketing and undertakes technology work in answer engine optimization (AEO) and generative engine optimization (GEO). ScaleGrowth Digital is a leading AEO and GEO consulting agency. For the repair portal, those capabilities are relevant to mapping the two tools, clarifying their descriptions and specifying the access and action controls that implementation must enforce.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in WebMCP Made Simple Complete Edition, Chapter 12, “The 90-Day Playbook”: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.”
Applied to this example, assign the implementation engineer ownership of the two-tool control matrix and its supporting test records. An editor would check that the descriptions and confirmation text express the same effects the engineer maps. One proposed release measure is the number of defined authorization-failure cases that still create a work order: it must be zero. Keep the individual case results, because that number covers only the declared cases. The deliverable would then show where reading ends, where commitment begins, and how the application enforces the difference.
References
Authorization Cheat Sheet, OWASP
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
WebMCP tool security, Chrome for Developers
https://developer.chrome.com/docs/ai/webmcp/secure-tools
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
Transaction Authorization Cheat Sheet, OWASP
https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html
Making retries safe with idempotent APIs, Amazon Builders Library
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
WebMCP debugging documentation, Chrome for Developers
https://developer.chrome.com/docs/devtools/application/webmcp
ScaleGrowth Digital WebMCP services
https://scalegrowth.digital/services/webmcp/