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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so safety is partly covered. The description adds genuinely useful side-effect context beyond that: API-created submissions do not trigger Fillout notifications, workflows, or integrations. It stops short of stating auth needs, error behavior, or whether partial failures are possible.

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, front-loaded with purpose, then prerequisite, then caveat. Nothing is redundant 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?

For a batch-mutation tool with no output schema, the description covers purpose, prerequisite, batch bounds, and the most important side effect. It leaves the return payload (e.g., created submission ids) and per-item failure semantics unaddressed, but the essential call-path information 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 description coverage is 50%; formId is documented in the schema and the description reinforces the question-id linkage by pointing to get_form. However, urlParameters and submissionTime are undocumented in both schema and description, and the accepted value types for questions[].value are left unexplained.

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 ('Create ... submissions for a form'), adds a concrete scope constraint (1-10) and a motivating use case (data import). It is clearly separable from siblings like create_webhook or delete_submission 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 prerequisite: 'Call get_form first to get question ids,' which routes the agent to the correct sibling before invoking. It offers a use case (import data) but does not state when not to use it or name alternative paths for bulk/large imports.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the agent knows this is a non-destructive write that reaches an external endpoint. The description adds the useful behavioral fact that the URL is invoked on every new submission and that the created webhook id is returned, but it says nothing about duplicate-URL handling, idempotency, or required permissions.

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, with the core action and its trigger front-loaded and the return value noted last. Every clause earns its place.

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 two-parameter, all-required tool with no output schema, the description covers the action, the trigger, and the return value ('the webhook id'), while annotations cover the safety profile. It is nearly complete, missing only edge-case behavior such as duplicate webhook registration or failure modes.

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 parameters (url, formId) are already fully documented with format and provenance hints. The description adds no syntax, format, or validation detail beyond what the schema provides, so the baseline of 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?

The description gives a specific verb (register), the resource (a URL/webhook), and the exact trigger semantics (called on every new submission to a form), which is enough to know precisely what the tool does. It does not explicitly contrast itself with the sibling delete_webhook or explain how webhooks relate to submission-listing tools, so it stops short of full sibling differentiation.

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?

The event-driven framing ('on every new submission') implies the use case for the tool, but there is no explicit statement of when to create a webhook versus polling submissions, no prerequisites (e.g., form must exist, endpoint must be HTTPS), and no mention of delete_webhook as the way to undo it. Usage is only implied.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds genuinely new context: the deletion is permanent, irreversible, and requires user confirmation before invocation — exactly the kind of operational caveat the 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 short sentences with zero filler; the destructive action is stated first and the confirmation requirement immediately follows. Nothing could be trimmed without losing meaning.

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 two-param destructive tool with full schema coverage and annotations carrying the safety flags, the description covers the essential caveat (irreversibility + confirm first). It omits secondary details such as cascade effects on related data or required permissions, which keeps it just short of complete.

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% with only two required params (formId, submissionId), both documented in the schema itself. The description adds no parameter-level detail, 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 ("Permanently delete a submission") that clearly distinguishes it from the list/get/create siblings on the same resource and from delete_webhook. It stops short of naming an alternative or scoping behavior, so it is clear but not fully differentiated.

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?

The description gives one procedural rule ("confirm with the user first") which is real guidance, but says nothing about when deletion is appropriate versus other tools, prerequisites, or whether any soft-delete/restore path exists.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not state that removal is permanent, what happens if the id is unknown, or whether the webhook stops firing immediately.

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?

One short sentence, front-loaded with the action and resource, with zero wasted words.

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 tool whose annotations carry the safety profile, the description plus schema is minimally sufficient. It omits irreversibility and error behavior, which would be worth stating for a delete operation.

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 parameter is documented as coming from create_webhook. Baseline 3 applies since the description adds no format or constraint 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 ('Remove') and resource ('webhook') with the key selector ('by its id'), which clearly separates it from create_webhook. It does not explicitly name the sibling it pairs with, so it falls just short of a 5.

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?

No guidance on when to use this versus alternatives, nor any prerequisites or warnings about removal. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. Because there is no output schema, the description's enumeration of what is returned (question ids, names, types, plus other field groups) adds real value beyond the 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?

