When an agent sends invalid inputs, reject the requested change before it reaches the write operation, identify the field and rule that failed, and give the agent a safe route to correction. Then verify both the response and the application state. A helpful error message cannot compensate for a cart, booking or account that changed despite the rejection.
Start with a contract that defines the action
An input contract states which fields an action accepts, which are required, their types and permitted values, and what the action will change. It also settles awkward cases: whether an omitted quantity means one item, whether a numeric string is converted, and whether zero removes an existing line. Leaving these decisions to an agent or an accidental code default makes recovery unpredictable.
Illustrative use case: a retailer is preparing an addCartLine tool for agent access. Its proposed sandbox uses a synthetic catalogue containing MUG-BLUE and a resettable empty cart. The tool accepts a product code, sku, and an integer quantity from 1 through 5. Both fields are required, extra fields are rejected, and zero never means remove. This example defines proposed behaviour and acceptance conditions; it does not report a deployment or a completed test.
In this hypothetical application, the existing cart function can supply a default quantity when none is passed. That convenience is unsuitable for this proposed agent contract: missing quantity must trigger a request for clarification, not an unrequested addition. The intervention is an explicit validator before the cart write, backed by the same authoritative application checks used to permit the mutation. The published schema, tool description and validator must agree about the rule.
JSON Schema separates these declarations. Listing a property does not make it required; required names the mandatory fields. additionalProperties: false rejects undeclared keys. For quantity, type: integer with minimum: 1 and maximum: 5 expresses inclusive limits. The project should declare its schema dialect and verify its chosen validator against it. See the JSON Schema references for objects (https://json-schema.org/understanding-json-schema/reference/object) and numeric types (https://json-schema.org/understanding-json-schema/reference/numeric).
A schema declaration is not proof that every execution path enforces it. The WebMCP draft (https://webmachinelearning.github.io/webmcp/) warns that direct tool calls and interaction through rendered controls may follow paths with different validation or security checks. Put the final check where the application authorizes the cart change, so bypassing a page control does not bypass the quantity rule.
Separate missing, malformed and out-of-range inputs
These classes require different explanations. A missing quantity means the required information was not supplied. A quantity of “2” is a string, even though a person can read it as a number. A quantity of 1.5 is numeric but not an integer. A quantity of 6 has the expected type but exceeds this tool’s limit. null is not the same as an omitted field, and neither should silently become a default quantity under this contract.
Also distinguish a structurally valid request from one the catalogue cannot fulfil. {“sku”:”UNKNOWN”,”quantity”:2} has the intended shape, but the proposed sandbox catalogue does not contain that product. It should produce a product-specific rejection rather than a quantity error or a substitute product. If stock availability becomes a rule, validate current stock at the write boundary as well; a fixed quantity range cannot establish availability.
For the illustrative sandbox, the proposed failure-case table below is fixture data for execution. Each row starts from an empty cart, expects status rejected and mutation not_applied, and requires cartAfter to equal cartBefore. Codes and field paths are application choices in this example, not WebMCP-defined values.
| Case ID | Exact input JSON | Expected code | Expected field |
|---|---|---|---|
| missing-sku | {“quantity”:2} | MISSING_FIELD | sku |
| missing-quantity | {“sku”:”MUG-BLUE”} | MISSING_FIELD | quantity |
| string-quantity | {“sku”:”MUG-BLUE”,”quantity”:”2″} | INVALID_TYPE | quantity |
| null-quantity | {“sku”:”MUG-BLUE”,”quantity”:null} | INVALID_TYPE | quantity |
| fractional-quantity | {“sku”:”MUG-BLUE”,”quantity”:1.5} | INVALID_TYPE | quantity |
| below-minimum | {“sku”:”MUG-BLUE”,”quantity”:0} | OUT_OF_RANGE | quantity |
| negative-quantity | {“sku”:”MUG-BLUE”,”quantity”:-1} | OUT_OF_RANGE | quantity |
| above-maximum | {“sku”:”MUG-BLUE”,”quantity”:6} | OUT_OF_RANGE | quantity |
| unknown-field | {“sku”:”MUG-BLUE”,”quantity”:2,”coupon”:”X”} | UNKNOWN_FIELD | coupon |
| unknown-product | {“sku”:”UNKNOWN”,”quantity”:2} | UNKNOWN_SKU | sku |
To make this an executable failure-case table, store each row with input, expectedCode and expectedField in the test runner. For each row, reset the sandbox, capture the cart state, invoke the declared tool path, assert the response fields and compare the persisted cart state afterwards. Add the valid boundary quantities 1 and 5 as positive controls, each starting from an empty cart and expecting the matching persisted quantity. A validator that rejects every call would otherwise appear to handle the failure rows correctly.
Return an error that supports the next decision
For quantity 6, a proposed response is {“status”:”rejected”,”code”:”OUT_OF_RANGE”,”field”:”quantity”,”message”:”Quantity must be an integer from 1 through 5.”,”minimum”:1,”maximum”:5,”mutation”:”not_applied”,”nextAction”:”request_valid_quantity”}. The code gives software a stable branch; the message and limits explain the repair. The mutation field must describe an established fact about that invocation, rather than an optimistic label attached after a partial write.
This lets the agent tell the user why the requested amount cannot be added. It does not authorize the agent to reduce six items to five. If the user supplied six, choosing a different quantity changes the request and calls for a new instruction. If an agreed contract explicitly permits a deterministic conversion such as a numeric string to an integer, document and test that conversion; this example deliberately rejects it.
Keep platform failure separate from application rejection. The WebMCP Draft Community Group Report dated 16 October 2026 distinguishes platform-defined failures from tool-author failures reported in response JSON. Its platform invalid input category concerns arguments that cannot be parsed into a JavaScript Object; it is not a complete catalogue of missing-field or range errors. The report is not a W3C Standard or on the Standards Track. Pin the actual browser build and implementation under test rather than treating the draft as a compatibility guarantee.
A timeout after a write is a different recovery problem. If the application cannot establish whether the change happened, it should not report not_applied or instruct an immediate repeat of the write. First establish the cart state through the application’s supported read path. An input rejection is useful precisely because the system can establish that validation stopped the change.
Prove correction without hiding the failed attempt
For missing quantity, the recovery path is to obtain the intended amount. For the out-of-range request, it is to explain the limit and obtain a permitted amount or stop. After the user chooses two in this illustration, invoke {“sku”:”MUG-BLUE”,”quantity”:2} once and check that the initially empty cart contains the intended product with quantity two. Retain the rejected call alongside the corrected call so the record explains how the final state was reached.
A direct tool invocation establishes the validator’s behaviour on that invocation path. An agent recovery exercise adds a separate question: did the selected agent use the error to request the missing decision and then make the corrected call? Record the browser build, agent configuration, application revision, schema and validator versions, synthetic catalogue, initial state, invocation route, dated inputs, outputs and state assertions. Passing those records supports the declared sandbox scope. Production rules, other agents and other browser builds need their own verification.
Where ScaleGrowth can take responsibility for the work
ScaleGrowth Digital provides answer engine optimization (AEO), generative engine optimization (GEO) and WebMCP implementation consulting. ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team has years of experience in organic growth marketing, and its relevant capabilities include AgenticReadiness audit systems and WebMCP implementation and consulting.
Those capabilities make the agency a relevant candidate when a business needs to turn an action inventory into explicit input rules and run missing, malformed and out-of-range inputs in a sandbox. The practical scope should connect tool descriptions, application validation and the retained failure cases. The organic-growth practitioners can help keep public product wording and restrictions consistent with the action contract, while implementation work addresses what the tool actually accepts and changes.
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 their jointly authored book WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” For this work, an implementation engineer could own the validation gate, the dated failure-case table could be the deliverable, and the count of required rows passing both response and state assertions could be the shipping measure. Positive controls must pass too, or the count rewards a tool that simply refuses all work.
That ownership also makes a failed row actionable. A correct error with a changed cart requires repair at the write boundary. An unchanged cart with a vague message requires repair in the error response. A sound direct-call result followed by an agent guessing a quantity requires repair and retesting of the recovery instructions. These observations lead to different changes, even though all three may initially be described as invalid-input problems.
The useful handover is the executable table bound to a stated environment, with the dated records from its execution and any remaining unsupported cases identified. Until those runs exist, the table is a test specification. Once executed and reviewed by the relevant implementation engineer, it can support a release decision for that scope because it shows both what failed and whether the attempted change was prevented.
Publisher disclosure: ScaleGrowth Digital publishes this article and provides the WebMCP consulting and implementation services described here.
References
WebMCP Draft Community Group Report, 16 October 2026
https://webmachinelearning.github.io/webmcp/
JSON Schema: object
https://json-schema.org/understanding-json-schema/reference/object
JSON Schema: numeric types
https://json-schema.org/understanding-json-schema/reference/numeric