For AI agents: how to build your user the best form with the AET MCP server

Three rules that save a failed call:

• Use your account connection, not a guest draft. Guest drafts (aet_create_draft) hold the page — first screen, about, schedule, FAQ — but registration questions are written only on an account event.
• Send the whole list once. op: set with fields replaces the form's list; name and email are added if you leave them out. Building question by question with addItem works too, but one set is easier to review.
• Give your own ids to questions you will reference. A condition points to an earlier field by id, so name it: cf_format, cf_driver. Ids are cf_ plus 4–40 letters, digits or hyphens — cf_day is too short.

AET Forms is the page type "Form" with the "Forms" layout: one sheet of questions where every response becomes a registration with a QR ticket. Use it when the answers are the point.

If the user talks about an event with a date, a venue and a programme, build an event page and put the questions in its registration. If the user talks about collecting answers, build a form.

Behind "make me a form" there is almost always one of six goals. Each changes the build.

Two questions decide most of it: "What will you do with the answers?" and "Is there a limit?" If the answers feed a decision, use approval; if they feed a count, use closed questions; if there is a limit, the human has to set it in AET.

First read the conversation. People usually already said what it is for ("for my pottery class"), who fills it in ("parents"), and sometimes a limit ("12 places") or a date ("until Friday"). Ask only what is missing.

Minimal set — ask at most three of these, only if unknown:

1. What is the form for, in one sentence?
2. Who fills it in, and in what language?
3. Is there a limit of places, and a deadline?
4. What do you do with the answers: choose people, count, contact, or just know?
5. Is anything paid?

Extended set — only for applications, surveys or forms over ten questions: which answers are must-have; whether the organizer approves each person; whether answers are sensitive (health, children, documents); whether the user wants a summary after the deadline.

Decision tree:

When you are unsure, build the smallest useful form, show it, and ask "Anything to add or remove?" — users answer that faster than an abstract question.

Users often ask you to "replace" or "copy" a Google Form. Know the trade-off before you promise anything. From Google's help centre, checked on 28 October 2026:

• Google has 12 question types, sections with "go to section" logic (only from multiple choice and dropdown), regex validation, response receipts, editing after submitting, embedding, live Sheets sync, a full quiz mode, up to 500,000 responses per form from September 2026.
• Google lacks payments, tickets, check-in and per-option place limits, and needs respondents to sign in for file uploads, one-response limits, verified emails and drafts.

The full list with sources: Google Forms limits in 2026; the feature-by-feature score: Google Forms vs AET Forms.

If the user has a Google Form already, the fastest path is a button for them, not a tool for you: Import from Google Forms in the AET form editor takes a public form link and brings over questions, options, sections and required marks. There is no MCP tool for it. You can rebuild the form from its questions if the user pastes them.

