livediagram

Add a form

add_form

Make a form (like Google Forms): a Form tab of questions, shared as a link anyone can fill in without an account. Each response becomes a card on a board (to work through: bug reports, requests, applications) or a row in a sheet (to count: RSVPs, feedback, surveys). From a starter, or from questions (or sections of them) of types short, paragraph, number, email, link, date, single, multi, rating and checkbox. On a board, each answer can be the card’s title, its description, or a card field (made when the card type lacks it). Without documentId it makes a document of its own. Answers as read_form does; share_form publishes it.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	The form’s heading, which is its tab’s name, up to 80 characters.
`theme`	No	The Form tab’s theme; the document’s when left out. A form wears its tab’s look.
`starter`	No	A ready-made form: bug-report, feature-request, job-application and contact send cards to a board; feedback and rsvp send rows to a sheet. Its questions, card type and fields come with it.
`sections`	No	Pages of questions, shown one at a time with Next and Back; a later one may show only on an earlier answer.
`settings`	No	When it closes, how many responses it takes, and its messages.
`questions`	No	The questions, in order, on one page. Use sections for several pages.
`documentId`	No	The document to add the Form tab to. Absent: a new document named after the form, holding it.
`respondsTo`	No	Where responses go. Absent: a starter’s own way; for questions, a new board.
`description`	No	A line under the heading (questions only; a starter brings its own).

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Link that opens the document in the livediagram editor.
`link`	Yes	The form link anyone can fill it in at; null unpublished or for a non-Editor.
`made`	No	The documents and tabs the call made.
`cover`	No	The cover band’s colours.
`lines`	No	What the call did.
`state`	Yes	accepting: the link takes responses. paused: published, but responses have nowhere to go.
`tabId`	Yes	The Form tab.
`unseen`	Yes	Responses the caller has not seen (opening the Form tab sees them).
`heading`	Yes	The form’s heading, which is its tab’s name.
`problems`	Yes	What stops it being published, in Share Form’s words; empty when ready.
`sections`	Yes	The pages of the form, in order.
`settings`	Yes	closesAt (ISO), limit, and the confirmation and closed messages respondents see.
`responses`	Yes	Responses so far.
`documentId`	Yes	The document.
`respondsTo`	Yes	Where responses go: {to: "board", board, cardType, column}, {to: "sheet", sheet} or {to: "nowhere"}.
`description`	No	The line under the heading.
`closedReason`	No	Why a published form is closed: switched_off, closes_at (its time passed) or limit (it is full).
`respondsToProblem`	No	Why responses cannot land there now.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 16, 2026

changedInput schema / properties / questions / items / properties / options / description

Previous value: -"single and multi: the options in order, 1 to 20, each up to 40 characters, unique."New value: +"single and multi: the options in order, 1 to 20, each up to 100 characters, unique."

changedInput schema / properties / sections / items / properties / questions / items / properties / options / description

Previous value: -"single and multi: the options in order, 1 to 20, each up to 40 characters, unique."New value: +"single and multi: the options in order, 1 to 20, each up to 100 characters, unique."

AddedOct 16, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorld=false) only tell the agent this is a non-destructive write. The description goes further, disclosing concrete side effects: creating a standalone document when documentId is absent, and spinning up new '<Form> Responses' board/sheet tabs with default content when board/sheet are absent. It stops short of permissions or limits, but adds real creation-behavior context.

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?

Purpose is front-loaded in the first clause, which is good. However, the description is dense and partly redundant, re-listing every question type ('short, paragraph, number, email, link, date, single, multi, rating and checkbox') already enumerated in the schema, and it crowds several ideas into long sentences.

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?

With an output schema present, return values need no explanation, and the description covers the essentials: what is created, the documentId-absent behavior, where responses land, and the read_form/share_form follow-ups. For a 9-param nested tool it is largely complete, missing only permission/error behavior.

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 still adds meaning: the board-vs-sheet framing for respondsTo ('to work through' vs 'to count'), the card-vs-sheet response model, and the goesTo mapping of answers to title/description/field. It reinforces rather than merely restating schema text.

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?

Opens with a concrete verb+resource ('Make a form (like Google Forms)') and quickly characterizes what a form is: a Form tab of questions shared as a link, responses becoming board cards or sheet rows. It also positions itself against siblings by noting 'Answers as read_form does; share_form publishes it,' so an agent can tell it apart from read/change/share form tools without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It implies the create path ('From a starter, or from questions...', 'Without documentId it makes a document of its own') and points at read_form and share_form for other lifecycle steps, but there is no explicit when-to-use/when-not-to-use guidance, and it never mentions change_form as the tool for modifying an existing form. Usage is inferable rather than stated.

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

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

Resources

Need Help?