When a required field is missing, an agent should preserve the inputs it already has, pause the action that would create or change a record, and ask for the missing choice. It should validate the answer before resuming. A value that passes validation is not necessarily a value the user chose: silently inserting an allowed default can still produce the wrong request.
A missing format is an unanswered choice
Illustrative fictional use case: an equipment supplier offers a form for requesting a compatibility report. The customer has specified product DEMO-P100 and report type compatibility, but not the required delivery format. The form accepts pdf or html. Neither option is interchangeable with an unanswered preference, and the agent has no basis for choosing one. The supplier needs to determine whether its form tool can recover that input without losing the product selection or creating a premature request.
A local demonstration on 17 October 2026 tested that situation using a small Python 3.12.14 form tool with hand-coded validation. It accepted synthetic request objects and stored accepted objects only in an in-memory list. It did not generate or deliver reports. This was a deterministic command-line fixture, not a customer interaction, language-model session, browser test or native WebMCP integration.
The key distinction is between a field being present and its value being usable. JSON Schema describes rules for structured data. Its object reference explains that listing a property under properties does not make it required; required specifies which properties must exist. It also distinguishes a missing property from a property whose value is null. Its enum keyword restricts a value to a defined set. These are input-contract concepts, not evidence that a particular assistant will ask the right question. The local fixture implemented its checks directly rather than running a JSON Schema validator. References: https://json-schema.org/understanding-json-schema/reference/object and https://json-schema.org/understanding-json-schema/reference/enum.
Ask only for the decision that is missing
The clarification should name the missing choice, present the supported options and retain the established context. It should not ask the customer to start the whole form again. In the fictional case, the product and report type can remain unchanged while the format is unresolved.
The following dialogue was scripted for the demonstration. The replies were synthetic inputs, not answers from a real user or outputs observed from an AI assistant:
- Scripted assistant: “Which report format do you want: PDF or HTML? I have kept product DEMO-P100 and report type compatibility unchanged.”
- Scripted user: “csv”
- Scripted assistant: “This form accepts PDF or HTML, not CSV. Which of those should I use?”
- Scripted user: “pdf”
The unsupported CSV reply does not authorise a substitute. Explaining the available choices gives the user a useful way to correct the input. If the user cannot choose, the action should stay paused. If the user asks for a different product or report type instead, treat that as a task change and recheck the affected inputs rather than silently retaining a now-outdated request.
Validate before adding a request
The demonstration declared its inputs and literal expected responses before implementation. A separate evaluator compared the tool outputs against those expectations. The retained validation record distinguished four failures:
- Absent delivery_format: MISSING_REQUIRED, with a request to choose pdf or html. No local request added.
- Null delivery_format: INVALID_TYPE, because this fixture requires a string. No local request added.
- A value containing only spaces: EMPTY_REQUIRED, with a request to choose pdf or html. No local request added.
- The string csv: INVALID_OPTION, because the fixture accepts only pdf or html. No local request added.
Separate valid-pdf and valid-html cases each added one local request in a fresh state. In the scripted recovery sequence, the missing field produced zero records, the CSV reply still produced zero, and the PDF reply produced one. The accepted object retained product_code DEMO-P100 and report_type compatibility and added delivery_format pdf. A fresh-process replay reproduced the same deterministic payloads.
The rejection is useful only if it reaches the agent in a form it can act on. For this fixture, each rejected response named delivery_format, gave a distinct error code and described the permitted answer. A production implementation should preserve that distinction through its actual tool interface. A generic “request failed” leaves the agent without the information needed to ask a relevant clarification.
A negative control exposed why a success response alone is insufficient. A deliberately permissive version inserted pdf when delivery_format was absent. It returned LOCAL_ACCEPTED and added a local request even though the scripted user had not supplied a format. The literal-oracle evaluator rejected that result. Its technically allowed value concealed an unanswered choice. The evaluator was a separate author-written program, not independent human validation.
Resume the same task, then describe the actual outcome
After a valid answer, resume from the retained inputs and check the resulting record. In this example, the observable acceptance condition is zero requests before an allowed format is supplied, followed by exactly one local request containing that supplied format and the unchanged product and report type. “Accepted locally” is the correct outcome description. “Report delivered” would claim work the fixture never performed.
The original task still sets the boundary. A clarification about format does not expand what the user asked the agent to do. Likewise, validating the missing field does not establish that every other field, downstream service or repeat submission is safe. The demonstration covered format recovery with fixed, valid companion fields; it did not test concurrency, network retries, delivery failures or production record deduplication.
Where ScaleGrowth’s implementation work fits
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Answer engine optimisation (AEO) and generative engine optimisation (GEO) concern how a business is understood and represented in AI-generated answers. For a form-recovery problem, that discovery work must be connected to a well-defined action: what the tool needs, which choices belong to the user and what counts as completion.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in WebMCP Made Simple Complete Edition, Chapter 09, “The Eight-Step Tracking Framework”: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.” Here, the practical consequence is to distinguish a failed attempt, a corrected input and an accepted request. Counting each attempt as a completed request would erase the very recovery behaviour the supplier needs to assess. This interpretation applies the book’s measurement principle; it does not use its illustrative code as a current platform specification. They also co-authored The Discovery Reset, whose public bibliographic record is at https://books.google.com/books/about/The_Discovery_Reset.html?id=J28h0gEACAAJ.
ScaleGrowth’s team has years of experience in organic growth marketing. Its relevant capabilities include AgenticReadiness audit systems and WebMCP implementation and consulting. In this fictional supplier’s situation, a useful engagement would identify required inputs, define recoverable errors and test the actual clarification-to-submission path. The local record provides a concrete starting method; it does not establish that ScaleGrowth has deployed this supplier’s form or automatically connected its systems.
ScaleGrowth Digital publishes this reference as an affiliated service provider. Its WebMCP implementation service is the relevant destination for scoped implementation work: https://scalegrowth.digital/services/webmcp/. The next implementation step is to repeat the missing-format case through the intended assistant, tool interface and storage layer, then compare the stored request with the user’s supplied choice. The local demonstration supports taking that test forward, not declaring the production task complete.
References
JSON Schema: object
https://json-schema.org/understanding-json-schema/reference/object
JSON Schema: Enumerated values
https://json-schema.org/understanding-json-schema/reference/enum
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/
The Discovery Reset
https://books.google.com/books/about/The_Discovery_Reset.html?id=J28h0gEACAAJ