Two sentences, no filler, with the core retrieve-and-what-you-get content front-loaded and the actionable follow-up ('use the question ids when creating submissions') placed last. Every clause earns its place.

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 carries the return-value burden and does describe the response contents adequately for a read-only fetch. Minor gaps remain: it does not say whether all field groups are always present or how missing formId errors are surfaced.

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?

There is a single parameter at 100% schema description coverage, and the schema already explains that formId is the public ID from list_forms or the form URL. The description adds no additional parameter meaning, so the schema baseline of 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?

The description gives a specific verb and resource ('Get a form's questions') and enumerates the returned content groups (calculations, URL parameters, scheduling, payment, quiz), which lets an agent see this is the single-form detail fetch. It never explicitly contrasts itself with list_forms, so differentiation is inferable rather than stated.

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 the question ids when creating submissions' hints at the downstream workflow and why an agent would call this tool, but it is guidance about the output, not about tool selection. There is no statement of when to prefer get_form over list_forms, no prerequisites, and no exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that - no note on what a submission record contains, whether missing IDs error, or how large the payload is. It restates the purpose rather than disclosing 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?

A single short sentence with the identifying action front-loaded and zero waste. It is efficient, though its brevity edges toward under-specification rather than deliberate economy.

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?

A 4-parameter retrieval tool with no output schema and two undocumented parameters needs the description to explain what is returned and what raw/includeEditLink control. None of that is present, leaving the agent without enough to call it confidently in non-trivial cases.

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 50%: formId and submissionId are documented in the schema, but raw and includeEditLink have no descriptions anywhere. The description does not compensate for those two undocumented parameters, adding no meaning 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 (Get) and resource (submission) with a scope of 'one ... by ID', which distinguishes it implicitly from the sibling list_submissions. It stops short of naming a sibling or the retrieval context, so it is clear but not fully differentiated.

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?

No when-to-use guidance, prerequisites, or alternatives are given. The agent is left to infer that this is the single-item counterpart to list_submissions purely from the word 'one'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network-access profile is covered. The description adds genuine value by naming the return fields, but says nothing about result limits or pagination, which matters for an open-world account-level listing.

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?

A single front-loaded sentence with no filler. Every clause (scope, return fields) is informative and it is appropriately sized for a trivial list operation.

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 read tool with annotations covering safety and no output schema, the description supplies the essential payload shape (name and formId). It is nearly complete, with only pagination/limit behavior left unaddressed.

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 zero parameters, so there is nothing to disambiguate; the schema accepts no input and the description correctly describes a no-argument call. Baseline of 4 applies for parameterless tools.

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 all Fillout forms') plus the scope ('in the account'), and adds the returned fields (name and formId). It does not explicitly distinguish itself from get_form, but the list-vs-fetch distinction is self-evident from the names.

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?

The description gives no explicit when-to-use guidance or named alternative, though 'List all' implies it is the enumeration entry point while get_form retrieves a single form. Usage is inferable rather than stated.

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

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

Read-only safety is already covered by readOnlyHint, but the description adds genuinely new behavioral context: the default compact shape with answers keyed by question name, and the opt-in raw=true variant. It omits pagination/limit behavior relative to offset and any rate-limit or auth notes.

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, no filler, with the filtering capability front-loaded and the non-obvious return-shape behavior immediately after. Every clause earns its place.

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 usefully characterizes the return shape (compact vs raw). It covers the main filter families well but is silent on a couple of schema parameters (includeEditLink, sort defaults) and on pagination semantics, leaving small gaps for a 10-parameter tool.

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 90%, so the schema already documents nearly every parameter with types, bounds, and enums. The description only loosely maps the filters (date range, status, text search, pagination) and adds no syntax or default detail beyond the schema, matching the baseline 3.

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?

Names a specific verb (Query) and resource (a form's submissions) and enumerates the supported filters, so the operation is unambiguous. It does not explicitly contrast itself with get_submission or the other submission siblings, so it stops short of a 5.

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 only implied through the filter list; there is no statement of when to reach for this versus get_submission (single record) or create_submissions. An agent can infer the bulk-list role from the name, but nothing is spelled out.

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