Skip to main content
Glama

Create form

create_form
Idempotent

Use to add a form under an existing project_id. Idempotent on slug unless strict is true. Overrides are nullable; omit them to inherit project notify emails, webhook, redirect, require_turnstile, and email templates. Pass email.subject / email.intro to override notification copy for this form only. Pass webhook_url_override to send this form to a different URL. Field contract labels (label) are used on notification emails. Checkbox groups, select multiple, and other multi-value HTML fields must use a [] suffix on the name (name="services[]") or only the last checked value is stored. Put services[] on field_contract.name too. JSON/fetch should send a real array without brackets ({ "services": ["a", "b"] }) and must not use Object.fromEntries(formData) — use formData.getAll("services"). Single checkbox, select, or combobox: no brackets. File inputs use multipart POST (name="resume[]" for multiple). Enable uploads on the project first. Downloads are the project inbox at files_url, with the form slug as a folder — never put that URL in a public snippet.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesForm display name, e.g. Contact or Quote request.
slugYesLowercase hyphenated identifier, unique per project. Used for idempotent re-runs.
emailNoPer-form subject and intro overrides for the notification email.
strictNoWhen true, fail if the slug already exists instead of returning the existing record.
project_idYesProject (website) id from list_projects, create_project, or bootstrap_site.
field_contractNoDeclared fields (name, type, label, report). Drives get_snippet and the email layout. Null clears it.
webhook_url_overrideNoWebhook endpoint for this form only. Null inherits the project webhook.
redirect_url_overrideNoSuccess redirect for this form only. Null inherits default_redirect_url.
notify_emails_overrideNoRecipients for this form only. Null inherits the project's notify_emails.
webhook_secret_overrideNoHMAC secret for this form's webhook. Null inherits the project secret.
require_turnstile_overrideNoForce Turnstile on or off for this form. Null inherits the project setting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare write and idempotent behavior, but the description goes far beyond them: it explains how idempotency is affected by strict, how nullable overrides inherit project settings, multi-value [] suffix rules, JSON vs formData submission behavior, multipart file handling, and the security caveat about files_url. This is substantial behavioral disclosure with no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the core purpose, followed by inheritance rules and complex field-contract semantics. It is longer than a minimal definition, but every sentence carries functional information necessary for correct invocation. A slight structural split into paragraphs would improve scannability.

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?

The description covers prerequisites, idempotency, override inheritance, field naming traps, multi-value submission, file uploads, and download-folder security. It does not describe the create response shape, but no output schema exists and required fields are already in the schema. This is a minor gap for a tool this complex.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100%, the description adds meaning not present in the schema: bracket conventions for multi-value HTML fields, the Object.fromEntries pitfall, formData.getAll usage for JSON mode, the file-upload multipart requirement, and the fact that field labels appear in notification emails. This materially improves correct parameter construction.

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 specific verb and resource: 'add a form under an existing project_id.' This clearly identifies the creation action and distinguishes it from update, get, list, and archive tools. The idempotency-on-slug note further defines the tool's exact purpose.

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?

The description gives clear operational context such as 'under an existing project_id,' nullable overrides inheriting project settings, the strict idempotency switch, and the upload prerequisite. It does not explicitly name sibling alternatives like update_form or list_forms, but the usage context is unambiguous enough for an agent to select this tool properly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.