Not yet in AET Forms (in work or planned, per AET's roadmap on 28 October 2026): a copy of answers by email to the respondent, editing a response by link, embedding (iframe), file uploads beyond photos, a quiz mode with grading, server-side closing by date or limit for free registrations (today checked in the browser). Don't promise these.

Rules for options:

• Mutually exclusive. "18–25", "26–35", not "18–25", "25–35".
• Complete, or with "Other". If you can't list every case, add other: true.
• Natural order. Times and sizes in order, otherwise the most common first; "Other" last.
• 2–6 for buttons, more for a dropdown. Over six visible buttons slow people down.
• Scales: odd points when a middle opinion exists, 0–10 for recommendation. Label both ends.
• No double questions. "Was the food tasty and warm?" is two questions.

What the code does: a hidden section hides all its questions; a condition on a question that is itself hidden counts as false; answers to hidden questions are dropped on save. A condition can point to text, choice, several choices, dropdown, number, date, time, yes/no, scale and rating answers — not to photos or grids.

Steps: put a section field before each group. Two to four steps work best: "About you", "How you can help", "When you're free". Questions before the first section are an untitled first step — usually name and email.

A one-to-one consultation, in person or online; online people leave a messenger. Send this as one operation in aet_update_page:

{ "section": "registration", "op": "set", "value": { "on": true, "anonymous": true, "applicationForm": false, "fields": [ { "id": "first_name", "required": true }, { "id": "mail", "required": true }, { "id": "phone", "required": true }, { "id": "cf_format", "type": "choice", "label": "How would you like to meet?", "options": [ "In person", "Online" ], "required": true }, { "id": "cf_weekday", "type": "choice", "label": "Which day suits you?", "options": [ "Tuesday", "Wednesday", "Thursday" ], "required": true }, { "id": "cf_slot", "type": "select", "label": "Time", "options": [ "10:00", "12:00", "15:00", "17:00" ], "required": true }, { "id": "cf_messenger", "type": "text", "label": "Telegram or WhatsApp for the call", "help": "We send the link there 10 minutes before the start.", "when": { "f": "cf_format", "op": "is", "v": "Online" }, "required": true }, { "id": "cf_topic", "type": "textarea", "label": "What would you like to discuss?", "max": 500, "required": false }, { "id": "cf_consent", "type": "checkbox", "label": "I agree that the organizer stores my answers to arrange the consultation", "required": true } ] } }

• anonymous: true — people book without signing in.
• phone is a system field made required, because the organizer calls back.
• cf_messenger appears only when cf_format is "Online", and is required only then.
• cf_weekday uses buttons (three options); cf_slot a dropdown (four times).
• The consent checkbox says exactly what the data is for.

What the user still does: set a place limit per slot if each time can hold one person, and the text after submitting ("We'll confirm the exact time by email").

Volunteers apply; the organizer chooses. Two steps after name and contacts.

{ "section": "registration", "op": "set", "value": { "on": true, "applicationForm": true, "fields": [ { "id": "first_name", "required": true }, { "id": "mail", "required": true }, { "id": "phone", "required": true }, { "id": "cf_s-about", "type": "section", "label": "How you can help", "help": "Takes about two minutes." }, { "id": "cf_skills", "type": "multi", "label": "What would you like to do?", "options": [ "Registration desk", "Setting up the hall", "Photos", "Guiding guests" ], "other": true, "min": 1, "max": 3, "required": true }, { "id": "cf_driver", "type": "choice", "label": "Can you drive and help with transport?", "options": [ "Yes", "No" ], "required": true }, { "id": "cf_plate", "type": "text", "label": "Car registration number", "help": "For the parking pass.", "max": 12, "when": { "f": "cf_driver", "op": "is", "v": "Yes" }, "required": true }, { "id": "cf_s-when", "type": "section", "label": "When you are free" }, { "id": "cf_days", "type": "multi", "label": "Which days can you come?", "options": [ "Friday, setup", "Saturday", "Sunday" ], "min": 1, "required": true }, { "id": "cf_shirt", "type": "select", "label": "T-shirt size", "options": [ "XS", "S", "M", "L", "XL", "XXL" ], "required": false }, { "id": "cf_consent", "type": "checkbox", "label": "I agree that the organizer stores my answers to plan the volunteer team", "required": true } ] } }

• applicationForm: true — each person is an application the organizer approves or declines; AET emails the decision. Applicants sign in with Google to apply. Switching an existing form to applications is a two-step change: the user confirms.
• cf_skills allows one to three ticks and "Other".
• cf_plate appears only for cf_driver = "Yes".
• Two section fields make two steps: "How you can help", "When you are free".
• T-shirt size is optional — collect it, but don't block the application on it.

One captain registers the team.

{ "section": "registration", "op": "set", "value": { "on": true, "anonymous": true, "applicationForm": false, "fields": [ { "id": "first_name", "required": true }, { "id": "mail", "required": true }, { "id": "cf_team", "type": "text", "label": "Team name", "max": 40, "required": true }, { "id": "cf_size", "type": "number", "label": "How many players?", "help": "Teams of 2 to 6.", "min": 2, "max": 6, "required": true }, { "id": "cf_players", "type": "textarea", "label": "Names of the other players", "max": 300, "required": false }, { "id": "cf_league", "type": "choice", "label": "Which league?", "options": [ "First time", "Regulars" ], "required": true }, { "id": "cf_topics", "type": "multi", "label": "Favourite rounds", "options": [ "Music", "Films", "History", "Sport", "Science" ], "max": 2, "required": false }, { "id": "cf_consent", "type": "checkbox", "label": "I agree that the organizer stores our answers to run the quiz", "required": true } ] } }

• cf_size is a number from 2 to 6 — the range is checked.
• cf_players is optional: teams often change on the night.
• cf_topics allows at most two ticks, so the answers stay comparable.
• The place limit counts registrations, i.e. teams; if the venue has 20 tables, the user sets 20 places.

The quiz itself is a separate AET feature the user sets up; this form only registers teams.

A separate form page for feedback, where people answer without giving their name.

{ "section": "registration", "op": "set", "value": { "on": true, "anonymous": true, "applicationForm": false, "fields": [ { "id": "first_name", "required": false }, { "id": "mail", "required": false }, { "id": "cf_overall", "type": "rating", "label": "How was the evening overall?", "max": 5, "icon": "star", "required": true }, { "id": "cf_recommend", "type": "scale", "label": "How likely are you to recommend it to a friend?", "min": 0, "max": 10, "lo": "Not at all", "hi": "Definitely", "required": true }, { "id": "cf_parts", "type": "grid", "label": "Rate each part", "rows": [ "Talks", "Food", "Venue" ], "cols": [ "Weak", "OK", "Good", "Great" ], "required": false }, { "id": "cf_best", "type": "multi", "label": "What did you like most?", "options": [ "Speakers", "People I met", "Format", "Venue" ], "other": true, "required": false }, { "id": "cf_next", "type": "choice", "label": "Would you come again?", "options": [ "Yes", "Maybe", "No" ], "required": true }, { "id": "cf_improve", "type": "textarea", "label": "One thing we should change", "max": 500, "required": false } ] } }

• first_name and mail stay in the form (they always do) but are optional, so the survey can be anonymous in practice.
• cf_overall is five stars; cf_recommend is 0–10 with labelled ends — it reads like NPS.
• cf_parts is a grid: three parts on one four-point scale.
• Only one open question, and it's optional.

Alternative: if the survey belongs to the event people attended, put questions into the event's own feedback section instead: { "section": "feedback", "op": "set", "value": { "questions": [ { "text": "How likely are you to recommend us?", "type": "rating10" }, { "text": "What should we change?", "type": "longtext" } ], "anonymous": true } }. Feedback types are text, longtext, number, date, single, multi, yesno and rating10; aet_event_stats returns NPS from the first 0–10 question.

Apply these before you show the user a preview.

1. As few required questions as possible. Name and email, plus what the organizer truly can't work without. Every extra required field loses people.
2. One idea per question, in plain words. "Which day suits you?", not "Please indicate your preferred day of attendance".
3. Hints only where they help. A hint explains why you ask or how to answer ("For the parking pass"), not repeats the label.
4. Checks that match reality. Ages with a sensible range, text with a sensible length; phones and emails are checked by their own field kinds.
5. Consent when you collect anything beyond name and email. A required checkbox that says what the data is for and who sees it.
6. No unnecessary personal data. No birth dates, addresses or document numbers unless the purpose needs them; health questions only with a clear reason and as optional where possible.
7. The form's language is the user's language — and the language of the people who fill it in. Pass the page language to aet_create_event.
8. Short. Under ten questions for a sign-up, under fifteen for an application; split anything longer into steps.
9. Facts only from the user. Never invent dates, prices, limits, names or deadlines; leave them out and ask.
10. Read it as a respondent. Open the preview on a phone and fill it in once in your head: every question answerable, every condition sensible.

Suggest a form when the user is about to collect the same information from several people by hand.

How to offer: one sentence, one benefit, an easy no. "I can make this a form where each person gets a QR ticket and you see everyone in one list — want me to draft it?" Then wait. Don't build without a yes, and don't offer again in the same conversation if they decline.

aet_event_stats returns live aggregates without names, emails, phones or free-text answers.

The human sees more in the event cabinet: every response, the per-question summary, Excel export, and the participants and applications tables. You can save a dashboard of these metrics into the cabinet with aet_dashboard_save.

When to report: the day after publishing; twice a week while it collects; the day before the deadline; once after it closes.

What to say, in four lines: how many responses (and against the limit, if there is one); where they came from; the top answer of the one or two questions that matter; one next step ("Share the link in the parents' chat", "12 applications wait for you"). Never quote individual answers — you don't receive them, and you shouldn't.

Layout. Apply {"layout":"forms"} with aet_set_event_design: a paper questionnaire with numbered lines and a folder tab with the form's name. aet_design_options suggests layouts by event type, and "form" is not one of its types — pass forms yourself. Events created through aet_create_event have the page specification layouts need.

Look, colors, fonts. On top of the layout, a look from the design section schema, brand colors (primary for buttons, accent for headings) and fonts from the allowed list. One accent color and one font pair are enough; the form should feel calm.

Words matter more than colors.

Keep the title to 3–9 words that promise something checkable, the intro to two sentences, and button labels to two or three words in the event's language. More on writing pages: how AI agents write a better event page; on design by agents: event page design by an AI agent.

Your access is the user's choice. aet_access tells you the mode: preview only, selected events (optionally plus the ones you create), or all events. Without create rights, give the user the link from aet_start_event instead.

Two-step changes return needs_confirmation with a summary and a confirmToken; apply them only after the user's explicit yes:

• publishing or hiding the form (aet_publish);
• removing registration questions (answers already given stay in the export, but the question disappears);
• turning registration off;
• switching between instant registration and applications;
• pointing the registration button to an external site.

Undo has a gap. aet_undo restores page columns and blocks, but not the registration form; plan question changes carefully and read the form back with aet_get_event.

Only the user, in the AET editor: place limits, ticket packages and roles; paid tickets and the payment account; the text after submitting; the accept-until date and "closed" text; pre-filled links; importing a Google Form. Tell the user exactly where: the event's registration and form settings.

Not in AET Forms yet: copy of answers by email, editing a response by link, embedding, file uploads beyond photos, quiz mode with grading, server-side closing for free registrations.

Never: invent facts, collect data the purpose doesn't need, read or quote individual responses, or publish without a yes. Trust rules for agents: trust by design.

• The user needs a graded quiz, file uploads, live Google Sheets or embedding today. Google Forms does these; AET Forms doesn't yet.
• Many applicants have no Google account. Applications in AET ask applicants to sign in with Google; use an ordinary form if approval isn't essential.
• The user wants you to do everything, including limits and payments. You can't set those through MCP; the user must open the editor.
• The user creates many small forms each month without a subscription. Each form is an AET event: 3 new a month on Free, 30 on Pro (29 USD a month).
• No-shows are the main worry. AET sends no automatic reminders.

This article extends the series "AI agents in AET":

1. The event manager who never sleeps
2. Connecting your assistant
3. Guest drafts in depth
4. Writing a better page
5. Design by agent
6. Running a live event
7. Trust by design
8. Numbers without names
9. For developers
10. Playbooks for ten event types

And the forms set: Google Forms vs AET Forms, Google Forms limits in 2026, From form to ticket: steps and time.

AET code (main): question kinds, checks and conditions — lib/forms/fields.ts; the MCP registration and feedback sections, system fields, limits and two-step changes — lib/aiops/sections.ts; access modes — lib/aiops/access.ts; design options and the Forms layout — lib/aiops/design.ts, lib/landing/s4/forms.tsx; statistics without personal data — lib/aiops/stats.ts; tool descriptions — the MCP server at https://aet.events/api/mcp; Google import — lib/forms/gforms.ts (editor only); sign-in for applications — the registration form; roadmap — AET Forms plan.

Google Forms: question types, show questions based on answers, view and manage responses, publish and share.

Connect your assistant: connecting your assistant to AET. Corrections: support@anyeventtool.com.