furrow-forms

Create project

create_project

Idempotent

Use to add one website under an existing client_id. Idempotent on slug unless strict is true. Free accounts are limited to 3 active (non-archived) projects; yearly is unlimited. If create_project returns plan_limit, call create_upgrade_link and hand the human the Stripe URL. Prefer bootstrap_site when the client does not exist yet. Optional email sets notification templates (subject, from_name, intro, footer_mode, include_meta). Free accounts keep footer_mode furrow; other values return plan_limit. Set uploads_enabled on the project to accept files. Email templates support {{project.name}}, {{project.slug}}, {{form.name}}, {{form.slug}}, {{count}} (1-based clean submissions on this form, including the current one), and any submission field such as {{name}} or {{email}}. Use a fallback with {{name | "New submission"}}. Missing fields render empty and never error. Do not pass HTML; Furrow renders one owned layout. Plans are capacity, not a feature ladder. Free: one workspace, 100 clean submissions/month pooled on the team, 3 active (non-archived) projects, 30-day submission retention, and email.footer_mode / branding.mode stay furrow (other values return plan_limit). Yearly ($199/year): extra workspaces, 10,000 submissions/month, unlimited projects, 730-day retention, branding.mode furrow | off | agency. Expansion packs are $99/year each and add 5,000 submissions/month on a yearly account. MCP, webhooks, snippets, inheritance, Turnstile, and email templates stay available on free. Spam, honeypot, and rejected posts do not count. Use create_upgrade_link to hand a human a Stripe Checkout (or Customer Portal) URL. Pass product=expansion on a yearly team to add a pack. 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. Do not put Turnstile keys on a form.

Input Schema

Name	Required	Description
`name`	Yes	Project (website) display name.
`slug`	Yes	Lowercase hyphenated identifier, unique per client. Used for idempotent re-runs.
`email`	No	Notification email template for the project: subject, from_name, intro, footer_mode, include_meta.
`strict`	No	When true, fail if the slug already exists instead of returning the existing record.
`client_id`	Yes	Client id from list_clients or create_client.
`from_name`	No	Legacy From display name. Prefer email.from_name.
`notify_cc`	No	Cc'd on every notification email (max 10). Copies only: an email still needs at least one notify_emails address, and an address on more than one list is sent once (To, then Cc, then Bcc). Copies get [Potential spam] emails too.
`notify_bcc`	No	Bcc'd on every notification email (max 10), hidden from the other recipients — use it when an agency wants a silent copy of a client's leads. Copies only: an email still needs at least one notify_emails address, and an address on more than one list is sent once (To, then Cc, then Bcc). Copies get [Potential spam] emails too.
`webhook_url`	No	Public https endpoint that receives a signed JSON POST per clean submission. Null disables it.
`notify_emails`	No	Addresses that receive each clean submission (max 10). Inherited by every form. Required unless webhook_url is set — ask the human which inbox should get submissions.
`notify_phones`	No	E.164 numbers that get a short "new lead, check your email" text per clean submission (max 5). Inherited by every form. Never sent for spam. Text messages need the team's own Twilio account first (update_account sms).
`honeypot_field`	No	Name of the hidden honeypot input the snippet emits. Defaults to _gotcha.
`webhook_secret`	No	HMAC-SHA256 secret for the X-Furrow-Signature header. Omit to have one generated and returned.
`allowed_domains`	No	Hostnames allowed to post to this project's forms (example.com, www.example.com). Empty accepts any origin.
`uploads_enabled`	No	Accept multipart file fields on this project's forms.
`turnstile_secret`	No	Cloudflare Turnstile secret used to verify tokens server-side. Null removes it.
`upload_max_files`	No	Max files per submission (up to 20).
`rate_limit_per_ip`	No	Max submissions per IP within rate_limit_window_s.
`require_turnstile`	No	Reject submissions that lack a valid Turnstile token.
`turnstile_site_key`	No	Cloudflare Turnstile site key for the frontend widget. Null removes it.
`rate_limit_window_s`	No	Rate-limit window in seconds (max 86400).
`default_redirect_url`	No	Where classic HTML posts redirect after success. Null returns JSON/inline success instead.
`upload_allowed_types`	No	Allowed upload MIME types, e.g. application/pdf or image/*.
`upload_max_file_bytes`	No	Max bytes per file (up to 25 MB).
`upload_max_total_bytes`	No	Max total upload bytes per submission (up to 50 MB).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 29, 2026

changedInput schema / properties / notify_bcc / items / 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,}$"

changedInput schema / properties / notify_cc / items / 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,}$"

changedInput schema / properties / notify_emails / items / 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,}$"

Changed2 schema fields changedOct 29, 2026

addedInput schema / properties / notify_bcc

Added value: +{
+  "description": "Bcc'd on every notification email (max 10), hidden from the other recipients — use it when an agency wants a silent copy of a client's leads. Copies only: an email still needs at least one notify_emails address, and an address on more than one list is sent once (To, then Cc, then Bcc). Copies get [Potential spam] emails too.",
+  "items": {
+    "format": "email",
+    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

addedInput schema / properties / notify_cc

Added value: +{
+  "description": "Cc'd on every notification email (max 10). Copies only: an email still needs at least one notify_emails address, and an address on more than one list is sent once (To, then Cc, then Bcc). Copies get [Potential spam] emails too.",
+  "items": {
+    "format": "email",
+    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

Changed2 schema fields changedOct 28, 2026

changedInput schema / properties / notify_emails / description

Previous value: -"Addresses that receive each clean submission (max 10). Inherited by every form."New value: +"Addresses that receive each clean submission (max 10). Inherited by every form. Required unless webhook_url is set — ask the human which inbox should get submissions."

addedInput schema / properties / notify_phones

Added value: +{
+  "description": "E.164 numbers that get a short \"new lead, check your email\" text per clean submission (max 5). Inherited by every form. Never sent for spam. Text messages need the team's own Twilio account first (update_account sms).",
+  "items": {
+    "maxLength": 32,
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

First observedSep 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the idempotent annotation, the description explains idempotency on slug unless strict is true, free-account project limits, plan_limit behavior, footer_mode constraints on free accounts, and that uploads must be enabled before file inputs work. It also discloses template rendering behavior and warns not to put the project inbox URL in a public snippet.

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

Conciseness2/5

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

The purpose and idempotency behavior are front-loaded, but the description then expands into pricing tiers, expansion packs, monthly submission capacity, retention periods, and MCP/webhook availability. Much of that is product documentation rather than guidance needed to create a project, so the definition is substantially bloated.

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 25-parameter tool with a nested email object and no output schema, the description covers the important invocation context: client existence, idempotency, plan-limit handling, email token behavior, and upload prerequisites. It does not describe the normal return shape beyond special cases like plan_limit and generated webhook_secret, which is the main remaining gap.

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, but the description adds meaningful semantics for the optional email object, token interpolation and fallback syntax, footer_mode limitations, and enabling uploads. It still leaves many of the 25 parameters to the schema, which is reasonable given the full schema descriptions.

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 opening sentence states a specific verb and resource: add one website under an existing client_id. It also distinguishes itself from bootstrap_site for the case where the client does not yet exist, so an agent can tell the two apart 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to prefer bootstrap_site and what to do when create_project returns plan_limit by routing to create_upgrade_link. These are concrete alternatives and error-routing instructions, not merely implied usage.

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

All furrow-forms tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Create project

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources