Tommos

Update a Smart Form

update_form

Idempotent

Update a Smart Form's configuration — the same fields the form editor saves. Pass form (id or slug) plus only the fields to change. fields replaces the whole field list and must include one field named "email" of type "email". success_mode: "booking" needs an event_type_id from list_events (the booking step's hours and duration live on that event). Returns the updated form.

Input Schema

Name	Required	Description
`form`	Yes	Form id or slug to update
`name`	No	Internal form name
`slug`	No	Public slug (a-z, 0-9, dashes); the embed snippet uses it
`title`	No	Heading shown on the widget
`fields`	No	The full field list, in order
`subtitle`	No	Muted line under the title
`is_active`	No	Published: true publishes what the form holds after this update (as publish_a_form does); false unpublishes it
`consent_md`	No	Consent / fine print, markdown (links allowed)
`show_title`	No
`create_deal`	No	Also open a deal on the default pipeline
`redirect_url`	No	http(s) URL (success_mode redirect)
`submit_label`	No	Submit button text
`success_mode`	No
`booking_intro`	No
`event_type_id`	No	Event to book after submit (success_mode booking)
`notify_emails`	No	Who gets the new-submission email
`show_subtitle`	No
`captcha_enabled`	No
`consent_enabled`	No
`success_message`	No	Thank-you text (success_mode message)
`consent_position`	No	Relative to the submit button
`booking_preheader`	No
`confirmation_body`	No	Plain text; merge tags like {{name}} allowed
`delivery_file_ids`	No	The files of this workspace's Files every submitter is sent (the editor's Delivery tab): the whole list, replacing the one before; [] sends none. add_a_file_from_a_link answers a file's id.
`notification_intro`	No
`confirmation_enabled`	No	Email the submitter a confirmation
`confirmation_subject`	No
`confirmation_preheader`	No
`notification_preheader`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 8, 2026

addedInput schema / properties / delivery_file_ids

Added value: +{
+  "description": "The files of this workspace's Files every submitter is sent (the editor's Delivery tab): the whole list, replacing the one before; [] sends none. add_a_file_from_a_link answers a file's id.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, so the write profile is covered. The description adds real behavioral context beyond that: it flags that `fields` overwrites the entire ordered field list (so omitted fields are lost), imposes the email-field invariant, and notes the return ('the updated form'). It does not discuss auth requirements or failure modes, keeping it short of a 5.

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 tight paragraph, front-loaded with the core action and identifier, then the replacement invariant, then the one conditional prerequisite. Every sentence carries a constraint or a behavior; nothing is redundant restatement of the schema.

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 29-parameter partial-update tool with no output schema, the description supplies what the schema structurally cannot: replacement-vs-merge semantics, a required structural invariant, the cross-tool lookup for booking mode, and an explicit return value. An agent has enough to call this correctly without guessing.

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?

With 29 parameters and only 62% schema description coverage, the description has to compensate and does so for the highest-risk ones: `form` accepts id or slug, `fields` is a wholesale replacement with an email-type invariant, and the success_mode/event_type_id coupling is spelled out with the cross-tool dependency. The long tail of boolean/string toggles is left entirely to the schema, so it doesn't fully close the coverage gap.

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+resource ('Update a Smart Form's configuration') and scopes it precisely as partial-update ('plus only the fields to change'), which cleanly separates it from create_a_form, duplicate_a_form, and delete_a_form in the sibling list. The 'same fields the form editor saves' framing tells an agent exactly which surface this tool maps to.

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 clear conditions for key parameters: pass `form` plus only changed fields, `fields` must be a full replacement containing one email-typed field, and `success_mode: "booking"` requires an `event_type_id` sourced from list_events. It never names an alternative tool to use instead in a given situation (e.g. publish_a_form), so the routing guidance is contextual rather than exclusionary.

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

All Tommos tools Inspect

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.

Update a Smart Form

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources