formset builds hosted forms from a description in chat. Ask Claude or ChatGPT for a signup sheet, RSVP, survey or poll; formset hosts it at a shareable link, collects the answers and reads them back to you, down to a CSV export. Respondents need no account.
Scored across 14 tools
Each tool targets a distinct resource or action: form lifecycle, response reading/analysis/export, sharing, banner upload, search, and connection check are cleanly separated. The generic fetch/search tools have slight overlap with get_form/list_forms, but descriptions clearly route by query vs known id.
Most names follow a predictable verb_noun pattern (create_form, get_response_stats, set_form_status, export_responses). The single-word fetch, search, and ping are standard but minor deviations from the otherwise consistent convention.
14 tools is within a well-scoped range for a form-building and response-management server. Each tool covers a distinct part of the workflow, including creation, editing, sharing, response analysis, and deletion.
The surface covers full form lifecycle CRUD plus status changes, response listing/stats/export, public sharing links, banner upload, search, and fetch. No significant operational gaps are apparent for the stated domain.
Create a hosted form and get back a public URL to share.
Call this when someone wants to collect answers from other people — a signup, an intake questionnaire, an RSVP, a feedback survey, a poll. For changing a form that already exists call update_form instead; to see what forms exist call list_forms.
You write the fields. Infer the type from what the question is actually asking: an email address is type "email", not "short_text"; a 1-5 rating is "rating"; a yes/no is "boolean". Write "key" values that read well as spreadsheet column headers, because that is where they end up.
Example: { "title": "Workshop signup", "fields": [ { "key": "full_name", "type": "short_text", "label": "Your name", "required": true }, { "key": "email", "type": "email", "label": "Email address", "required": true }, { "key": "session", "type": "single_select", "label": "Which session?", "options": [{ "value": "am", "label": "Morning" }, { "value": "pm", "label": "Afternoon" }] }, { "key": "dietary", "type": "long_text", "label": "Dietary requirements", "visible_when": { "field": "session", "op": "eq", "value": "pm" } } ] }
A "visible_when" condition may only reference a field defined earlier in the array.
Every question is required unless you say otherwise — "required" defaults to true, so omit it for a question someone must answer and set it to false deliberately for one they may skip. A "rating" is the one exception: it defaults to optional, because ratings arrive as a battery and requiring each row makes someone with no opinion invent a middle score. Set "required": true on a rating if you really need it.
Length is a design decision, and it is yours. Every question costs responses. Someone asking for "a list of activities" or "some questions about X" has not told you how many they want — they have left it to you, and the honest answer is usually fewer than you can think of. Aim for eight or ten questions. Past that, ask before you build: "I can rate twelve activities or pick the six most likely — which?"
Use what you know about the occasion to narrow, not to enumerate. A Nashville girls trip suggests honky-tonks, hot chicken and a pedal tavern; a company offsite suggests none of those. That knowledge is what makes a form feel written rather than generated — but it earns its place by producing the six best options, not every option you can name. A respondent scoring fourteen activities stops reading and starts pattern-filling, and the owner gets noise back.
Say what you assumed. If you inferred a year, a city, a start date or an audience from context, name it in one line when you hand over the link, so it can be corrected before the form goes out.
Before creating the form, ask about any question you are not sure of rather than guessing. A required question a respondent cannot answer is a dead end: they abandon the form, and the owner never learns why. Three cases worth a follow-up almost every time:
a question that will not apply to everyone ("spouse's name", "company"), which is either optional or belongs behind a "visible_when" condition;
anything sensitive — a phone number, an address, a date of birth — where making it required costs responses;
a battery of similar questions — several ratings in a row — which should be optional, so someone with no opinion can skip rather than invent a middle score. A "rating" is optional unless you say otherwise, for exactly this reason.
One short question covering all of them is better than one per field. If the person has already been clear, or has asked you to just build it, build it.
Three settings exist for when someone asks for them, all on the paid plan: "settings.theme" sets the form's colours, "settings.password" hides the form behind a shared password (for "only my team should see this"), and "settings.payment_links" puts payment buttons on the thank-you page (for "people should Venmo me $25 when they sign up"). Say how much to pay in "thanks_message"; the buttons only link to the owner's page and formset never learns whether anyone paid.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| fields | Yes | ||
| settings | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| slug | No | |
| status | No | |
| refused | No | |
| edit_hint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish that this is a non-read-only, open-world, non-idempotent, non-destructive tool, but the description adds substantial context: public URL sharing, required defaults, visible_when ordering constraints, paid-plan settings, password behavior, and payment-link limitations. It also explains that formset does not learn whether payment occurred, which is useful behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, then provides a useful example and structured guidance. It is somewhat long and repeats the rating-optional rationale in two places, but the detail is mostly justified for a complex nested form-creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary, and the description covers the main creation path, field design, requiredness, conditional visibility, and key settings. It is not fully complete because some schema settings are left unexplained despite 0% schema description coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, and it does strongly for title, fields, key naming, field type inference, required defaults, visible_when, and three paid settings. However, it does not explain the top-level description parameter or several settings such as close_at, submit_label, max_responses, and one_response_per_person.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: creates a hosted form and returns a public URL. It also distinguishes itself from siblings by naming update_form for edits and list_forms for viewing existing forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use it: collecting answers from other people, such as signups, intake questionnaires, RSVPs, feedback surveys, and polls. It names alternatives and gives nuanced guidance on when to ask follow-up questions versus when to build immediately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a form and every response it has collected. This is not the same as closing a form — if someone wants to stop collecting answers but keep them, call set_form_status with "closed" instead.
Requires confirm: true. Do not pass it on a vague instruction; ask the person to confirm they want the responses destroyed, and say how many there are.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true, and only after the person has confirmed. | |
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| deleted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description goes well beyond that by naming exactly what is destroyed (the form and all collected responses) and stating irrevocability via 'Permanently'. It also discloses the human-confirmation requirement and asks the agent to report response counts, which annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, front-loaded with the destructive consequence and the routing rule, followed by the operational constraint. No sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive two-parameter tool with an output schema present, the description covers consequence, alternative, and the confirm gate. Return values need not be explained because the output schema carries them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds real meaning beyond the schema by requiring confirm: true only after an explicit human confirmation and by prescribing how to obtain it, which is behavioral guidance the parameter's own description states only tersely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Permanently delete a form') plus the scope of destruction ('every response it has collected'). It explicitly distinguishes itself from the nearby sibling set_form_status, so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-not (stopping collection but keeping answers) and names the alternative tool, set_form_status with "closed". It also prescribes the confirmation protocol, including refusing to act on vague instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a download link for every response to a form, as a spreadsheet (CSV, which opens directly in Excel, Numbers and Google Sheets) or as JSON. Use this when someone wants the whole dataset in their own hands — "send me the responses", "export this", "can I get a spreadsheet".
Returns a link, not the data: a few thousand answers do not belong in a conversation. For questions you can answer here — counts, totals, which option is winning — use get_response_stats, and for reading particular answers use list_responses.
The link works for one hour and needs no login, so treat it as sensitive and give it only to the person who asked.
Example: { form_id: "…", format: "csv" }
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | csv (default) or json. | |
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). |
| Name | Required | Description |
|---|---|---|
| url | No | |
| format | No | |
| refused | No | |
| expires_at | No | |
| response_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive), and the description adds the traits that actually matter: it returns a link and not the data, the link expires in one hour, it needs no login, and it should be treated as sensitive and shared only with the requester.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what the tool returns, then usage triggers, then alternatives, then the expiry security note. Every sentence carries distinct information; none is padding or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no prose, and the description still clarifies the critical shape (a link, not the data) plus its lifetime. An agent has everything needed to call this correctly and to warn about link sensitivity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value beyond it by explaining what format means in practice (CSV opens directly in Excel, Numbers, Google Sheets) and by showing a concrete example call with form_id and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get a download link) and resource (every response to a form) plus the output formats (CSV or JSON). It explicitly distinguishes itself from get_response_stats and list_responses, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use triggers ("send me the responses", "export this", "can I get a spreadsheet") and names two alternatives with the conditions that select them: get_response_stats for counts/totals, list_responses for particular answers. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full detail of something search returned. Pass back the id exactly as search gave it — a form id resolves to the form, its questions and its results so far; a response id resolves to that one submission.
Returns readable prose rather than raw data, so it can be quoted directly.
Example: { id: "formset:form/0ff015a4-…" }
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An id returned by search. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them by disclosing the return format ('readable prose rather than raw data, so it can be quoted directly') and the expansion behavior of form ids (form, questions, results so far).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded verb+scope, followed by the id contract and return format, then a concrete example. Every sentence earns its place and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the prose note on output shape adds useful context. For a single-param read tool with full annotations, the description leaves no gap an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds genuine meaning: the id must be the exact token search returned, and its interpretation differs by prefix (form id vs response id). That is more than the schema's bare 'An id returned by search.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read the full detail of something search returned') and immediately scopes it to ids originating from search, which separates it from get_form/list_responses. The form-id vs response-id resolution sentence tells the agent exactly what object each id type yields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly establishes the usage context: this is the follow-up to search, and the id must be passed back verbatim. No alternatives (e.g. get_form, list_responses) are named, so there's no explicit when-not guidance, but the trigger condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a link the form owner opens in a browser to put a picture at the top of their form — a photo, a logo, a poster image — above the questions.
Call this when someone asks to add an image, a banner, a header or a logo to a form. You cannot send the picture yourself: it is on their device, so this returns a page they open and choose the file on. Hand them the link and say it works for an hour.
The same page replaces or removes a banner that is already there, so use it for those too. Colours are a different thing and are set with update_form settings.theme, which needs a paid plan; a banner does not.
Example: { form_id: "k3nq8vre2p" }
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). |
| Name | Required | Description |
|---|---|---|
| expires_at | Yes | |
| upload_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/destructiveHint already declaring the safety profile, the description adds real operational context: the link expires after an hour, the user must open it in a browser and pick the file, and the same page replaces or removes an existing banner. It does not restate the read-only nature, which is the right restraint, though it says nothing about whether repeated calls produce different links (relevant given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core outcome, then the when-to-use rule, then the constraint and the sibling caveat, closing with a concrete example. Every sentence carries information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is unnecessary. Given one required parameter and full annotation coverage, the description supplies everything an agent needs: what the link is for, who opens it, the expiry, and where the neighbouring capability lives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single form_id parameter is already fully documented in the schema, so the baseline is 3. The inline example format adds marginal concreteness but no semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource and the exact outcome: a link the form owner opens in a browser to place an image at the top of a form. It also names what it is NOT (you cannot send the picture yourself) and routes colours to a different tool, so it is distinguishable from siblings like update_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger (add/replace/remove an image, banner, header or logo), explicit alternative for a related need (colours → update_form settings.theme, which requires a paid plan, whereas a banner does not), and a clear constraint that the file lives on the user's device.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one form in full: every question with its type, options and validation, plus settings and the public URL. Call this before update_form so you edit against what the form actually contains rather than what you remember. For a list of forms call list_forms; this needs an id.
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| slug | Yes | |
| title | Yes | |
| fields | Yes | |
| status | Yes | |
| settings | Yes | |
| created_at | Yes | |
| updated_at | Yes | |
| description | Yes | |
| response_count | Yes | |
| current_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the payload scope (full question set, settings, public URL) and the read-before-write workflow, but says nothing about permissions, error behavior, or whether a missing id fails or returns empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what it returns, the workflow reason to call it, and the sibling alternative. The core purpose is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with full schema coverage, complete annotations, and an output schema, the description needn't explain return values, yet it still summarizes them. Nothing an agent needs 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single form_id parameter already documents both accepted origins (id from create_form/list_forms or slug from a share link). The description only repeats 'this needs an id', which adds nothing beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one form in full') and enumerates exactly what comes back: every question with type, options, validation, plus settings and public URL. It explicitly distinguishes itself from list_forms, so an agent can separate it from its closest sibling 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance ('Call this before update_form so you edit against what the form actually contains rather than what you remember') and names the alternative for listing ('For a list of forms call list_forms'). It also states the precondition that an id is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts, distributions and averages for every field on a form, computed in one call. This is the right tool for almost any question about results: "which option is winning", "what is the average rating", "how many people answered", "which question do people skip", "how many came in per day".
Select, boolean and rating fields come back with a distribution — each option and how many chose it. Number and rating fields also get min, max, sum, mean, median and standard deviation — the sum is what answers "how many kids are coming" or "how many seats do we need". Free-text fields return up to five short excerpts, not the whole corpus; call list_responses when the full text is what the person wants.
Example: { form_id: "…" } or, for a window, { form_id: "…", since: "2026-07-01T00:00:00Z" }
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ||
| until | No | ||
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). |
| Name | Required | Description |
|---|---|---|
| by_day | Yes | |
| last_at | Yes | |
| by_field | Yes | |
| first_at | Yes | |
| completion_rate | Yes | |
| total_responses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds substantial behaviour beyond that — per-field-type output shape (distributions for select/boolean/rating, min/max/sum/mean/median/stddev for number/rating) and the free-text truncation limit of five excerpts. These are exactly the traits an agent needs to set expectations about the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is longer than most definitions but front-loads the core claim and makes each sentence work: question examples, per-field-type behaviour, sibling routing, then an invocation example. Slight redundancy between the question list and the field-type explanation keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still characterises the aggregate fields and the truncation behaviour. Combined with the invocation example, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% — only form_id carries a schema description, while since/until are undocumented. The description partly compensates by showing an example call with a since window and by motivating time-boxed queries ('how many came in per day'), but it never explains until, whether bounds are inclusive, or timezone handling. Partial compensation warrants a 3 rather than a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Counts, distributions and averages for every field on a form, computed in one call') and immediately contrasts with the sibling that does something similar, list_responses. An agent can distinguish this summarisation tool from list_responses and export_responses without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the selection rule explicitly ('the right tool for almost any question about results') and enumerates concrete question shapes it answers, then names the exclusion condition: free-text fields return only excerpts, so 'call list_responses when the full text is what the person wants.' When-to-use and when-to-use-something-else are both present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the forms this person owns, newest first. Returns a compact summary — id, slug, title, status, response count and timestamps — not the questions. Call get_form when you need the questions themselves.
Call this to answer "what forms do I have?", to find a form's id before editing it, or when the person names a form you do not have an id for. At most 50 come back per call; if next_cursor is not null, pass it back as "cursor" for the following page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| forms | Yes | |
| next_cursor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds behavior beyond that: the returned field set, sort order (newest first), a page-size cap of 50, and the exact pagination protocol ('if next_cursor is not null, pass it back as cursor'). That is precisely the operational detail an agent needs and that annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs, front-loaded with what it lists and returns, followed by when to use it and the pagination mechanics. Every sentence carries information; no filler or restated title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description is not obliged to enumerate return values, yet it still summarizes them usefully. Combined with the usage guidance and pagination instructions, the only real gap is the unexplained status filter parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it compensates for only two of three parameters: cursor handling is spelled out and the 50-per-page cap implies limit behavior. The status enum (draft/open/closed) is never mentioned, leaving an undocumented filter the agent may need.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the forms this person owns'), adds scope ('newest first') and explicitly names what is NOT returned ('not the questions'), routing to the sibling get_form. An agent can distinguish this from get_form, search, and list_responses 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives three concrete triggers ('what forms do I have?', finding an id before editing, resolving a named form to an id) and names the alternative tool plus the condition that selects it ('Call get_form when you need the questions themselves'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the individual answers people submitted to a form. Use this when the question is about what someone actually wrote — quotes, open text, or the full row for a particular person. For counts, averages or "which option is winning", call get_response_stats instead: it answers in one call, where paging through answers takes many.
Ask for only the fields you need. Answers are the bulk of the payload.
Example — the email and rating of everyone who chose Tahoe, newest first: { form_id: "…", fields: ["email", "rating"], filter: { field: "location", op: "eq", value: "tahoe" }, limit: 20 }
Returns newest first. If next_cursor is not null, pass it back as "cursor" for the following page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Capped at 50. | |
| since | No | ||
| until | No | ||
| cursor | No | ||
| fields | No | Field keys to return. Omit for every answer on each response. | |
| filter | No | ||
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). |
| Name | Required | Description |
|---|---|---|
| hint | No | |
| total | Yes | |
| responses | Yes | |
| next_cursor | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: results come back newest first, answers dominate the payload, and next_cursor/cursor drives paging. It does not mention any rate limiting or permission requirements, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose then routing, followed by a compact payload warning, a single illustrative call and one pagination sentence. Every element earns its place; it is slightly longer than strictly necessary but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape needn't be described, and the description still covers ordering, pagination and payload bulk. The remaining hole is the since/until time-window parameters, which are neither in the schema text nor the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43%, and the description compensates partially with a worked example that clarifies filter/fields/limit syntax and the cursor round-trip. However, since/until and the max-limit cap are not explained in the description at all, leaving documented gaps that no structured field fills.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb+resource ('Read the individual answers people submitted to a form') and immediately distinguishes the scope from the aggregate sibling get_response_stats. An agent can tell what this returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use this for quotes/open text/full rows, use get_response_stats for counts, averages or 'which option is winning', with the reason (one call vs. many pages). That is a textbook when-to-use/when-not with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that formset is reachable and that you are signed in. Returns the signed-in user id and the server time. Call this when a connection or authorization problem is suspected; it reads nothing and changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still earns credit by disclosing the concrete return payload (signed-in user id and server time) and reinforcing that it 'reads nothing and changes nothing' — return information the agent cannot get from any output schema since none exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the first states the check and its output, the second states the trigger condition and side-effect profile. Front-loaded with the purpose and no redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic with no output schema, the description covers everything needed: what it verifies, what it returns, when to invoke it, and that it has no side effects. Nothing an agent needs in order to call or interpret it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the description carries no parameter burden and the baseline for a no-arg tool applies. The description correctly implies nothing is configurable, matching the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: verifies reachability of 'formset' and signed-in status, and names the return values (user id, server time). No sibling tool performs connectivity/auth checks, so it is trivially distinguishable from the create/get/list/delete form tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger — 'call this when a connection or authorization problem is suspected' — which is exactly the diagnostic scenario an agent would need. It lacks an explicit negative case (e.g., 'do not use to validate data or permissions beyond authentication'), but the sibling set offers no competing alternative to route to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search everything this person has in formset — form titles, descriptions, question labels, and the answers people have submitted. Use it to find something by name or by what it contains when you do not already have an id: "the trip poll", "whoever mentioned Tahoe", "the form asking about budgets".
Returns a list of matches, each with an id you can pass to fetch for the full detail. If you already have a form id, call get_form or get_response_stats directly instead — they are more precise.
Example: { query: "Tahoe" }
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free text. Matched case-insensitively. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description focuses on useful additions: the full breadth of what is indexed and that results carry ids usable with fetch. It stops short of disclosing ranking, result limits, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded statement of purpose, then the routing advice, then a compact example. The example queries are illustrative rather than filler and each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations carry the safety profile. The description still covers search scope, the id-to-fetch handoff, and the alternative tools, leaving no practical gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter, so the baseline is 3. The description adds real value beyond the schema by showing the query shape both as concrete example strings and as a literal example object {query: "Tahoe"}, clarifying that natural-language phrases are acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource plus the exact search domain: form titles, descriptions, question labels, and submitted answers. It is immediately distinguishable from siblings because it explicitly contrasts itself with get_form, get_response_stats, and fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition (finding something by name or content when you do not already have an id) and an explicit when-not with named alternatives (if you already have a form id, call get_form or get_response_stats). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open or close a form, or put it back into draft. Closing stops new responses and swaps the public page for a closed notice; nothing is deleted and it is reversible. Use this rather than delete_form when someone says a form is "done", "finished" or "no longer needed" — deleting destroys the answers.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=false and idempotentHint=true, but the description adds substantive side-effect detail the annotations cannot express: closing 'stops new responses and swaps the public page for a closed notice', nothing is deleted, and the change is reversible. It stops short of noting what existing responses do when reopened or any auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, each carrying distinct load: the core action, the behavioral consequence of closing, and the sibling-routing rule. No filler and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. Between the action semantics, the reversibility guarantee, and the explicit contrast with delete_form, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — form_id is documented there, but the status enum has no schema description. The description compensates by naming the three states in plain language ('open', 'close', 'back into draft'), which maps cleanly onto the draft/open/closed enum, though it does not spell out the literal enum tokens.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (set/open/close) on a specific resource (form) with all three target states enumerated ('open or close a form, or put it back into draft'). It also actively differentiates itself from the closest sibling, delete_form, so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative tool and the trigger condition: 'Use this rather than delete_form when someone says a form is "done", "finished" or "no longer needed"'. It even quotes the user vocabulary that should map to this tool, which is unusually actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a form's title, description, questions or settings. Call get_form first so you send the complete question list — "fields" replaces the whole array, it does not merge.
You may add questions, reorder them, and edit any label, help text, required flag, options or validation. Questions are required unless you set required to false — except a rating, which is optional unless you set it to true. "required": false — confirm with the person before making a question required that not everyone can answer. You may not make a question's "key" disappear: keys are how answers already collected are identified, so renaming one would silently change what past answers mean. To rename, add a new question and leave the old one. To genuinely delete a question, list its key in "remove_fields" so the deletion is deliberate.
Changing the questions creates a new version; existing responses stay pinned to the version they were answered against. To open or close a form use set_form_status instead.
Settings merge, so send only the ones that change. To lock a form behind a password set "settings.password"; to add payment buttons to the thank-you page set "settings.payment_links". Send null and [] to remove them.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| fields | No | ||
| form_id | Yes | The form id from create_form or list_forms, or the slug from its share link (the part after /f/). | |
| settings | No | ||
| description | No | ||
| remove_fields | No |
| Name | Required | Description |
|---|---|---|
| id | No | |
| refused | No | |
| version | No | |
| version_created | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructive/openWorld annotations: 'fields' replaces the whole array rather than merging, settings do merge, removals must be deliberate via remove_fields, keys cannot be renamed because past answers are keyed on them, and editing questions creates a new version with existing responses pinned to the old one. These are exactly the mutation semantics an agent cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the critical non-merge warning, and every subsequent paragraph carries distinct operational information. It is dense and slightly run-on in places, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the annotations already flag the destructive/open-world nature; the description supplies the versioning, merge, and deletion semantics that a mutation tool of this complexity needs. Nothing required to call it correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must compensate and largely does: it defines the replace-vs-merge behaviour of fields and settings, the role of remove_fields, required-flag defaults (including the rating exception), and null/[] for clearing password and payment_links. It still leaves the inner field object (type enum, options, validation, visible_when) largely to the schema, so it is not fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Change) and resource (a form) plus the exact surfaces it touches: title, description, questions, settings. It also differentiates from siblings by naming get_form and set_form_status as the tools for reading and for open/close, so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call get_form first so you send the complete question list' and routes open/close to set_form_status. It also gives a when-not rule (do not make a question required without confirming) and prescribes the alternative workflows for renaming (add new + leave old) and deleting (list key in remove_fields).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_form2 fields changedOutput schema / properties / refusedAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "reason",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "id",
- "slug",
- "url",
- "status",
- "edit_hint"
-]export_responses2 fields changedOutput schema / properties / refusedAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "reason",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "url",
- "format",
- "expires_at",
- "response_count"
-]update_form2 fields changedOutput schema / properties / refusedAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "reason",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "id",
- "version",
- "version_created"
-]create_form4 fields changedOutput schema / additionalPropertiesAdded value: +falseOutput schema / anyOfRemoved value: -[
- {
- "additionalProperties": false,
- "properties": {
- "edit_hint": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "slug": {
- "type": "string"
- },
- "status": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "slug",
- "url",
- "status",
- "edit_hint"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "refused": {
- "additionalProperties": false,
- "properties": {
- "message": {
- "type": "string"
- },
- "reason": {
- "type": "string"
- }
- },
- "required": [
- "reason",
- "message"
- ],
- "type": "object"
- }
- },
- "required": [
- "refused"
- ],
- "type": "object"
- }
-]Output schema / propertiesAdded value: +{
+ "edit_hint": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "id",
+ "slug",
+ "url",
+ "status",
+ "edit_hint"
+]export_responses4 fields changedOutput schema / additionalPropertiesAdded value: +falseOutput schema / anyOfRemoved value: -[
- {
- "additionalProperties": false,
- "properties": {
- "expires_at": {
- "type": "string"
- },
- "format": {
- "type": "string"
- },
- "response_count": {
- "type": "number"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "url",
- "format",
- "expires_at",
- "response_count"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "refused": {
- "additionalProperties": false,
- "properties": {
- "message": {
- "type": "string"
- },
- "reason": {
- "type": "string"
- }
- },
- "required": [
- "reason",
- "message"
- ],
- "type": "object"
- }
- },
- "required": [
- "refused"
- ],
- "type": "object"
- }
-]Output schema / propertiesAdded value: +{
+ "expires_at": {
+ "type": "string"
+ },
+ "format": {
+ "type": "string"
+ },
+ "response_count": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+}Output schema / requiredAdded value: +[
+ "url",
+ "format",
+ "expires_at",
+ "response_count"
+]update_form4 fields changedOutput schema / additionalPropertiesAdded value: +falseOutput schema / anyOfRemoved value: -[
- {
- "additionalProperties": false,
- "properties": {
- "id": {
- "type": "string"
- },
- "version": {
- "type": "number"
- },
- "version_created": {
- "type": "boolean"
- }
- },
- "required": [
- "id",
- "version",
- "version_created"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "refused": {
- "additionalProperties": false,
- "properties": {
- "message": {
- "type": "string"
- },
- "reason": {
- "type": "string"
- }
- },
- "required": [
- "reason",
- "message"
- ],
- "type": "object"
- }
- },
- "required": [
- "refused"
- ],
- "type": "object"
- }
-]Output schema / propertiesAdded value: +{
+ "id": {
+ "type": "string"
+ },
+ "version": {
+ "type": "number"
+ },
+ "version_created": {
+ "type": "boolean"
+ }
+}Output schema / requiredAdded value: +[
+ "id",
+ "version",
+ "version_created"
+]create_form4 fields changedOutput schema / additionalPropertiesRemoved value: -falseOutput schema / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "edit_hint": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "slug",
+ "url",
+ "status",
+ "edit_hint"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "refused": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "reason",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "refused"
+ ],
+ "type": "object"
+ }
+]Output schema / propertiesRemoved value: -{
- "edit_hint": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "slug": {
- "type": "string"
- },
- "status": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "id",
- "slug",
- "url",
- "status",
- "edit_hint"
-]export_responses4 fields changedOutput schema / additionalPropertiesRemoved value: -falseOutput schema / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "expires_at": {
+ "type": "string"
+ },
+ "format": {
+ "type": "string"
+ },
+ "response_count": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "format",
+ "expires_at",
+ "response_count"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "refused": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "reason",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "refused"
+ ],
+ "type": "object"
+ }
+]Output schema / propertiesRemoved value: -{
- "expires_at": {
- "type": "string"
- },
- "format": {
- "type": "string"
- },
- "response_count": {
- "type": "number"
- },
- "url": {
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "url",
- "format",
- "expires_at",
- "response_count"
-]update_form4 fields changedOutput schema / additionalPropertiesRemoved value: -falseOutput schema / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "version": {
+ "type": "number"
+ },
+ "version_created": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "id",
+ "version",
+ "version_created"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "refused": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "reason",
+ "message"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "refused"
+ ],
+ "type": "object"
+ }
+]Output schema / propertiesRemoved value: -{
- "id": {
- "type": "string"
- },
- "version": {
- "type": "number"
- },
- "version_created": {
- "type": "boolean"
- }
-}Output schema / requiredRemoved value: -[
- "id",
- "version",
- "version_created"
-]create_formdelete_formexport_responsesfetchget_banner_upload_linkget_formget_response_statsget_share_linkslist_formslist_responsespingsearchset_form_statusupdate_formCreate forms, share the link and read responses as JSON or CSV from your AI agent.
AI-native form builder: create, publish & read responses from Claude, ChatGPT & MCP.
Create forms, read submissions, and build invitations from Claude, ChatGPT, or any MCP client.
Form backend for AI agents: create live form endpoints, configure them, read submissions.
Add one secure layer between your agents and this server.
