Skip to main content
Glama
Sign In

Convika

by com.convika
OverviewDiscussionsAdmin

Create form

create_form

Add a contact form, email signup, or lead capture form to a landing page.

Use when the user wants to collect submissions from visitors (e.g. "add a contact form", "collect emails", "add a signup form", "take cash-on-delivery orders", "take reservations", 「お問い合わせフォーム」「注文フォーム」「予約フォーム」). Convika handles submission storage, spam protection (honeypot), and optional email notifications automatically. Give the form the fields the page asks for, not a generic name/email/message: an order form asks for what the shop needs (name, a tel field for the phone or WhatsApp number, a select of cities or governorates, an address textarea, a number for quantity), a reservation form for a date and the party size. Every answer is stored as text; a checkbox group's ticked options are joined with ", ". Entries are listed and exported (CSV) under the field labels, and the entry email links a tel answer for calling. After creating the form, embed it in the page HTML using save_page_content with the returned form ID, then call create_preview so the preview shows the form. Use get_form_submissions to view collected production data. Preview submissions validate the form but are not stored and do not trigger webhooks. A form needs an existing siteId. For a brand-new page, call create_landing_page_preview first (it returns the siteId), then this tool, then save_page_content with the embed, then create_preview. Available on all plans. Free shows 50 submissions a month; later ones are still saved and held from view (up to 1,000 more per form a month) and show on Pro. Pro/MAX: no monthly limit.

HTML embed example (use JavaScript fetch, NOT with method="POST"):

IMPORTANT: Replace {formId} with the actual form ID. Replace {successMessage} with the form's successMessage or a suitable thank-you message. Do NOT use — always use the JavaScript fetch approach above to submit to /_form.

Input Schema

NameRequiredDescriptionDefault
fieldsYesForm fields configuration
siteIdYesThe ID of the page to create the form for
notifyEmailNoEmail address to receive submission notifications
successMessageNoMessage shown after successful submission
submitButtonLabelNoCustom label for the submit button (default: 'Submit')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / siteId / description
      Previous value: -"The ID of the site to create the form for"New value: +"The ID of the page to create the form for"
  2. Changed1 schema field changed
    • changedInput schema / properties / notifyEmail / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  3. Changed3 schema fields changed
    • addedInput schema / properties / fields / items / properties / options
      Added value: +{
+  "description": "For select, radio, and checkbox: what the visitor picks from, each both the text shown and the answer stored (e.g. ['Cairo', 'Giza', 'Alexandria']). Required for select and radio; leave it out for other types.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 300,
+  "type": "array"
+}
    • changedInput schema / properties / fields / items / properties / type / description
      Previous value: -"Field type: text, email, or textarea"New value: +"Field type: text, email, textarea, tel (a phone or WhatsApp number), number, date (sent as YYYY-MM-DD), select (a dropdown), radio (pick one), or checkbox (tick any; without options, one box such as 'I agree')"
    • changedInput schema / properties / fields / items / properties / type / enum
      Previous value: -[
-  "text",
-  "email",
-  "textarea"
-]New value: +[
+  "text",
+  "email",
+  "textarea",
+  "tel",
+  "number",
+  "date",
+  "select",
+  "radio",
+  "checkbox"
+]
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already state readOnly=false, destructive=false, and idempotent=false, but the description adds substantial context beyond them: automatic submission storage, honeypot spam protection, optional email notifications, plan limits (50 free submissions/month, held entries up to 1,000, Pro unlimited), and the fact that preview submissions validate but are not stored or trigger webhooks. It also specifies how answers are stored as text and how checkbox groups are joined.

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 front-loaded with purpose and usage, but it is extremely long and includes a full HTML form plus a lengthy JavaScript fetch example. While relevant to correct embedding, this level of detail bloats the tool description and could be trimmed or moved to separate documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with no output schema, the description covers prerequisites, workflow, plan limits, submission behavior, field design, and embedding requirements. An agent has enough information to invoke the tool correctly and follow up with the right sibling tools.

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 baseline is 3. The description adds meaningful guidance beyond the schema by instructing the agent to tailor fields to the page (e.g. order forms need tel, select, address, quantity; reservation forms need date and party size) and by mapping field types to HTML inputs and storage behavior.

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 contact form, email signup, or lead capture form to a landing page.' It clearly distinguishes the tool from page-creation siblings by explaining the prerequisite siteId and the create_landing_page_preview workflow.

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?

It gives explicit when-to-use examples in multiple languages and lists the exact workflow: create_landing_page_preview for new pages, then create_form, then save_page_content, then create_preview. It also names related tools for viewing submissions (get_form_submissions) and embedding (save_page_content).

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

All Convika toolsInspect
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.

Resources