Getting Started
- Deploy Formulize to your website
- Setup a local development environment
- Use Formulize with AI
- See the Roadmap
Professional Services
Help and Documentation
create_form
Admin-only MCP tool.
Create a new form in Formulize. This creates the form, including default screens and setting basic permissions and menu entries. After creating a form, there are other tools you can use to add user interface elements to the form, such as create_text_box_element, create_list_element, create_linked_list_element, create_user_list_element, create_derived_value_element, create_selector_element, etc. Also, you can use create_subform_interface to provide a way to interact with data from connected forms. See the tool descriptions for more information. To change a form after it exists, use update_form.
It is worth filling in ‘entry_description’, ‘usage_notes’ and ‘data_conventions’ when you know the answers, because they are what a future AI assistant will read to understand what the form is for. If you are not sure, leave them out rather than guessing, and ask the person you are working with.
Properties
| Property | Type | Required? | Description |
|---|---|---|---|
| title | string | Required | Required. The name of the form as it will appear to users. |
| singular | string | Optional | Optional. The word for one entry in this form, used in button labels and messages, for example ‘Artifact’. If you leave this out, Formulize works it out from the title. |
| plural | string | Optional | Optional. The word for several entries in this form, for example ‘Artifacts’. If you leave this out, Formulize works it out from the title. |
| entry_description | string | Optional | Optional. What one entry in this form represents, in plain language. An example, for a Workshop Booking form: ‘One booking, by one person, for one workshop on a given date (the workshops are entries in the Workshops form).’ This is read by AI assistants working with the form, so it should describe the meaning of an entry rather than restate the element list. |
| usage_notes | string | Optional | Optional. Who uses this form, when, and for what purpose. An example, for a Workshop Booking form: ‘Public users visit the form and select a workshop to book. Managers look at the bookings to make decisions about workshop scheduling and room assignments.’ |
| data_conventions | string | Optional | Optional. Rules and expectations the data follows that are not visible in the elements themselves. An example, for a Workshop Booking form: ‘There are a limited number of spaces in a workshop, and new bookings trigger an update of the available spaces value for the selected workshop in the Workshops form. Once a workshop has no available spaces it does not show up in the bookings form anymore.’ This is often the most valuable of the three, because it describes things no amount of looking at the schema would reveal. |
| limit_entries | string (one of: off, user, group) or object | Optional | |
| store_revisions | boolean | Optional | Optional. Keep a revision history of every change made to entries in this form. This is off by default and should only be turned on at the user’s request. |
| send_digests | boolean | Optional | Optional. Send notification emails about activity in this form once a day as a digest, instead of immediately. This is off by default and should only be turned on at the user’s request. |
| principal_identifier | string or integer | Optional | Optional. The element that distinguishes one entry from another. ie: a name, an order number, etc. Not all forms have a natural principal identifier. If a form does have one, Formulize usually shows it when it needs to refer to a single entry. Give either the element’s handle or its id. To clear it, send the number 0 - that is the only value that clears it, so that leaving the setting out, or sending an empty value, cannot remove it by accident. |
| application_id_or_name | string or integer or array of integer | Optional |