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
- 69.4% over 60 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- musaib001/deoochform-mcp
- GitHub Stars
- 0
- Server Listing
- Deoochform MCP Server
TDQS
A3.5/5.0
Scored across 10 tools
Disambiguation3/5
Two clear overlap clusters exist: create_form vs create_invitation (which the descriptions spend paragraphs disambiguating) and list_templates vs list_invitation_templates. The lengthy caveats in the descriptions help, but the fact that they are needed signals real boundary confusion between the form and invitation domains.
Naming Consistency5/5
All ten tools follow a strict verb_noun snake_case pattern: create_form, get_form, list_forms, update_form, publish_invitation, list_templates, etc. The convention is applied uniformly across both the form and invitation sub-domains.
Tool Count5/5
Ten tools is well within the ideal range and each maps to a distinct resource-action. No obvious padding or redundancy beyond the template listing pair.
Completeness3/5
The form side is fairly complete (create/get/list/update plus submissions and templates), but the invitation side only offers create, publish and template listing with no get/list/update, and there are no delete operations anywhere. Agents will hit dead ends managing existing invitations.
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. 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 the ready made templates; list_templates returns the slugs. A template brings its own field set, colour theme and header artwork, which hand written fields don't include. 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/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the mutation/safety profile is covered. The description adds one genuinely new behavioral fact — that a successful create yields a public link, i.e. the created object is externally shareable — but says nothing about permissions, reversibility, or cleanup of the public link, so it only partially extends 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?
Three short sentences, front-loaded with the action and its result, then the disambiguation rule. Every sentence earns its place and nothing is repeated from the schema or annotations.
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?
An output schema exists, so return shape need not be described, and the schema documents the nine parameters thoroughly. The description covers creation semantics and the sibling overlap, though it omits any note on what happens on a failed create or how the returned link relates to publish/invitation flows.
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 high (78%) and the schema itself carries unusually rich parameter guidance (theme presets, field types, upload vs file, templateSlug semantics, notAnInvitation), so the baseline is 3. The description contributes no parameter-level detail of its own; it spends its text on object disambiguation instead.
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?
States a specific verb and resource ('Create a new form'), names the return artifact (public link), and explicitly differentiates from the sibling create_invitation by warning that 'wedding invitation form' usually means the invitation page rather than a questionnaire. An agent can disambiguate without opening either schema.
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?
Gives a clear when-not-to-use rule with the alternative named (create_invitation), which is the highest-risk confusion for this tool. It does not, however, cover the other selection choices an agent faces on this tool, such as templateSlug vs hand-written fields or when a plain questionnaire is appropriate versus an invitation.
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?
Annotations already declare openWorldHint=true and idempotentHint=true; the description is consistent with both, describing a public-facing publication whose repetition is harmless. It adds useful preconditions (required fields) beyond the annotations but says nothing about who may publish or what happens to the draft afterward.
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, purpose front-loaded ahead of the prerequisite, with no filler. The second sentence is slightly run-on in enumerating the required fields and could be tightened.
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 tool with an output schema (so return values need no prose) and full annotation coverage, the description supplies the essentials: effect, public visibility, and a pre-publication validation loop through create_invitation. Only the provenance of invitationId is left unstated.
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?
There is one parameter (invitationId) at 0% schema description coverage, so the description carries the burden and only indirectly implies it via 'draft invitation'. It never says where invitationId comes from (e.g. created by create_invitation or listed elsewhere).
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?
States a specific verb and resource plus the concrete effect: a draft invitation goes live at its public link and starts collecting RSVPs. It is clearly distinguishable from create_invitation, which it explicitly references, though it doesn't contrast against update_form or the other siblings.
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?
Gives an actionable precondition: the invitation must already carry names, date, time and venue, and the agent is told to have the user supply whatever is missing before calling. It stops short of naming alternatives (e.g. what to use for later edits to a live invitation) or stating when not to publish.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_formUpdate formCDestructiveInspect
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. 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
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so safety is partly covered, but the description adds nothing about the crucial update semantics: whether omitted fields are preserved or cleared, whether passing `fields` replaces the whole array, or whether editing a published form affects live responses. For a destructive, non-idempotent mutation it should disclose more than it does.
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?
A single front-loaded sentence of nine words with zero filler. Its brevity costs it nothing structurally, though it is arguably too thin for a nine-parameter mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, three enums, a nested rules/fields structure, and destructive non-idempotent annotations, the description is far too sparse. An output schema exists so return values need no explanation, but the update semantics and the existence of theme/layout/rules parameters are entirely absent.
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 56%, and the description names only four of nine parameters (title, description, fields, status) while adding no meaning beyond the schema for any of them. The behaviorally significant parameters (theme, layout, rules, submitLabel) and the partial-vs-full update question go unaddressed in the description.
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?
States a specific verb (Update) and resource (form) and names four of the mutable aspects (title, description, fields, status), which is enough to distinguish it from create_form/get_form/list_forms siblings. However, it never explicitly contrasts itself with those siblings or notes that it modifies an existing form by id.
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 gives no when-to-use guidance, no prerequisites (such as needing an existing formId), and no mention of alternatives or when not to call it. It is a bare capability statement with no routing information.
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.
2 tool updates
- Changed
create_form2 fields changed- changed
Input schema / properties / layout / descriptionPrevious value: -"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."New value: +"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. 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." - changed
Input schema / properties / templateSlug / descriptionPrevious value: -"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."New value: +"Start from one of the ready made templates; list_templates returns the slugs. A template brings its own field set, colour theme and header artwork, which hand written fields don't include. 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."
- Changed
update_form1 field changed- changed
Input schema / properties / layout / descriptionPrevious value: -"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."New value: +"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. 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."
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.
formset builds hosted forms from a description in chat. Ask Claude or ChatGPT for a signup sheet, RSVP, survey or poll; formset hosts it at a shareable link, collects the answers and reads them back to you, down to a CSV export. Respondents need no account.
Form backend for AI agents: create live form endpoints, configure them, read submissions.
- mcpOAuthcom.formester
Give AI agents access to form submissions — read, search, update, and process file attachments.
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
formbase MCP serverofficial
AlicenseNot gradedqualityAmaintenanceEnables AI agents to collect and verify customer information by creating prefilled, branded form requests for individual recipients, reading their submissions, and building, publishing, translating, and sharing forms through a hosted MCP connection.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
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.