---
title: "Forms"
description: "Sign-up forms, the people who fill them in, and their numbers."
url: "https://openemail.uk/docs/mcp/tools/forms"
area: "MCP server"
category: "Tools"
---

# Forms

Sign-up forms, the people who fill them in, and their numbers.

## Forms tools

| Tool | What it does |
| --- | --- |
| listForms | The workspace’s sign-up forms, most recently changed first, with their status, sign-ups and views. |
| getForm | One form in full: its fields, copy, audiences, double opt-in and notifications. A published form adds its link, embed code and the address a plain HTML form posts to, and `includeDesign` returns the draft as JSON. |
| listFormStarters | The starting points a new form can begin from, with the fields each asks for. |
| createForm | Create a form from a starter, from a design written as `document`, or from a starter with changes on top, with any settings. It stays a draft unless `publish` is true. |
| updateForm | Change a form’s name and settings, which apply at once, or its draft design through `document`. Copy and style merge key by key, and `fields` replaces the whole list. |
| publishForm | Make the current draft what visitors see, so the form takes sign-ups. |
| setFormStatus | Pause a published form, or open it again. |
| duplicateForm | Copy a form into a new draft, without its sign-ups. |
| deleteForm | Delete a form and its sign-ups for good. Its link and embeds stop working, and the people it added stay in your contacts. |
| getFormAnalytics | Views, sign-ups, people added and still waiting, and the conversion rate over a window, in total and per minute, hour or day. Views are kept per hour. |
| listFormSubmissions | The people who filled in a form, newest first, with their answers and status, a page at a time. Search by email address and filter by status. |
| getFormSubmission | One sign-up in full: every answer, its status, when it came in and when the person was added, the page it came from and its audiences. |
| approveFormSubmission | Add a sign-up that is waiting for its confirmation without the email. Needs `contacts:write` as well. |
| resendFormConfirmation | Email a fresh confirmation link to a sign-up still waiting. Nothing is sent when this form emailed that address in the last ten minutes, or when the address has had five from this workspace in the last day. Needs `emails:send` as well. |
| removeFormSubmissions | Delete up to 200 sign-ups of a form by id. Contacts and audiences stay as they are. |

> Reading needs `forms:read` and every change needs `forms:write`. Anything that makes a form send mail also needs `emails:send`: turning on double opt-in, setting the sender or the confirmation email, publishing or opening a double opt-in form, and resending a confirmation. A client acting for a member sees only the forms that member made, and a client limited to some addresses may only send confirmations from, and notify, addresses it can reach.

> Designing a form from a written brief happens in the app’s chat. Over MCP, the client is the designer: pass the fields, copy and style as `document` to `createForm` or `updateForm`, and the tools tidy the design and say what they changed.

> Seven tools on this server make a change the REST API guards with a verification code, and ask for the same code: `createRule`, `setRuleEnabled`, `removeDomain`, `removeDomainAddress`, `removeAppHost`, `deleteForm`, and `deleteAudience` on an audience you created. Until the client has verified a code in the last 60 minutes, or the person has chosen Allow changes for 60 minutes on it in Account → Connected apps, such a tool answers with a result that starts `Refused (step_up_required):` and changes nothing. `emptyAudience` never asks for a code. The API Authentication page shows how to ask for a code and verify it.

> The tools apply the same rules and refusals as the REST API, and the `/forms` pages of the API reference describe every field. `listForms` orders by last change, and `createForm` and `updateForm` tidy a partial `document` where the API takes it whole.