Wayfront

Form Write Tool

form-write

Destructive

Create or update forms. Creation requires type, name and the full initial fields list. Updating fields replaces the full list and deletes omitted fields; preserve existing field IDs. Omit fields to change form settings only. Order/contact forms require email, and order forms require a service-bearing field. Field edits are blocked for forms with white-labeled services.

Input Schema

Name	Required	Description
`info`	No	Form description/instructions shown to users. Optional.
`name`	No	Form name. Required for "create", optional for "update".
`type`	No	Form type. Required for "create".
`action`	Yes	Action to perform.
`coupon`	No	Enable coupon field on order forms. Only applicable to order forms.
`fields`	No	Form fields. Required for "create" (min 1). For "update": include id to edit, omit id to create new, fields not listed are deleted.
`form_id`	No	Form id. Required when updating an existing record.
`folder_id`	No	Folder ID to organize the form. Set to null to remove the form from all folders; omit to leave it unchanged. The folder must match the form type.
`access_key`	No	URL-safe access key for the form. Optional, auto-generated if not provided.
`redirect_url`	No	Redirect URL after contact form submission. Only applicable to contact forms.
`has_sidebar_link`	No	Show link in client portal sidebar. Only for order and onboarding forms.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / fields / items / properties / is_rows_limited_to_quantity

Added value: +{
+  "description": "data-spreadsheet fields on intake forms only: limit rows to the order's purchased quantity (missing quantity counts as 1). Ignored when rows is set.",
+  "type": "boolean"
+}

First observedSep 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, and the description earns that flag by spelling out exactly what is destroyed: 'Updating fields replaces the full list and deletes omitted fields.' It also discloses validation gates (email on contact forms, a service-bearing field on order forms) that are not visible in the schema.

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

Conciseness5/5

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

Four dense sentences, each carrying a distinct rule, with the create/update distinction front-loaded before the destruction caveat and the type-specific constraints. No filler.

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 an 11-parameter destructive mutation with no output schema, the description covers the risky paths well. Minor gaps remain: no mention of the return value or whether a failed update leaves the form partially modified, and the white-label block is stated without saying how to detect it beforehand.

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 coverage is 100%, so the baseline is 3; the description goes beyond it by stating conditional requirements that live nowhere in the schema — order/contact forms require email, order forms require a service-bearing field, and preserve existing field IDs on update. It does not explain the less obvious params (folder_id null-vs-omit, access_key, has_sidebar_link), which the schema already handles.

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 specific verbs plus resource ('Create or update forms') and immediately scopes the two actions by their differing requirements. An agent can distinguish this from form-read without opening any 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 concrete when-conditions: creation needs type/name/fields, update with fields replaces the list, omitting fields changes settings only, and field edits are blocked for white-labeled services. It stops short of naming sibling alternatives (form-read, form-folder-write) but the routing conditions are explicit.

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

All Wayfront 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.

Resources

Need Help?