Formfacade

Create and PUBLISH a new live form in one step. This is the ONLY tool for creating a form. Use it in every case: 1. The user uploaded, attached, or pasted a file, document, image, screenshot, or PDF: convert that content into the "document" parameter. 2. The user described the form in words (e.g., "create a feedback form", "make a registration form") or you worked out the fields together in conversation: write the complete form yourself as the "document" parameter, with a title, sections, and every field with its label, input type, and choices, then call this tool. Do NOT ask the user to review an outline first unless they ask for one. If they do, agree the fields in chat, then call this tool once. Use "html" format when the content has layout, formatting, structure, or comes from HTML, SCREENSHOT, IMAGE, or PDF. Use "markdown" format when the content is plain text without formatting. This tool returns the complete published form with all sections and fields, a preview URL, and an edit URL. IMPORTANT: This tool already renders the preview widget for the newly created live form, so do NOT call preview or progress in the same turn after a successful create_form. That would render a second widget. Signatures, signers, payments, and notifications mentioned in the request are part of the form you create here; do not call progress for them. Call create_form at most once per turn. Afterwards: to change this form, write the complete updated form yourself and call update_form with the returned publishId (the form was just created and has no responses, so it proceeds without confirmation). Use surgical_edit_form only for one specific field or wording change. Never create a second form to change this one. IMPORTANT: Do NOT include sensitive personal data in the document content. This includes health information, biometric data, social security numbers, payment card industry information (credit/debit card numbers, CVV, expiration dates), bank account details, login credentials, passwords, or authentication secrets. Remove or redact any such sensitive data before passing the document. Output MUST match the "format" parameter. Never mix formats. FIELD DETECTION (when the document comes from a user-supplied source; when you are writing the document yourself from a description, include every field the user asked for): - Create a form field ONLY where the source document has an actual place to write, mark, check, or sign: a blank line (____), an empty box, a checkbox, or a signature line. The number of fields must match the number of real inputs in the source — do not add one. - Text that has NO input in the source (paragraphs, recitals, numbered clauses, instructions) is descriptive content. Keep it as headings/<p> text in the form, NOT as a field. Do not attach an input box to a clause that the source only asks the reader to read. - Reproduce all wording VERBATIM. Never paraphrase, summarize, shorten, or rewrite the source text — especially legal, consent, agreement, or policy text. - Preserve the source's own section order and grouping. Do not split one block into many sections or invent sections. format="html" example output: <!DOCTYPE html> <html><head><base target="_top"></head><body> <h1>Title</h1> <h3>Section</h3> <div><p>Choices</p> <p> <input type="radio"/> <input type="text"/></p> <p> <input type="radio"/> <input type="text"/></p> </div> <div><p>Field *</p><p><input type="text"></p></div> <div><p>Notes</p><textarea></textarea></div> <div><p>Yes/No statement — full statement text goes in the label *</p><p><input type="checkbox"/></p></div> </body></html> DOM rules for checkbox fields (apply to any document, in any combination): - A single yes/no checkbox is ALWAYS one <div> with the statement text inside <p> as the label and a single <input type="checkbox"/> inside its own <p>. The statement text never goes next to the input. - Multiple independent yes/no statements = repeat the same <div>...</div> shape, one per statement. Place each <div> in the section that matches its position in the source document. - A multi-select question (one prompt, several options where more than one can be picked) uses <input type="radio"/> shape per choice — DO NOT collapse the options into the label. - Never wrap <input type="checkbox"> inside <label>...</label> (e.g., <label><input type="checkbox">text</label>). That shape is parsed as a multi-choice question and emits a stray "Other" option. format="markdown" example output: # Title ### Section Choices ( ) ___________ ( ) ___________ Field (text) *: ___________ Notes (textarea) : ___________ Yes/No statement (checkbox) * * after label = required field.

create_form

Use this to help the user turn on, set up, or change a form's SETTINGS: everything about how a published form behaves that is not one of its questions. It opens the setup checklist, which is where the user enables each setting (for example email notifications), and returns checklist status plus next actions. This is the ONLY tool for these settings, so never reply that no tool exists for them. ALWAYS use this tool when the user's message is about ANY of these topics — regardless of how they phrase it: TOPICS THIS TOOL OWNS: - Email notifications (submission alerts, owner/admin notify, respondent confirmation, completion emails, signature workflow emails) - Signature and workflow setup - Payment enablement - HIPAA compliance configuration - Google Drive sync for signed documents - Respondent or customer mapping - Business name setup - Score setup - Submit message or form layout customization - General "what's next" or "what's left to configure" for a form If the user's intent touches any of the above topics on an EXISTING form, whether they are asking how to, asking if it's possible, or reporting it's not working, use this tool first before responding. NOT THIS TOOL: - Creating a form. When the user asks for a new form, call create_form only, even if the request mentions signatures, signers, payments, notifications, or other settings: those are part of the form being created and create_form handles them. Never call progress in the same turn as create_form; the created form's settings can be set up later when the user asks. - Adding, removing, rewording, reordering, or restyling the form's questions, sections, choices, or text (including "make it a quiz" or "make it more engaging"). Those change the form's content, so use update_form or surgical_edit_form.

progress

Fetch the full structure of a LIVE, already-published form by publishId — including title, sections, fields, field types, choices, and required flags. Use this to understand what a form contains BEFORE changing it with update_form, or to answer questions about the form's shape. If you do not know the publishId, use list_forms first to find it by title. Also returns createdAt/createdAtISO and isActivelyCollectingResponses (with activity.recentResponses), which tell you whether update_form will proceed without confirmation. Does not return submissions — use list_submissions for that.

get_form

Search and list the user's published forms with optional filters for title, date range, submission count, ordering, and pagination. Use this tool to find a form (and its publishId) by name or criteria before invoking any other tool that requires a publishId (such as update_form). Submissions are not a form type — this tool does not search submissions. Returns the matching forms as structured data (id, publishId, title, url, submission_count) for the model to present.

list_forms

Show the preview UI for a single form when the user wants to see, show, open, view, or preview it (e.g., "show me my feedback form", "show me the preview"). Pass publishId for the form (use list_forms first if you do not know it). Do NOT call this in the same turn as create_form or update_form, because those already render the preview widget. Call this at most once per turn. To list or search across multiple forms, use list_forms instead.

preview

Make ONE specific change to an EXISTING live form from a natural-language instruction, leaving everything else untouched. USE surgical_edit_form WHEN: * The user names a single field or wording change: make a field required, rename one question or section, change one field's type or options, remove one question, add one question. * Rewriting the whole form for that change would be wasteful. DO NOT USE surgical_edit_form WHEN: * The request touches more than one or two questions, changes what the form is for, who fills it, its topic or scope, or supplies new source content. Use update_form for those (it is the default). HOW IT WORKS: * Pass the user's instruction as typed; do not rephrase or interpret it. * The change is applied to the real, live form that respondents see. * Changes the form's CONTENT only. Settings such as email notifications, signature workflow, payments, Google Drive sync, HIPAA, or the business name are handled by progress. RESPONSES: * The result includes activity with the form's response counts. * When activity.isActivelyCollectingResponses is true (responses in the last 3 calendar months), removing or replacing a question also removes its existing answers. Tell the user how many recent responses the form has (activity.recentResponses) and get confirmation before such an edit. Adding, renaming, or reordering questions is safe and needs no confirmation. If publishId is unknown, use list_forms. Call surgical_edit_form at most once per turn. Do not call preview after a successful surgical_edit_form; the result already renders the preview widget.

surgical_edit_form

Change an EXISTING form. This is the DEFAULT tool for any change to a form that already exists: it replaces the form's questions from a complete document while preserving its publishId, URL, and settings. USE update_form WHEN: * The user asks for any change to an existing form: adding, removing, or rewriting questions, changing its purpose, audience, topic, or scope, redesigning or restructuring it. * The user supplies new source content for an existing form: a description, document, PDF, image, screenshot, HTML, or markdown. Convert it into HTML or markdown for the "document" parameter, exactly as create_form does; files cannot be passed directly. * Not sure which tool to use: use this one. HOW IT WORKS: * The tool DELETES every existing question and section and recreates the form from the document. The document must therefore be COMPLETE: every section and every field that should exist afterwards, not only the changed ones. Anything left out of the document is removed from the form. * If the current questions are not already in the conversation, call get_form first so you can keep what is still relevant. * Keep existing questions and sections that still apply; add, remove, or rewrite the rest as the user asked. * The publishId, URL, and settings stay the same. Never create a new form to change an existing one. * Only forms owned by the signed-in user can be updated. * Output MUST match the "format" parameter and follow the create_form document formatting rules. USE OTHER TOOLS: * create_form: the user wants a NEW form. * surgical_edit_form: the user names ONE specific field or wording change (make a field required, rename one question, remove one question) and rewriting the whole form would be wasteful. RESPONSE SAFETY: * Default to overwrite="auto". It replaces the form only when it has no responses in the last 3 calendar months. A form created less than an hour ago with up to 3 responses counts as test submissions and is replaced without confirmation. * If blocked, the result has success=false, blocked=true, errorCode=FORM_ACTIVELY_COLLECTING_RESPONSES and the count in activity.recentResponses. Nothing was changed. Tell the user the count, then offer: replace it anyway, create a new form with create_form, or make a single-field change with surgical_edit_form. * Use overwrite="force" only after the user explicitly confirms, with the same document. After a force, further update_form calls on the same form proceed in auto mode for 8 hours (overwriteForceUntil in the result) unless new responses arrive, so do not re-ask the user within that window. * Existing responses are retained but were collected against the old questions, so they may not align with the new ones. * A snapshot is saved before the change; the user can revert from the editor's edit history. If publishId is unknown, use list_forms. Call update_form at most once per turn. Do not call preview after a successful update_form; the result already renders the preview widget. Do not include sensitive personal data in the document (health, biometric, government ID, payment card, bank, or login details).

update_form