Fillo

Create or update a form and take it live

fillo_push_form

Destructive

Create or update a form from a FormSchema plus a stable handle (an idempotent id — reuse it to update the same form), then publish it by default. With auto-publish permission the form goes live in this call; otherwise the call returns a human approval link that completes publication. Set publish=false only when the user explicitly asks for a draft or review. File requests stay draft when storage setup blocks publication. Handle: letters, digits, dashes, max 64 chars. The owner can also edit the form in the Fillo dashboard; if they have since your last push, the push is refused so their changes aren't overwritten — fillo_pull_form it, apply your change on top, and push with baseRevision.

Input Schema

TableJSON Schema

Name	Required	Description
`theme`	No	Optional theme: colorScheme, primary, background, text, radius, fontFamily, logo (an image id from fillo_import_logo), and dark ({ primary, background, text, logo }) — the dark-mode palette used when colorScheme is omitted or "auto". A custom background without dark colors keeps the form in that one scheme; give both palettes to follow light and dark.
`handle`	Yes	Stable idempotent form id (letters, digits, dashes, max 64). Reuse to update.
`schema`	Yes	The FormSchema object: title, pages (with blocks/fields), and settings.
`publish`	No	Publish after writing (default true). Set false only for an explicitly requested draft/review workflow.
`purpose`	No	Marks the durable file-request journey and preserves its required upload field.
`storage`	No	Optional exact storage destination. Required with purpose=file_request.
`baseRevision`	No	The revisionId from fillo_pull_form that this change was built on. Needed only after the owner edited the form in the dashboard since your last push.
`allowBreaking`	No	Acknowledge removing/re-typing fields used by existing responses. Confirm with the user first.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Always true after a successful write and optional publication.
`url`	No	Hosted URL when the result is live.
`slug`	Yes
`formId`	Yes
`staged`	Yes	True when the write left changes waiting for a publish.
`status`	Yes	The form's lifecycle status after the write.
`changed`	Yes	False when the push matched existing content exactly (no-op).
`created`	Yes	True when a new draft form was created.
`warning`	No	Owner action required before publishing.
`warningUrl`	No	Owner-facing Fillo page that resolves the blocker.
`warningCode`	No	Stable blocker code when setup is incomplete.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / baseRevision

Added value: +{
+  "description": "The revisionId from fillo_pull_form that this change was built on. Needed only after the owner edited the form in the dashboard since your last push.",
+  "type": "string"
+}

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / theme / description

Previous value: -"Optional theme tokens (colorScheme, primary, background, text, radius, fontFamily)."New value: +"Optional theme: colorScheme, primary, background, text, radius, fontFamily, logo (an image id from fillo_import_logo), and dark ({ primary, background, text, logo }) — the dark-mode palette used when colorScheme is omitted or \"auto\". A custom background without dark colors keeps the form in that one scheme; give both palettes to follow light and dark."

AddedSep 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true): describes the auto-publish permission branch and the human approval link fallback, the draft fallback when storage setup blocks publication, and the conflict-refusal behavior that protects dashboard edits. Note the handle is described as an idempotent id for the target form, which is resource identity, not a claim that the call itself is idempotent, so it does not contradict idempotentHint=false.

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?

Front-loaded with purpose and default behavior, then the exceptions in descending priority. Sentences are information-dense with no filler, though the conflict-handling sentence is long enough that it slightly taxes readability.

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 an 8-parameter, nested-schema mutation with an output schema present, this covers the branches an agent must reason about: permission-gated publish, approval-link path, draft fallback, and revision conflicts. Nothing needed to invoke it correctly is missing.

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 already 100%, so the baseline is 3; the description earns extra credit by supplying workflow context the schema omits — why baseRevision is needed (dashboard edits since last push), when allowBreaking applies and that the user must confirm first, and what publish=false means contextually.

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 (create or update) and resource (a form), and adds the key scope detail: it also publishes by default. It distinguishes itself from siblings by naming fillo_pull_form as the conflict-resolution alternative, so an agent can route correctly 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 Guidelines5/5

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

Explicit guidance: publish defaults true, publish=false only on an explicit draft/review request, file requests auto-stay draft when storage blocks, and the baseRevision pull-then-push flow when the owner edited in the dashboard. This is when-to-use/when-not plus named alternatives.

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

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