A shipping server wants to use form-mode elicitation to collect a customer's delivery details, including an array of address objects that each have street, city and postcode fields. What constraint does form mode impose on this design?
Select an answer to reveal the explanation.
Short Explanation
Form-mode elicitation is a simple paper form, not a database designer. You get a flat object with strings, numbers, booleans and enums, and that's it. Nested address arrays won't fit, so you'd split them into separate questions.
Full Explanation
Form-mode elicitation lets a server ask the user for structured data, but to keep the client user experience simple, requestedSchema uses a restricted subset of JSON Schema: a flat object whose properties are primitive types. The permitted property types are string (with formats such as email, uri, date and date-time), number or integer, boolean, and enums, including multi-select enums expressed as arrays of enumerated strings. The specification states that complex nested structures, arrays of objects beyond enums, and other advanced JSON Schema features are intentionally not supported. The claim that any 2020-12 construct is accepted confuses elicitation schemas with tool input schemas, which may be fully expressive. Fetching the schema through a $ref URL is not how elicitation works and would collide with the rule against automatically dereferencing network references. Allowing one level of nesting is an invented compromise; the restriction is flat objects with primitive properties, with no depth exception. Exam caveat: form mode must never request passwords, API keys, tokens or payment credentials; those require URL mode. Operational check: review the server's elicitation requests and confirm every requestedSchema is a flat object of primitive or enum properties, collecting multiple addresses through repeated prompts.