F
licenseA
qualityC
maintenanceMCP server for FormsList, a form-backend SaaS. Enables creating form endpoints, reading submissions, configuring auto-responses, and generating embed snippets via natural language.
7
-
Deoochform
Server Details
Create forms, read submissions, and build invitations from Claude, ChatGPT, or any MCP client.
Ownership verified
- Status
- Healthy
- Uptime
- 54.9% over 40 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- musaib001/deoochform-mcp
- GitHub Stars
- 0
TDQS
A3.9/5.0
Scored across 10 tools
Disambiguation5/5
Every tool targets a distinct resource and action: forms, invitations, submissions, and templates are clearly separated. The descriptions for create_form and create_invitation explicitly disambiguate the two object types, eliminating any chance of misselection. List operations are specific to their resource types (list_forms, list_submissions, list_invitation_templates, list_templates) with no overlap.
Naming Consistency5/5
All tool names follow the consistent verb_noun pattern in snake_case: create_form, get_form, list_forms, update_form, publish_invitation, etc. Even the two template listers (list_templates and list_invitation_templates) are consistent with the pattern, and the verbs (create, get, list, publish, update) are used uniformly. No mixed conventions or inconsistent verb styles.
Tool Count5/5
With 10 tools, the server is well-scoped for its dual domain of forms and invitations. Each tool earns its place: CRUD for forms, submission retrieval, template listing, and invitation creation/publishing. This falls squarely in the ideal range and does not feel bloated or thin.
Completeness3/5
The form lifecycle is well covered (create, get, list, update) though delete is missing. However, the invitation lifecycle is notably incomplete: there is no way to list existing invitations, retrieve a draft, or update an invitation after creation—only create and publish. This gap means agents cannot manage or inspect invitations after they are made, which will likely cause failures when users need to modify or review them.
Available Tools
10 toolscreate_formCreate formAInspect
Create a new form and return its public link. A form is a page of questions that collects answers. An animated wedding invitation page is a different object, built by create_invitation, and the phrase "wedding invitation form" usually describes that page rather than a questionnaire.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rules | No | Conditional show/hide logic: each rule reads one field's answer and shows or hides another. Only set this when asked for a field to depend on another; most forms carry no rules. Every fieldId used must exist in this same `fields` array, a rule referencing a field that isn't there is dropped. | |
| theme | No | Visual preset: the form's entire look, not only its background colour. DESIGNED PRESETS (typography, field styling, depth and background together): `editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour. Category presets, each with its own title font; pick by what the form is for: `blush`: weddings, engagements, beauty, celebrations. `bistro`: restaurants, cafes, catering, food orders, hotels. `playground`: schools, courses, kids' classes, summer camps. `studio`: gyms, fitness classes, sport, races (dark). `clinic`: healthcare, dental, therapy, patient intake. `noir`: tattoo, photography, music, creative studios (dark). `chambers`: law, accountancy, consulting, anything that ends in a signature. `terminal`: engineering, IT, bug reports, internal tooling (dark). `meadow`: charities, community groups, volunteering, the environment. `civic`: councils, school offices, public services, official reports. `frost`: winter events, travel, and anything that should feel cool and unhurried. These show a cover photo behind the title when the form has one. SCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark: `lane`: pools, gyms, swimming, anything with water. `skyline`: property, architecture, city and office work. `ceremony`: weddings and formal invitations. `nightfield`: festivals, gigs, outdoor events after dark. `kiln`: studios, workshops, craft and making things by hand. `confetti`: parties, birthdays, celebrations. `supper`: restaurants, reservations, hospitality. `roastery`: cafes, coffee, drink orders. `expedition`: tours, travel, the outdoors. `salon`: salons, barbers, beauty appointments. `thermal`: spas, treatments, rest. `lecture`: courses, training, teaching. `atrium`: clinics and practices, calm and clinical. `marquee`: conferences, talks, ticketed events. `trailhead`: races, runs, outdoor signups. `pressroom`: photography, press, creative bookings. A scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting. PLAIN: `default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now. How to choose: - They named a colour → the category preset or scene closest to it. - The form clearly belongs to one of the categories above → that category preset. - They asked for it to look good but named no colour → `editorial`. - They asked for neither → OMIT. A form nobody asked to style stays default. Each preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do. | |
| title | Yes | ||
| fields | No | Do not open with a `heading` field that repeats the form title. The title already renders above the fields. Use `heading` fields only to break a multi-topic form into named sections. For anything the respondent attaches from their device (a CV, resume, photo, receipt, portfolio) the type is `upload`, never `file`. `file` is a plain URL text box and collects no file at all. A `label` or `helpText` may quote an earlier answer back to the respondent by writing `{{<field id>}}`, e.g. a field with id `q1` asking their name lets a later label read `Thanks {{q1}}, what is your email?`. The reference is the other field's **id**, never its label, and that field must appear earlier in this same `fields` array; add `|` and fallback text (`{{q1|there}}`) for what to show when they skipped it. A reference naming a field that is not in this array is rejected. | |
| layout | No | How the form presents itself. `classic` stacks every question on one page and is the default. `conversational` asks one question per screen, with a progress bar and Next/Back, the Typeform-style flow. Set `conversational` when the user asks for one question at a time, a guided or step-by-step form, or something that feels like a conversation; it pairs especially well with labels that quote an earlier answer. It changes nothing about what is collected, so it is safe to set on a form that already has responses. | |
| description | No | ||
| submitLabel | No | Text on the final button, at most 40 characters. Write what pressing it does, in the form's own voice: "Book my table", "Count me in", "Send my RSVP". Omit for "Submit". Ignored on payment forms, whose button always states the amount. | |
| templateSlug | No | Start from one of our ready-made templates. Call list_templates to find the slug. STRONGLY PREFERRED over writing fields by hand whenever a template fits: the template brings its own field set, colour theme and header artwork, none of which you can supply yourself. Omit `fields` to take the template's as-is; supply `fields` only to genuinely replace them, which loses the template's questions but keeps its theme and artwork. | |
| notAnInvitation | No | Leave this out. Set it to true only after the user has been told about the interactive invitation page and has explicitly said they want a plain questionnaire instead. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| theme | Yes | |
| formId | Yes | |
| publicUrl | Yes |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core side effect (creates a form) and adds the useful return behavior (public link), which goes beyond the all-false annotations. However, it does not describe any other behavioral traits such as idempotency, visibility of created forms, or failure behavior. For a simple create operation this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first establishes the operation and output, the second resolves the key sibling confusion. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex creation tool with nine parameters, the definition is complete because the schema carries extensive guidance on themes, fields, conditional rules, and templates. The description supplies the missing conceptual context—what a form is and how it differs from an invitation—and an output schema exists, so return-value detail is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself adds no parameter-level meaning, but the input schema covers most parameters in detail, especially fields, theme, rules, layout, and templateSlug. With 78% schema coverage, the description does not need to compensate; the title parameter's purpose is self-evident from the tool name and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create a new form') and a specific result ('return its public link'), then defines the resource ('a page of questions that collects answers'). It also explicitly distinguishes the tool from the create_invitation sibling, so an agent can select it correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly addresses the main ambiguity by naming create_invitation as the alternative and explaining that 'wedding invitation form' usually refers to that page, not a questionnaire. This is an explicit when-not-to-use rule with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_invitationCreate invitationAInspect
Create an interactive invitation: an animated page on its own link with an opening scene, scratch-to-reveal, countdown, venue map and RSVP. It is a page guests read, not a questionnaire that collects answers, which is what create_form builds. A request for a "wedding invitation form" describes this page rather than a questionnaire, since that is how the page is commonly named. It arrives as a draft and publish_invitation puts it live.
A template id from list_invitation_templates is required. The programme is whatever functions the couple names: pre-wedding ones such as Mehndi, Haldi, Sangeet, Dholki, Engagement, Welcome dinner, and wedding-day ones such as Guest arrival, Baraat, Nikah, Wedding ceremony, Rukhsati, Photographs, Dinner, Reception, Walima. Which of these a couple holds varies by tradition and by family, and the lists record only what is supplied.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| details | Yes | Everything known so far, an invitation saves fine half-filled. `preWedding` is the run-up (Mehndi, Haldi, Sangeet, Dholki…) and `ceremonies` the day itself (Baraat, Nikah, Rukhsati, Reception, Walima…); each entry needs only a `name`, with date/time/venue added as they are settled, and both lists stay in the order you send them. `blessing` is the invocation the card opens with: `bismillah` (﷽), `ganesha` (the image with the Sanskrit shloka), `cross` (with Song of Solomon 3:4), or `none`. It reflects the couple's own stated choice; names do not indicate it, since names cross traditions and interfaith weddings are common. Omitted, the card opens with no invocation. `colors.bg` and `colors.ink` override the template's ground and text colour; omitted, the template's own palette applies, which is already matched to its artwork. | |
| templateId | Yes | An invitation template id, as returned by list_invitation_templates. It sets the design and is fixed once the invitation is published. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| status | Yes | |
| editUrl | Yes | |
| publicUrl | Yes | |
| invitationId | Yes | |
| missingBeforePublish | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnly, openWorld, idempotent, destructive), so the description must carry the behavioral disclosure. It does so by stating that the invitation 'arrives as a draft and publish_invitation puts it live,' which clarifies the side effect of creation (draft only) and the need for a separate publishing step. It also explains that the template id is fixed once published, a meaningful behavioral trait. It doesn't disclose any destructive implications, but none are expected for a create tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, running into a lengthy second paragraph about pre-wedding and wedding-day functions. While informative, this detail could be condensed or moved to a later position; the core purpose and usage guidance are front-loaded, but the extended enumeration of ceremony types adds bulk. It earns a mid-range score because the structure is still logical and the content is relevant, but it is not as lean as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, 2 required params, an existing output schema), the description covers the essential context: what it creates, when to use it, the template requirement, and the draft/publish flow. It doesn't describe error conditions or return values, but those are adequately handled by the output schema and the assumed behavior of a create operation. It is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds value beyond that by highlighting that templateId is required and that the programme lists are flexible ('the lists record only what is supplied'), clarifying that the agent should only include ceremonies the couple actually holds. This contextual nuance compensates for the otherwise generic schema and makes the parameters more usable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement of what the tool does: 'Create an interactive invitation: an animated page on its own link with an opening scene, scratch-to-reveal, countdown, venue map and RSVP.' It then explicitly contrasts itself with the sibling create_form ('not a questionnaire... which is what create_form builds'), making the purpose unambiguous and distinguishing it from the closest alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description goes beyond stating purpose to give direct usage guidance. It names create_form as the alternative for questionnaires and provides a concrete rule: 'A request for a "wedding invitation form" describes this page rather than a questionnaire.' It also points to list_invitation_templates for the required template id and to publish_invitation for making the draft live, giving the agent a clear workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_formGet formARead-onlyIdempotentInspect
Get a form's full definition.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| rules | Yes | |
| theme | Yes | |
| title | Yes | |
| fields | Yes | |
| formId | Yes | |
| status | Yes | |
| createdAt | Yes | |
| publicUrl | Yes | |
| updatedAt | Yes | |
| description | No |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needs to add context beyond that. It adds 'full definition' as a scoping detail, but offers no further behavioral information such as error handling, 404 behavior, or authentication needs. With annotations present, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single five-word sentence that is front-loaded with the core action and resource. There is zero filler or repetition; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with a present output schema and safety annotations, the definition is nearly complete. The only notable gap is the lack of a pointer to list_forms for discovering valid IDs, but the sibling list makes that easy to infer. Overall, an agent can correctly call this tool with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for formId. The phrase 'a form's full definition' implies that formId identifies the target form, which is helpful. However, it does not explicitly define the parameter, its expected format, or how to obtain a valid ID. The parameter is self-explanatory, but the description adds minimal semantic value beyond the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('form'), and a scope qualifier ('full definition'). This cleanly separates it from siblings like list_forms (which lists forms, presumably as summaries) and get_submission (a different resource). The meaning is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the name and description: fetch a single form's complete definition by ID. However, the description provides no explicit guidance on when to choose this over list_forms or get_submission, nor does it point to list_forms for discovering valid form IDs. Usage guidance is inferred, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_submissionGet submissionBRead-onlyIdempotentInspect
Get a single submission by id.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| submissionId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| formId | Yes | |
| answers | Yes | |
| submittedAt | Yes | |
| submissionId | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety and idempotency of the operation. The description adds no behavioral context beyond that; it simply repeats the action. Given the annotations, the bar for additional disclosure is lower, and the description is adequate but does not add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It is appropriate in length and structure, effectively stating the purpose without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, a clear output schema, and rich annotations. The description is minimal but given the low complexity, it may suffice. However, it does not mention what the output contains or any details about the submission object. Since the output schema exists, the description need not explain return values, but it could be more complete by referencing the schema or any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameter 'submissionId' as a string with no additional description. The schema coverage is 0%, so the description must compensate. However, the description only says 'by id' without clarifying that the id is the submissionId parameter, though it's inferable. It does not explain any format, constraints, or how the id is used. This is minimal compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a single submission by id', which clearly indicates the verb (get), the resource (submission), and the identifier (id). It distinguishes from sibling tools like list_submissions by emphasizing 'single' and 'by id'. However, it does not explicitly mention the output schema or any specific details that would differentiate it from other get tools like get_form, but the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need a single submission by its id. It doesn't explicitly discuss alternatives or when not to use it. The sibling list includes list_submissions, which is for listing, but the description doesn't reference it. The context of 'single' vs 'list' is implied, but not as explicit as it could be.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_formsList formsBRead-onlyIdempotentInspect
List forms in this workspace.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| forms | Yes |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the workspace-scoping constraint but says nothing about pagination or default limit; no contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The information is front-loaded and every word earns its place, though it is minimal rather than verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two optional parameters, output schema present, safety annotations present), and the description covers purpose and workspace scope. However, it omits the existence of the status filter and limit behavior, which the agent must discover from the schema; this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention that `limit` controls page size or that `status` filters forms, leaving the agent to infer all parameter semantics from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('forms') with a workspace scope. It clearly distinguishes itself from sibling tools like list_submissions and list_templates by naming a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description does not mention get_form for retrieving a single form, nor does it note when listing is preferable, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_invitation_templatesList invitation templatesARead-onlyIdempotentInspect
The designs an interactive invitation can be built on. Each entry carries its name, how the card opens, and its colour palette. The template decides how the invitation looks and is fixed once the invitation is published.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| templates | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds useful domain context: each entry includes name, card-opening style, and colour palette, and templates are fixed after publication. This goes beyond annotations but does not mention pagination or ordering, which is acceptable for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: the first states the purpose, the second lists entry contents, and the third explains the significance of templates. No fluff, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an existing output schema, the description is complete. It explains the meaning of the list and the implications of template fixation, which is all an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description needs to add no parameter detail. It appropriately focuses on what the returned entries represent, satisfying the baseline for parameter-free tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool lists invitation templates, describing what each entry contains (name, opening style, colour palette) and the role of templates in invitations. It distinguishes from the sibling 'list_templates' by focusing on invitation-specific templates, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing available invitation templates before creation, but it does not explicitly state when to use this vs. other tools like 'list_templates' or 'create_invitation'. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_submissionsList submissionsBRead-onlyIdempotentInspect
List submissions for a form.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| formId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| submissions | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond the trivial listing semantics, but it does not contradict annotations either. With strong annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence contains no filler and immediately conveys the core operation. Every word earns its place, and the key scoping detail ('for a form') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the output schema plus annotations cover much of what an agent needs. However, the description lacks usage guidance and any behavioral nuances (e.g., ordering, full result set), leaving the agent to infer when to choose this over get_submission. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies that submissions are scoped to a form (formId), but it does not explain the 'limit' parameter or its default/maximum behavior. The schema provides the numeric constraints, but the description adds minimal meaning beyond the property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List'), a specific resource ('submissions'), and a scope ('for a form'). It is immediately distinguishable from siblings like get_submission (single item) and list_forms (different resource), even without explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_submission or list_forms. The usage is only implied by the verb and resource, with no exclusions or routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesList templatesARead-onlyIdempotentInspect
Ready-made form templates, each with its own field set, colour theme and header artwork. Search here before building a common form from scratch. Pass the slug to create_form's templateSlug and the form arrives complete. Building the same questions by hand loses the theme and the artwork.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter by words in the name, category or description, e.g. "job", "wedding", "feedback". Omit to list every template. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| templates | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the template content and how to use the result (passing slug to create_form) but does not disclose additional behaviors like pagination or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the tool's purpose, then provides usage guidance and integration details. Every sentence earns its place without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and an existing output schema, the description covers purpose, usage, and how to apply results. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single optional query parameter, describing filtering by words in name, category, or description. The tool description does not add any parameter details beyond what the schema already states, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ready-made form templates with field sets, colour themes, and header artwork. It distinguishes from siblings like list_forms (which lists forms) by focusing on templates and explicitly ties to create_form via templateSlug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance: 'Search here before building a common form from scratch' and explains the benefit of using templates. However, it does not mention alternatives like list_invitation_templates or when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_invitationPublish invitationAIdempotentInspect
Put a draft invitation live at its public link and start collecting RSVPs. Needs the couple's names, the date, the time and the venue name, create_invitation reports any that are still missing, so ask the user for those before calling this.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| invitationId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| publicUrl | Yes | |
| invitationId | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: it changes the invitation from draft to live, creates a public link, and starts RSVP collection. It aligns with the annotations (non-read-only, idempotent, non-destructive) and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. However, the second sentence is a run-on and awkwardly combines the missing-field prerequisites and the reference to create_invitation, which costs some readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and annotations carry some of the burden, so return format and safety properties do not need to be repeated. Still, the description lacks a clear statement of what invitationId is and what happens when an invite is already published, leaving the agent to infer part of the correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not directly explain the sole parameter, invitationId, as the identifier of the draft invitation to publish. The list of needed data (couple names, date, time, venue) refers to invitation contents, not to input parameters, which can confuse an agent about what this tool actually accepts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('put live'), names the resource ('draft invitation'), and states the effect ('public link' and 'start collecting RSVPs'). This clearly distinguishes it from creation/editing tools like create_invitation and create_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete precondition: ask the user for missing invitation details and references create_invitation as the tool that reports missing data. However, it doesn't explicitly cover when not to call it (e.g., if the invitation is already live) or compare to alternatives, so it falls just short of fully explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_formUpdate formADestructiveInspect
Update a form's title, description, fields, or status.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rules | No | Conditional show/hide logic: each rule reads one field's answer and shows or hides another. Only set this when asked for a field to depend on another; most forms carry no rules. Every fieldId used must exist in this same `fields` array, a rule referencing a field that isn't there is dropped. | |
| theme | No | Visual preset: the form's entire look, not only its background colour. DESIGNED PRESETS (typography, field styling, depth and background together): `editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour. Category presets, each with its own title font; pick by what the form is for: `blush`: weddings, engagements, beauty, celebrations. `bistro`: restaurants, cafes, catering, food orders, hotels. `playground`: schools, courses, kids' classes, summer camps. `studio`: gyms, fitness classes, sport, races (dark). `clinic`: healthcare, dental, therapy, patient intake. `noir`: tattoo, photography, music, creative studios (dark). `chambers`: law, accountancy, consulting, anything that ends in a signature. `terminal`: engineering, IT, bug reports, internal tooling (dark). `meadow`: charities, community groups, volunteering, the environment. `civic`: councils, school offices, public services, official reports. `frost`: winter events, travel, and anything that should feel cool and unhurried. These show a cover photo behind the title when the form has one. SCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark: `lane`: pools, gyms, swimming, anything with water. `skyline`: property, architecture, city and office work. `ceremony`: weddings and formal invitations. `nightfield`: festivals, gigs, outdoor events after dark. `kiln`: studios, workshops, craft and making things by hand. `confetti`: parties, birthdays, celebrations. `supper`: restaurants, reservations, hospitality. `roastery`: cafes, coffee, drink orders. `expedition`: tours, travel, the outdoors. `salon`: salons, barbers, beauty appointments. `thermal`: spas, treatments, rest. `lecture`: courses, training, teaching. `atrium`: clinics and practices, calm and clinical. `marquee`: conferences, talks, ticketed events. `trailhead`: races, runs, outdoor signups. `pressroom`: photography, press, creative bookings. A scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting. PLAIN: `default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now. How to choose: - They named a colour → the category preset or scene closest to it. - The form clearly belongs to one of the categories above → that category preset. - They asked for it to look good but named no colour → `editorial`. - They asked for neither → OMIT. A form nobody asked to style stays default. Each preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do. | |
| title | No | ||
| fields | No | Do not open with a `heading` field that repeats the form title. The title already renders above the fields. Use `heading` fields only to break a multi-topic form into named sections. For anything the respondent attaches from their device (a CV, resume, photo, receipt, portfolio) the type is `upload`, never `file`. `file` is a plain URL text box and collects no file at all. A `label` or `helpText` may quote an earlier answer back to the respondent by writing `{{<field id>}}`, e.g. a field with id `q1` asking their name lets a later label read `Thanks {{q1}}, what is your email?`. The reference is the other field's **id**, never its label, and that field must appear earlier in this same `fields` array; add `|` and fallback text (`{{q1|there}}`) for what to show when they skipped it. A reference naming a field that is not in this array is rejected. | |
| formId | Yes | ||
| layout | No | How the form presents itself. `classic` stacks every question on one page and is the default. `conversational` asks one question per screen, with a progress bar and Next/Back, the Typeform-style flow. Set `conversational` when the user asks for one question at a time, a guided or step-by-step form, or something that feels like a conversation; it pairs especially well with labels that quote an earlier answer. It changes nothing about what is collected, so it is safe to set on a form that already has responses. | |
| status | No | ||
| description | No | ||
| submitLabel | No | Text on the final button, at most 40 characters. Write what pressing it does, in the form's own voice: "Book my table", "Count me in", "Send my RSVP". Omit for "Submit". Ignored on payment forms, whose button always states the amount. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| theme | Yes | |
| formId | Yes | |
| publicUrl | Yes | |
| updatedAt | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description doesn't elaborate on what 'update' implies in terms of overwriting existing data, required permissions, or reversibility. It adds minimal behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose. It is appropriately sized for the tool's scope, though it could add a bit more guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, a rich schema, and an output schema. The description is minimal but the schema carries significant detail. However, the description doesn't mention update semantics like partial updates, required formId, or the behavior of omitted fields, so an agent may not know how to handle partial updates correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 56%, and the description adds meaning by listing the updatable aspects (title, description, fields, status) which clarifies the purpose of several parameters. However, it doesn't deeply explain parameter behavior for nested fields/rules beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Update a form's title, description, fields, or status'), clearly distinguishing this tool from siblings like create_form and list_forms. However, it doesn't explicitly contrast it with get_form or mention update semantics beyond the listed fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear list of what can be updated, which implies usage, but it doesn't provide explicit when-to-use guidance versus alternatives like create_form. There are no exclusions or conditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
create_form3 fields changed- added
Input schema / properties / fields / items / properties / formulaAdded value: +{ + "maxLength": 500, + "type": "string" +} - changed
Input schema / properties / fields / items / properties / type / descriptionPrevious value: -"The field's input type. Two of these are easily confused: `upload` is the real file uploader, the respondent attaches an image, PDF or Word doc from their device, and is what you want for a CV, resume, photo, receipt, portfolio, certificate, or any \"attach\"/\"upload\" request. `file` is NOT an uploader: it only collects a URL the respondent types in, so use it only when the user explicitly asked for a link to a file hosted somewhere else."New value: +"The field's input type. Two of these are easily confused: `upload` is the real file uploader, the respondent attaches an image, PDF or Word doc from their device, and is what you want for a CV, resume, photo, receipt, portfolio, certificate, or any \"attach\"/\"upload\" request. `file` is NOT an uploader: it only collects a URL the respondent types in, so use it only when the user explicitly asked for a link to a file hosted somewhere else. `calculation` shows a number worked out from other answers, such as a total or a score; its `formula` holds arithmetic (+ - * /, brackets, round, min, max) over other fields referenced as {{<field id>}}, e.g. \"{{qty}} * 25\". A choice answer counts as the first number in its text." - changed
Input schema / properties / fields / items / properties / type / enumPrevious value: -[ - "text", - "textarea", - "name", - "email", - "phone", - "url", - "address", - "number", - "select", - "radio", - "checkbox", - "ranking", - "rating", - "scale", - "date", - "time", - "file", - "upload", - "signature", - "appointment", - "heading", - "image", - "page-break", - "hidden" -]New value: +[ + "text", + "textarea", + "name", + "email", + "phone", + "url", + "address", + "number", + "select", + "radio", + "checkbox", + "ranking", + "rating", + "scale", + "date", + "time", + "file", + "upload", + "signature", + "appointment", + "heading", + "image", + "page-break", + "hidden", + "calculation" +]
- Changed
get_form3 fields changed- added
Output schema / properties / fields / items / properties / formulaAdded value: +{ + "maxLength": 500, + "type": "string" +} - changed
Output schema / properties / fields / items / properties / type / descriptionPrevious value: -"The field's input type. Two of these are easily confused: `upload` is the real file uploader, the respondent attaches an image, PDF or Word doc from their device, and is what you want for a CV, resume, photo, receipt, portfolio, certificate, or any \"attach\"/\"upload\" request. `file` is NOT an uploader: it only collects a URL the respondent types in, so use it only when the user explicitly asked for a link to a file hosted somewhere else."New value: +"The field's input type. Two of these are easily confused: `upload` is the real file uploader, the respondent attaches an image, PDF or Word doc from their device, and is what you want for a CV, resume, photo, receipt, portfolio, certificate, or any \"attach\"/\"upload\" request. `file` is NOT an uploader: it only collects a URL the respondent types in, so use it only when the user explicitly asked for a link to a file hosted somewhere else. `calculation` shows a number worked out from other answers, such as a total or a score; its `formula` holds arithmetic (+ - * /, brackets, round, min, max) over other fields referenced as {{<field id>}}, e.g. \"{{qty}} * 25\". A choice answer counts as the first number in its text." - changed
Output schema / properties / fields / items / properties / type / enumPrevious value: -[ - "text", - "textarea", - "name", - "email", - "phone", - "url", - "address", - "number", - "select", - "radio", - "checkbox", - "ranking", - "rating", - "scale", - "date", - "time", - "file", - "upload", - "signature", - "appointment", - "heading", - "image", - "page-break", - "hidden" -]New value: +[ + "text", + "textarea", + "name", + "email", + "phone", + "url", + "address", + "number", + "select", + "radio", + "checkbox", + "ranking", + "rating", + "scale", + "date", + "time", + "file", + "upload", + "signature", + "appointment", + "heading", + "image", + "page-break", + "hidden", + "calculation" +]
- Changed
update_form3 fields changed- added
Input schema / properties / fields / items / properties / formulaAdded value: +{ + "maxLength": 500, + "type": "string" +} - changed
Input schema / properties / fields / items / properties / type / descriptionPrevious value: -"The field's input type. Two of these are easily confused: `upload` is the real file uploader, the respondent attaches an image, PDF or Word doc from their device, and is what you want for a CV, resume, photo, receipt, portfolio, certificate, or any \"attach\"/\"upload\" request. `file` is NOT an uploader: it only collects a URL the respondent types in, so use it only when the user explicitly asked for a link to a file hosted somewhere else."New value: +"The field's input type. Two of these are easily confused: `upload` is the real file uploader, the respondent attaches an image, PDF or Word doc from their device, and is what you want for a CV, resume, photo, receipt, portfolio, certificate, or any \"attach\"/\"upload\" request. `file` is NOT an uploader: it only collects a URL the respondent types in, so use it only when the user explicitly asked for a link to a file hosted somewhere else. `calculation` shows a number worked out from other answers, such as a total or a score; its `formula` holds arithmetic (+ - * /, brackets, round, min, max) over other fields referenced as {{<field id>}}, e.g. \"{{qty}} * 25\". A choice answer counts as the first number in its text." - changed
Input schema / properties / fields / items / properties / type / enumPrevious value: -[ - "text", - "textarea", - "name", - "email", - "phone", - "url", - "address", - "number", - "select", - "radio", - "checkbox", - "ranking", - "rating", - "scale", - "date", - "time", - "file", - "upload", - "signature", - "appointment", - "heading", - "image", - "page-break", - "hidden" -]New value: +[ + "text", + "textarea", + "name", + "email", + "phone", + "url", + "address", + "number", + "select", + "radio", + "checkbox", + "ranking", + "rating", + "scale", + "date", + "time", + "file", + "upload", + "signature", + "appointment", + "heading", + "image", + "page-break", + "hidden", + "calculation" +]
1 tool update
- Changed
create_invitation2 fields changed- changed
Input schema / properties / details / descriptionPrevious value: -"Everything known so far, an invitation saves fine half-filled. `preWedding` is the run-up (Mehndi, Haldi, Sangeet, Dholki…) and `ceremonies` the day itself (Baraat, Nikah, Rukhsati, Reception, Walima…); each entry needs only a `name`, with date/time/venue added as they are settled, and both lists stay in the order you send them. `colors.bg` and `colors.ink` override the template's ground and text colour. Leave them out unless the user asked for particular colours, because the template's own palette is already matched to its artwork."New value: +"Everything known so far, an invitation saves fine half-filled. `preWedding` is the run-up (Mehndi, Haldi, Sangeet, Dholki…) and `ceremonies` the day itself (Baraat, Nikah, Rukhsati, Reception, Walima…); each entry needs only a `name`, with date/time/venue added as they are settled, and both lists stay in the order you send them. `blessing` is the invocation the card opens with: `bismillah` (﷽), `ganesha` (the image with the Sanskrit shloka), `cross` (with Song of Solomon 3:4), or `none`. It reflects the couple's own stated choice; names do not indicate it, since names cross traditions and interfaith weddings are common. Omitted, the card opens with no invocation. `colors.bg` and `colors.ink` override the template's ground and text colour; omitted, the template's own palette applies, which is already matched to its artwork." - changed
Input schema / properties / templateId / descriptionPrevious value: -"From list_invitation_templates. Ask the user to choose; do not pick for them."New value: +"An invitation template id, as returned by list_invitation_templates. It sets the design and is fixed once the invitation is published."
2 tool updates
- Changed
create_form2 fields changed- changed
Input schema / properties / theme / descriptionPrevious value: -"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nSCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark:\n`lane`: pools, gyms, swimming, anything with water.\n`skyline`: property, architecture, city and office work.\n`ceremony`: weddings and formal invitations.\n`nightfield`: festivals, gigs, outdoor events after dark.\n`kiln`: studios, workshops, craft and making things by hand.\n`confetti`: parties, birthdays, celebrations.\n`supper`: restaurants, reservations, hospitality.\n`roastery`: cafes, coffee, drink orders.\n`expedition`: tours, travel, the outdoors.\n`salon`: salons, barbers, beauty appointments.\n`thermal`: spas, treatments, rest.\n`lecture`: courses, training, teaching.\n`atrium`: clinics and practices, calm and clinical.\n`marquee`: conferences, talks, ticketed events.\n`trailhead`: races, runs, outdoor signups.\n`pressroom`: photography, press, creative bookings.\nA scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting.\n\nPLAIN:\n`default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now.\n\nHow to choose:\n- They named a colour → the category preset or scene closest to it.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do."New value: +"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\n`chambers`: law, accountancy, consulting, anything that ends in a signature.\n`terminal`: engineering, IT, bug reports, internal tooling (dark).\n`meadow`: charities, community groups, volunteering, the environment.\n`civic`: councils, school offices, public services, official reports.\n`frost`: winter events, travel, and anything that should feel cool and unhurried.\nThese show a cover photo behind the title when the form has one.\n\nSCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark:\n`lane`: pools, gyms, swimming, anything with water.\n`skyline`: property, architecture, city and office work.\n`ceremony`: weddings and formal invitations.\n`nightfield`: festivals, gigs, outdoor events after dark.\n`kiln`: studios, workshops, craft and making things by hand.\n`confetti`: parties, birthdays, celebrations.\n`supper`: restaurants, reservations, hospitality.\n`roastery`: cafes, coffee, drink orders.\n`expedition`: tours, travel, the outdoors.\n`salon`: salons, barbers, beauty appointments.\n`thermal`: spas, treatments, rest.\n`lecture`: courses, training, teaching.\n`atrium`: clinics and practices, calm and clinical.\n`marquee`: conferences, talks, ticketed events.\n`trailhead`: races, runs, outdoor signups.\n`pressroom`: photography, press, creative bookings.\nA scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting.\n\nPLAIN:\n`default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now.\n\nHow to choose:\n- They named a colour → the category preset or scene closest to it.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do." - changed
Input schema / properties / theme / enumPrevious value: -[ - "default", - "editorial", - "blush", - "bistro", - "playground", - "studio", - "clinic", - "noir", - "lane", - "skyline", - "ceremony", - "nightfield", - "kiln", - "confetti", - "supper", - "roastery", - "expedition", - "salon", - "thermal", - "lecture", - "atrium", - "marquee", - "trailhead", - "pressroom" -]New value: +[ + "default", + "editorial", + "blush", + "bistro", + "playground", + "studio", + "clinic", + "noir", + "lane", + "skyline", + "ceremony", + "nightfield", + "kiln", + "confetti", + "supper", + "roastery", + "expedition", + "salon", + "thermal", + "lecture", + "atrium", + "marquee", + "trailhead", + "pressroom", + "chambers", + "terminal", + "meadow", + "civic", + "frost" +]
- Changed
update_form2 fields changed- changed
Input schema / properties / theme / descriptionPrevious value: -"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nSCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark:\n`lane`: pools, gyms, swimming, anything with water.\n`skyline`: property, architecture, city and office work.\n`ceremony`: weddings and formal invitations.\n`nightfield`: festivals, gigs, outdoor events after dark.\n`kiln`: studios, workshops, craft and making things by hand.\n`confetti`: parties, birthdays, celebrations.\n`supper`: restaurants, reservations, hospitality.\n`roastery`: cafes, coffee, drink orders.\n`expedition`: tours, travel, the outdoors.\n`salon`: salons, barbers, beauty appointments.\n`thermal`: spas, treatments, rest.\n`lecture`: courses, training, teaching.\n`atrium`: clinics and practices, calm and clinical.\n`marquee`: conferences, talks, ticketed events.\n`trailhead`: races, runs, outdoor signups.\n`pressroom`: photography, press, creative bookings.\nA scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting.\n\nPLAIN:\n`default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now.\n\nHow to choose:\n- They named a colour → the category preset or scene closest to it.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do."New value: +"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\n`chambers`: law, accountancy, consulting, anything that ends in a signature.\n`terminal`: engineering, IT, bug reports, internal tooling (dark).\n`meadow`: charities, community groups, volunteering, the environment.\n`civic`: councils, school offices, public services, official reports.\n`frost`: winter events, travel, and anything that should feel cool and unhurried.\nThese show a cover photo behind the title when the form has one.\n\nSCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark:\n`lane`: pools, gyms, swimming, anything with water.\n`skyline`: property, architecture, city and office work.\n`ceremony`: weddings and formal invitations.\n`nightfield`: festivals, gigs, outdoor events after dark.\n`kiln`: studios, workshops, craft and making things by hand.\n`confetti`: parties, birthdays, celebrations.\n`supper`: restaurants, reservations, hospitality.\n`roastery`: cafes, coffee, drink orders.\n`expedition`: tours, travel, the outdoors.\n`salon`: salons, barbers, beauty appointments.\n`thermal`: spas, treatments, rest.\n`lecture`: courses, training, teaching.\n`atrium`: clinics and practices, calm and clinical.\n`marquee`: conferences, talks, ticketed events.\n`trailhead`: races, runs, outdoor signups.\n`pressroom`: photography, press, creative bookings.\nA scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting.\n\nPLAIN:\n`default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now.\n\nHow to choose:\n- They named a colour → the category preset or scene closest to it.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do." - changed
Input schema / properties / theme / enumPrevious value: -[ - "default", - "editorial", - "blush", - "bistro", - "playground", - "studio", - "clinic", - "noir", - "lane", - "skyline", - "ceremony", - "nightfield", - "kiln", - "confetti", - "supper", - "roastery", - "expedition", - "salon", - "thermal", - "lecture", - "atrium", - "marquee", - "trailhead", - "pressroom" -]New value: +[ + "default", + "editorial", + "blush", + "bistro", + "playground", + "studio", + "clinic", + "noir", + "lane", + "skyline", + "ceremony", + "nightfield", + "kiln", + "confetti", + "supper", + "roastery", + "expedition", + "salon", + "thermal", + "lecture", + "atrium", + "marquee", + "trailhead", + "pressroom", + "chambers", + "terminal", + "meadow", + "civic", + "frost" +]
2 tool updates
- Changed
create_form2 fields changed- changed
Input schema / properties / theme / descriptionPrevious value: -"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nCOLOUR PALETTES (background and button colour only, default field styling):\n`default` (warm neutral), `midnight`/`ink` (dark), `royal`/`ocean` (blue), `forest` (green), `sunset` (orange), `rose` (pink), `plum` (purple), `slate` (grey).\n\nHow to choose:\n- They named a colour → that palette.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do."New value: +"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nSCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark:\n`lane`: pools, gyms, swimming, anything with water.\n`skyline`: property, architecture, city and office work.\n`ceremony`: weddings and formal invitations.\n`nightfield`: festivals, gigs, outdoor events after dark.\n`kiln`: studios, workshops, craft and making things by hand.\n`confetti`: parties, birthdays, celebrations.\n`supper`: restaurants, reservations, hospitality.\n`roastery`: cafes, coffee, drink orders.\n`expedition`: tours, travel, the outdoors.\n`salon`: salons, barbers, beauty appointments.\n`thermal`: spas, treatments, rest.\n`lecture`: courses, training, teaching.\n`atrium`: clinics and practices, calm and clinical.\n`marquee`: conferences, talks, ticketed events.\n`trailhead`: races, runs, outdoor signups.\n`pressroom`: photography, press, creative bookings.\nA scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting.\n\nPLAIN:\n`default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now.\n\nHow to choose:\n- They named a colour → the category preset or scene closest to it.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do." - changed
Input schema / properties / theme / enumPrevious value: -[ - "default", - "midnight", - "royal", - "forest", - "ocean", - "sunset", - "rose", - "plum", - "slate", - "ink", - "editorial", - "blush", - "bistro", - "playground", - "studio", - "clinic", - "noir" -]New value: +[ + "default", + "editorial", + "blush", + "bistro", + "playground", + "studio", + "clinic", + "noir", + "lane", + "skyline", + "ceremony", + "nightfield", + "kiln", + "confetti", + "supper", + "roastery", + "expedition", + "salon", + "thermal", + "lecture", + "atrium", + "marquee", + "trailhead", + "pressroom" +]
- Changed
update_form2 fields changed- changed
Input schema / properties / theme / descriptionPrevious value: -"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nCOLOUR PALETTES (background and button colour only, default field styling):\n`default` (warm neutral), `midnight`/`ink` (dark), `royal`/`ocean` (blue), `forest` (green), `sunset` (orange), `rose` (pink), `plum` (purple), `slate` (grey).\n\nHow to choose:\n- They named a colour → that palette.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do."New value: +"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nSCENES (a photograph behind the form, with the card tinted to match it). Reach for one when the form is for a real place or occasion and the user wants it to feel like that place. All are dark:\n`lane`: pools, gyms, swimming, anything with water.\n`skyline`: property, architecture, city and office work.\n`ceremony`: weddings and formal invitations.\n`nightfield`: festivals, gigs, outdoor events after dark.\n`kiln`: studios, workshops, craft and making things by hand.\n`confetti`: parties, birthdays, celebrations.\n`supper`: restaurants, reservations, hospitality.\n`roastery`: cafes, coffee, drink orders.\n`expedition`: tours, travel, the outdoors.\n`salon`: salons, barbers, beauty appointments.\n`thermal`: spas, treatments, rest.\n`lecture`: courses, training, teaching.\n`atrium`: clinics and practices, calm and clinical.\n`marquee`: conferences, talks, ticketed events.\n`trailhead`: races, runs, outdoor signups.\n`pressroom`: photography, press, creative bookings.\nA scene carries a photograph the user did not choose, so prefer a category preset unless they asked for imagery or described a setting.\n\nPLAIN:\n`default` (warm neutral, standard field styling). The flat colour palettes that used to sit here are retired: they still render on forms that already use them, but nothing should pick one now.\n\nHow to choose:\n- They named a colour → the category preset or scene closest to it.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do." - changed
Input schema / properties / theme / enumPrevious value: -[ - "default", - "midnight", - "royal", - "forest", - "ocean", - "sunset", - "rose", - "plum", - "slate", - "ink", - "editorial", - "blush", - "bistro", - "playground", - "studio", - "clinic", - "noir" -]New value: +[ + "default", + "editorial", + "blush", + "bistro", + "playground", + "studio", + "clinic", + "noir", + "lane", + "skyline", + "ceremony", + "nightfield", + "kiln", + "confetti", + "supper", + "roastery", + "expedition", + "salon", + "thermal", + "lecture", + "atrium", + "marquee", + "trailhead", + "pressroom" +]
3 tool updates
- Changed
create_form2 fields changed- added
Input schema / properties / fields / items / properties / imageUrlAdded value: +{ + "anyOf": [ + { + "format": "uri", + "type": "string" + }, + { + "pattern": "^\\/templates\\/(?:[a-z0-9-]+\\.svg|photos\\/[a-z0-9-]+\\.jpg)$", + "type": "string" + } + ] +} - changed
Input schema / properties / fields / items / properties / type / enumPrevious value: -[ - "text", - "textarea", - "email", - "phone", - "url", - "address", - "number", - "select", - "radio", - "checkbox", - "ranking", - "rating", - "scale", - "date", - "time", - "file", - "upload", - "signature", - "appointment", - "heading", - "page-break", - "hidden" -]New value: +[ + "text", + "textarea", + "name", + "email", + "phone", + "url", + "address", + "number", + "select", + "radio", + "checkbox", + "ranking", + "rating", + "scale", + "date", + "time", + "file", + "upload", + "signature", + "appointment", + "heading", + "image", + "page-break", + "hidden" +]
- Changed
get_form2 fields changed- added
Output schema / properties / fields / items / properties / imageUrlAdded value: +{ + "anyOf": [ + { + "format": "uri", + "type": "string" + }, + { + "pattern": "^\\/templates\\/(?:[a-z0-9-]+\\.svg|photos\\/[a-z0-9-]+\\.jpg)$", + "type": "string" + } + ] +} - changed
Output schema / properties / fields / items / properties / type / enumPrevious value: -[ - "text", - "textarea", - "email", - "phone", - "url", - "address", - "number", - "select", - "radio", - "checkbox", - "ranking", - "rating", - "scale", - "date", - "time", - "file", - "upload", - "signature", - "appointment", - "heading", - "page-break", - "hidden" -]New value: +[ + "text", + "textarea", + "name", + "email", + "phone", + "url", + "address", + "number", + "select", + "radio", + "checkbox", + "ranking", + "rating", + "scale", + "date", + "time", + "file", + "upload", + "signature", + "appointment", + "heading", + "image", + "page-break", + "hidden" +]
- Changed
update_form2 fields changed- added
Input schema / properties / fields / items / properties / imageUrlAdded value: +{ + "anyOf": [ + { + "format": "uri", + "type": "string" + }, + { + "pattern": "^\\/templates\\/(?:[a-z0-9-]+\\.svg|photos\\/[a-z0-9-]+\\.jpg)$", + "type": "string" + } + ] +} - changed
Input schema / properties / fields / items / properties / type / enumPrevious value: -[ - "text", - "textarea", - "email", - "phone", - "url", - "address", - "number", - "select", - "radio", - "checkbox", - "ranking", - "rating", - "scale", - "date", - "time", - "file", - "upload", - "signature", - "appointment", - "heading", - "page-break", - "hidden" -]New value: +[ + "text", + "textarea", + "name", + "email", + "phone", + "url", + "address", + "number", + "select", + "radio", + "checkbox", + "ranking", + "rating", + "scale", + "date", + "time", + "file", + "upload", + "signature", + "appointment", + "heading", + "image", + "page-break", + "hidden" +]
2 tool updates
- Changed
create_form3 fields changed- added
Input schema / properties / submitLabelAdded value: +{ + "anyOf": [ + { + "maxLength": 40, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Text on the final button, at most 40 characters. Write what pressing it does, in the form's own voice: \"Book my table\", \"Count me in\", \"Send my RSVP\". Omit for \"Submit\". Ignored on payment forms, whose button always states the amount." +} - changed
Input schema / properties / theme / descriptionPrevious value: -"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\n\nCOLOUR PALETTES (background and button colour only, default field styling):\n`default` (warm neutral), `midnight`/`ink` (dark), `royal`/`ocean` (blue), `forest` (green), `sunset` (orange), `rose` (pink), `plum` (purple), `slate` (grey).\n\nHow to choose:\n- They named a colour → that palette.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do."New value: +"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nCOLOUR PALETTES (background and button colour only, default field styling):\n`default` (warm neutral), `midnight`/`ink` (dark), `royal`/`ocean` (blue), `forest` (green), `sunset` (orange), `rose` (pink), `plum` (purple), `slate` (grey).\n\nHow to choose:\n- They named a colour → that palette.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do." - changed
Input schema / properties / theme / enumPrevious value: -[ - "default", - "midnight", - "royal", - "forest", - "ocean", - "sunset", - "rose", - "plum", - "slate", - "ink", - "editorial" -]New value: +[ + "default", + "midnight", + "royal", + "forest", + "ocean", + "sunset", + "rose", + "plum", + "slate", + "ink", + "editorial", + "blush", + "bistro", + "playground", + "studio", + "clinic", + "noir" +]
- Changed
update_form3 fields changed- added
Input schema / properties / submitLabelAdded value: +{ + "anyOf": [ + { + "maxLength": 40, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Text on the final button, at most 40 characters. Write what pressing it does, in the form's own voice: \"Book my table\", \"Count me in\", \"Send my RSVP\". Omit for \"Submit\". Ignored on payment forms, whose button always states the amount." +} - changed
Input schema / properties / theme / descriptionPrevious value: -"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\n\nCOLOUR PALETTES (background and button colour only, default field styling):\n`default` (warm neutral), `midnight`/`ink` (dark), `royal`/`ocean` (blue), `forest` (green), `sunset` (orange), `rose` (pink), `plum` (purple), `slate` (grey).\n\nHow to choose:\n- They named a colour → that palette.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do."New value: +"Visual preset: the form's entire look, not only its background colour.\n\nDESIGNED PRESETS (typography, field styling, depth and background together):\n`editorial`: warm paper, serif title, understated. This is the answer when the user asks for something beautiful, premium, elegant, polished, smart or professional without naming a colour.\nCategory presets, each with its own title font; pick by what the form is for:\n`blush`: weddings, engagements, beauty, celebrations.\n`bistro`: restaurants, cafes, catering, food orders, hotels.\n`playground`: schools, courses, kids' classes, summer camps.\n`studio`: gyms, fitness classes, sport, races (dark).\n`clinic`: healthcare, dental, therapy, patient intake.\n`noir`: tattoo, photography, music, creative studios (dark).\nThese show a cover photo behind the title when the form has one.\n\nCOLOUR PALETTES (background and button colour only, default field styling):\n`default` (warm neutral), `midnight`/`ink` (dark), `royal`/`ocean` (blue), `forest` (green), `sunset` (orange), `rose` (pink), `plum` (purple), `slate` (grey).\n\nHow to choose:\n- They named a colour → that palette.\n- The form clearly belongs to one of the categories above → that category preset.\n- They asked for it to look good but named no colour → `editorial`.\n- They asked for neither → OMIT. A form nobody asked to style stays default.\n\nEach preset is a matched set and cannot be mixed or set piecemeal. If the user asked for something none of these express (a specific hex value, two colours combined, a particular font), apply the nearest and tell them plainly what you could and couldn't do." - changed
Input schema / properties / theme / enumPrevious value: -[ - "default", - "midnight", - "royal", - "forest", - "ocean", - "sunset", - "rose", - "plum", - "slate", - "ink", - "editorial" -]New value: +[ + "default", + "midnight", + "royal", + "forest", + "ocean", + "sunset", + "rose", + "plum", + "slate", + "ink", + "editorial", + "blush", + "bistro", + "playground", + "studio", + "clinic", + "noir" +]
10 tool updates
- First observed
create_form - First observed
create_invitation - First observed
get_form - First observed
get_submission - First observed
list_forms - First observed
list_invitation_templates - First observed
list_submissions - First observed
list_templates - First observed
publish_invitation - First observed
update_form
Related MCP Connectors
AI-native form builder: create, publish & read responses from Claude, ChatGPT & MCP.
- mcpOAuthcom.formester
Give AI agents access to form submissions — read, search, update, and process file attachments.
Manage Chasync funnels, forms, email templates and leads from MCP-compatible AI assistants.
Generate PDFs from templates via AI chat. Works with Claude, ChatGPT, Cursor, and any MCP client.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceMCP server for Dashform (getaiform.com) - create and manage AI-powered forms, quizzes, and surveys. Supports form creation, response collection, analytics, and AI-driven form building with 15 tools across form management, response handling, and AI operations.MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for reading, editing, and publishing Google Forms with the official Google Forms API. Enables AI agents to programmatically create, modify, and manage forms and responses.MIT
- AlicenseNot gradedqualityAmaintenanceMCP server for Microsoft Forms automation, enabling AI agents to inspect forms, resolve branching, validate and submit answers, upload files, and manage response links.28 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.