Read Fillout forms and submissions, export responses, and create submissions and webhooks.
Scored across 9 tools
Most tools have clearly distinct purposes, but the submissions trio (fillout_list_submissions, fillout_export_submissions, fillout_count_submissions) target the same resource with subtly different intent. Descriptions do a good job clarifying: list = one page, export = bulk pagination walk, count = total only. fillout_get_submission is clearly a single-by-id lookup, so boundaries remain workable.
Every tool follows the identical fillout_verb_noun pattern (fillout_list_forms, fillout_get_form, fillout_create_submissions, fillout_remove_webhook, etc.). Verbs are consistent (list/get/create/export/count/remove), so the naming is entirely predictable.
Nine tools is well-scoped for a form-submission API, and each one earns its place (form discovery, submission read variants, submission write, webhook lifecycle). No redundancy or filler.
Core workflows are covered: forms (list/get), submissions (list/get/export/count/create) and webhooks (create/remove). Minor gaps exist — no way to list existing webhooks (you must retain the id yourself), and no form create/update or submission delete — but the read-and-import domain is largely complete.
Count a form's submissions matching the same filters as fillout_list_submissions (date range, status, search) without pulling the answers — e.g. 'how many responses this week?' or 'how many partial submissions?'. Reads totalResponses from GET /forms/{formId}/submissions with limit=1.
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes | The form's public id (the formId from fillout_list_forms, also the id in the form's share URL). | |
| search | No | Only submissions containing this text. | |
| status | No | 'finished' (default) or 'in_progress' for unfinished / partial submissions. | |
| afterDate | No | Only submissions submitted after this ISO 8601 date-time, e.g. 2026-09-01T00:00:00Z. | |
| beforeDate | No | Only submissions submitted before this ISO 8601 date-time. | |
| includePreview | No | Also include preview (test) responses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, and the description adds real behavioral context beyond it: the count is derived from totalResponses via GET /forms/{formId}/submissions with limit=1, which tells the agent this is a cheap, non-fetching operation. It doesn't discuss pagination or rate limits, but for a read-only count that is a minor gap.
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 sentences: the purpose and filter-parity claim lead, followed by use-case examples and one implementation detail. No sentence is redundant or 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?
With no output schema, the description compensates by naming the return value (totalResponses) and explaining how it is obtained, and it enumerates the filtering dimensions. It could still say what happens when zero submissions match, but an agent has enough 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 description coverage is 100%, so every parameter (formId, search, status, afterDate, beforeDate, includePreview) is already documented, and the description only summarizes the filter set at a high level. Per the baseline rule, 3 is correct when the schema does the heavy lifting.
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 (count) and resource (a form's submissions) and immediately distinguishes it from the sibling fillout_list_submissions by noting it does so 'without pulling the answers'. 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete invocation contexts ('how many responses this week?', 'how many partial submissions?') and frames the filter parity with fillout_list_submissions, which steers selection between the two. It does not explicitly state the inverse condition (use list when you need the actual answers), so it stops just short of a full when/when-not rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create up to 10 new submissions on a form, as if respondents had filled it in — e.g. to import responses collected elsewhere. Each submission needs its question answers (question ids from fillout_get_form); URL parameters, scheduling, payments, login email and timestamps are optional. Creates real records that trigger the form's integrations. Fillout: POST /forms/{formId}/submissions.
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes | The form's public id (the formId from fillout_list_forms, also the id in the form's share URL). | |
| submissions | Yes | 1-10 submissions to create. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply only destructiveHint=true. The description adds meaningful context beyond that: real records are created, the form's integrations are triggered as a side effect, submissions are capped at 10, and payments are recorded without charging anyone. This is more than the annotation conveys.
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 front-loaded sentences plus the underlying endpoint; the purpose, the import use case, required vs optional fields, and the side-effect warning each appear once with no 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?
For a write tool with no output schema, the description covers purpose, limits, required fields and side effects. It omits what the call returns (e.g. created submission ids) and any partial-failure behavior, which are the only notable gaps.
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: it separates the required question answers from the optional URL parameters, scheduling, payments, login email and timestamps, and ties question ids back to fillout_get_form. It doesn't explain answer value shaping beyond what the schema says.
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 ('Create up to 10 new submissions on a form') and scopes it precisely against siblings like fillout_list_submissions and fillout_get_submission. The 'as if respondents had filled it in' framing clarifies exactly what kind of record is produced.
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 a concrete use case ('import responses collected elsewhere') and a prerequisite that question ids come from fillout_get_form, plus the 10-item cap. It does not explicitly state when not to use this tool versus alternatives, but the context is clear enough to route an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe a URL to a form's new submissions: Fillout will POST each submission (same shape as a fillout_list_submissions entry) to it. Returns the webhook id — keep it, it is the only handle for removing the webhook later. Fillout: POST /webhook/create.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The HTTPS endpoint that should receive submissions. | |
| formId | Yes | The form's public id (the formId from fillout_list_forms, also the id in the form's share URL). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the destructiveHint annotation by describing the ongoing side effect (a POST per submission), the payload shape ('same shape as a fillout_list_submissions entry'), and the returned webhook id plus the obligation to keep it. It does not cover permissions, duplicate-subscription behavior, or delivery guarantees, so it is not 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?
Three tight clauses, front-loaded with the core action, then the payload shape, then the return-handle warning. The trailing 'Fillout: POST /webhook/create' is a small implementation breadcrumb but costs one line and aids debugging, so nothing meaningful is wasted.
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 no output schema, the description correctly carries the return value (the webhook id) and its persistence implications, and it explains the runtime side effect the agent is triggering. For a two-parameter, no-enum tool whose schema is fully documented, an agent has everything needed 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 description coverage is 100%, so both formId and url are already documented in the schema (public id from fillout_list_forms, HTTPS endpoint). The description adds no format, constraint, or validation detail beyond that, which is the expected baseline when the schema does the heavy lifting.
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 ('Subscribe a URL to a form's new submissions') and immediately clarifies the resulting behavior: Fillout POSTs each submission to that URL. It is clearly distinguishable from the sibling fillout_remove_webhook and from fillout_create_submissions, which handle different resources.
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?
Clear context for when this tool applies (you want an HTTP push of new submissions) and it implicitly points at the removal path by noting the id is 'the only handle for removing the webhook later.' It stops short of explicitly naming fillout_remove_webhook or stating when-not to use this versus another tool, so it is a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch many submissions in one call by walking the offset pagination (150 per page, paced under Fillout's 5 requests/second limit), up to max_submissions. Same filters as fillout_list_submissions. Use this for analysis across a whole response set; the result says whether it was truncated. Fillout: GET /forms/{formId}/submissions (repeated).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | 'asc' (default, oldest first) or 'desc'. | |
| formId | Yes | The form's public id (the formId from fillout_list_forms, also the id in the form's share URL). | |
| search | No | Only submissions containing this text. | |
| status | No | 'finished' (default) or 'in_progress' for unfinished / partial submissions. | |
| afterDate | No | Only submissions submitted after this ISO 8601 date-time, e.g. 2026-09-01T00:00:00Z. | |
| beforeDate | No | Only submissions submitted before this ISO 8601 date-time. | |
| includePreview | No | Also include preview (test) responses. | |
| max_submissions | No | Stop after this many submissions (default 500, max 3000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=true provided, the description carries real operational detail beyond the annotation: page size (150), rate pacing under the 5 req/s limit, the max_submissions cap, and the fact that the result reports truncation. It does not say what happens if pagination fails mid-walk or how partial results are handled, so it is strong but not exhaustive.
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 sentences, front-loaded with the pagination mechanism and the cap, followed by the use case. The trailing 'Fillout: GET /forms/{formId}/submissions (repeated)' is slightly redundant but cheap and maps the tool to the underlying API.
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 multi-page export with no output schema, the description discloses the pieces an agent needs: the cap, the pacing, and the truncation signal in the result. It could say more about the returned shape (e.g., a flat list of submission objects) but nothing essential for correct invocation 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%, so all eight parameters are already documented in the schema. The description only references max_submissions and alludes to the shared filter set; it adds no format or default detail beyond what the schema states, so the baseline 3 applies.
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 (fetch many submissions) and immediately distinguishes itself from the sibling by mechanism: multi-call offset pagination at 150/page, capped by max_submissions. An agent can tell it apart from fillout_list_submissions and fillout_get_submission without opening a 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?
'Use this for analysis across a whole response set' gives a clear selection context, and 'Same filters as fillout_list_submissions' implicitly routes the agent to that sibling for small scoped reads. It stops short of an explicit when-not rule (e.g., 'use list_submissions for a single page'), so it is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one form's metadata: every question (id, name, type), calculations, URL parameters, scheduling and payment fields, and quiz settings. Use the question ids to read answers or to create submissions. Fillout: GET /forms/{formId}.
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes | The form's public id (the formId from fillout_list_forms, also the id in the form's share URL). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a non-mutating read. The description adds value beyond that by disclosing the shape of the payload (questions, calculations, URL params, scheduling/payment/quiz settings), which matters since no output schema exists. It does not mention auth or rate limits, but the safety profile is already covered.
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 with the action and returned fields front-loaded, followed by the downstream usage hint and the API mapping. No filler, and nothing important is buried.
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 no output schema, the description compensates well by enumerating the returned metadata categories, and it links to how formId is obtained. Minor gaps remain on error/empty-form behavior, but the essential context for calling the tool is present.
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% and the single formId parameter is fully documented in the schema, including its origin (fillout_list_forms, share URL). The description adds no parameter detail beyond that, so the baseline 3 applies.
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 ('Fetch one form's metadata') and enumerates what is returned: questions with id/name/type, calculations, URL parameters, scheduling and payment fields, quiz settings. This clearly distinguishes it from fillout_get_submission and fillout_list_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?
It briefly points downstream ('Use the question ids to read answers or to create submissions'), which implies when this tool belongs in a workflow. However, it never names an alternative tool or states a when-not condition, so the routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single submission by id, with every answer. Fillout: GET /forms/{formId}/submissions/{submissionId}.
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes | The form's public id (the formId from fillout_list_forms, also the id in the form's share URL). | |
| submissionId | Yes | The submission's id (submissionId). | |
| includeEditLink | No | Include an editLink for the submission. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds useful scope detail ("with every answer," i.e. the full answer set is returned) and the underlying REST mapping, but says nothing about pagination, missing-id behavior, or whether edit links require extra handling beyond the includeEditLink flag.
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 sentences, front-loaded with the action and resource, with the endpoint mapping appended as a compact reference. Nothing is wasted or buried.
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 read-only single-record fetch with a fully described schema and no output schema, the description covers the essentials and notes that all answers come back. It is sufficient to call correctly, though a note on error/not-found behavior would round it out.
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 all three parameters are already documented, including formId's connection to fillout_list_forms and includeEditLink's effect. The description adds nothing beyond "by id," so the baseline 3 applies for a schema that does the heavy lifting.
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 ("Fetch a single submission by id") and signals scope with "single" and "with every answer," which distinguishes it from the sibling list/count/export tools without naming them. It is clear but stops short of explicitly contrasting with fillout_list_submissions or fillout_export_submissions.
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?
Usage is implied rather than stated: an agent can infer this is the tool to call when it already has a submissionId and wants that one record. There is no explicit when-not guidance or mention of the sibling alternatives (list, count, export) that an agent might otherwise consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every form in the Fillout account — each form's name and formId. Start here to find the formId the other tools need. Fillout: GET /forms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is covered; the description adds useful behavior by describing the returned identity fields (name, formId) in the absence of an output schema. It does not discuss volume or pagination behavior for large accounts.
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 sentences with the outcome and the routing hint front-loaded. The trailing 'Fillout: GET /forms' endpoint note is mild filler that does not help an agent select or call the 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?
For a no-parameter, read-only listing tool with no output schema, the description supplies the return shape and the reason to call it. Pagination or scale limits for accounts with many forms are the only unaddressed gap.
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?
The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter schema applies.
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 every form in the Fillout account') and clarifies the returned fields (name and formId), which cleanly separates it from the singular fillout_get_form sibling.
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?
'Start here to find the formId the other tools need' gives an explicit entry-point context and implied prerequisite for downstream tools. It stops short of naming specific alternatives or stating when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List one page of a form's submissions (answers to every question, calculations, URL parameters, scheduling, payments, quiz score, login email), filtered by date range, status or free-text search. Offset pagination: the response carries totalResponses and pageCount. Fillout: GET /forms/{formId}/submissions.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by submission time: 'asc' (default) or 'desc' for newest first. | |
| limit | No | Submissions per page, 1-150 (Fillout default 50). | |
| formId | Yes | The form's public id (the formId from fillout_list_forms, also the id in the form's share URL). | |
| offset | No | Starting position (0-based) for this page. | |
| search | No | Only submissions containing this text. | |
| status | No | 'finished' (default) or 'in_progress' for unfinished / partial submissions. | |
| afterDate | No | Only submissions submitted after this ISO 8601 date-time, e.g. 2026-09-01T00:00:00Z. | |
| beforeDate | No | Only submissions submitted before this ISO 8601 date-time. | |
| includePreview | No | Also include preview (test) responses. | |
| includeEditLink | No | Include an editLink for each submission. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already covers the safety profile, so the description's added value is pagination behavior: it discloses offset pagination and that the response carries totalResponses and pageCount. It also hints at defaults (status finished, sort asc) that are only implicit in the schema. It stops short of noting rate limits, max offset behavior, or error conditions.
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 plus an endpoint reference, front-loaded with the verb/resource and scope before the filter and pagination details. Every clause carries information an agent needs; nothing is 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?
With no output schema, the description does the work of sketching the returned payload (answers, calculations, URL parameters, scheduling, payments, quiz score, login email) and the pagination counters, which is more than most tools in this family. It is still silent on failure modes and how includeEditLink/includePreview alter the response shape.
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% and each of the 10 parameters is individually documented, so the baseline is 3. The description's mention of 'date range, status or free-text search' only restates three of those parameters and adds no syntax, format, or default detail beyond the 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 and resource ('List one page of a form's submissions') plus the payload scope (answers, calculations, payments, quiz score, etc.) and the underlying endpoint. The 'one page' framing distinguishes it from fillout_count_submissions, fillout_export_submissions, and fillout_get_submission without needing 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?
It lists the available filters (date range, status, free-text search) and explains offset pagination, which implies the listing use case, but it never says when to prefer this over fillout_export_submissions, fillout_count_submissions, or fillout_get_submission. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a webhook from receiving submissions. Recoverable: create it again with fillout_create_webhook (it gets a new id). Fillout: POST /webhook/delete.
| Name | Required | Description | Default |
|---|---|---|---|
| webhookId | Yes | The webhook id returned by fillout_create_webhook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint=true annotation already flags this as a destructive operation, but the description adds meaningful context beyond it: the removal is recoverable and re-creation yields a new id. It still omits any permission/auth requirements or effects on in-flight submissions.
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 terse sentences, front-loaded with the core action, then recovery information, then the underlying API endpoint. No filler and nothing buried.
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 single-parameter destructive operation with full schema coverage, complete annotations, and no output schema, the description supplies everything an agent needs: what it does, that it is reversible, and how to undo it.
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 schema already documents webhookId as the id returned by fillout_create_webhook. The description adds no additional syntax, format, or constraint detail beyond the schema, so baseline 3 applies.
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 ('Stop a webhook from receiving submissions') that is unambiguous and clearly distinct from sibling tools like fillout_create_webhook or fillout_list_submissions. An agent can identify the operation 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?
Explains the recovery path by naming the alternative sibling fillout_create_webhook and noting the id changes, which tells the agent what to do next. It does not state explicit exclusions or when-not-to-use conditions, so it falls short of full routing guidance.
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.
fillout_count_submissions1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_create_submissions1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_create_webhook1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_export_submissions1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_get_form1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_get_submission1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_list_forms1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_list_submissions1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_remove_webhook1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"fillout_count_submissionsfillout_create_submissionsfillout_create_webhookfillout_export_submissionsfillout_get_formfillout_get_submissionfillout_list_formsfillout_list_submissionsfillout_remove_webhookBuild, preview, edit, publish and analyze forms and surveys; read responses and manage webhooks.
Browse Formstack forms, submissions and webhooks, search responses, and create submissions.
Read Paperform forms, submissions, products and coupons, Papersign documents, and manage coupons.
AI-native survey & form builder. Manage surveys, responses, analytics, and webhooks.
Add one secure layer between your agents and this server.
