Formcarry

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

The description adds meaningful behavioral context beyond the annotations: duplicates change nothing, the free plan limits the list to one address, and the operation returns the whole list. These details are not present in the annotations and materially affect how an agent predicts the tool's effects.

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 concise and front-loaded: the core operation and its semantics appear first, followed by plan limits, return value, and an alternative. Every sentence earns its place without repetition or 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 simple two-parameter tool with no output schema, the description is complete. It specifies the action, the list semantics, the idempotent duplicate behavior, the free-plan constraint, the return value, and the alternative for replacement, leaving no critical gap for an agent deciding to call 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 coverage is 100%, so the input schema already documents both parameters well. The description does not add much parameter-specific meaning beyond the schema, matching the baseline expectation for high schema coverage.

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 states a specific verb and resource: 'Adds one address to the list that receives the email on every submission.' It also clarifies the additive behavior ('keeps the others') and the idempotent duplicate case, making the tool's purpose unmistakable and distinct from siblings like remove_recipient.

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 explicitly tells the agent when not to use this tool: 'To replace the list, pass self_email_notification.recipients to update_form.' It also conveys that the tool is for adding, not replacing, which is key guidance for choosing between add_recipient and update_form.

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 mark it readOnly/idempotent/non-destructive, and the description adds non-obvious behavior: group_by returns only the largest 20 groups with the rest under 'other', field:<name> exposes distinct values for pre-filtering, and timeouts return partial results flagged exact:false. No contradiction with 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?

Every sentence carries a distinct piece of guidance: purpose, when-to-call, filter compatibility, group_by modes, field exploration, and timeout handling. There is no filler and the critical timeout caveat is included.

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 10-param tool with no output schema, the description covers the count/group semantics, the partial-result caveat, and the relationship to list_submissions. It does not spell out the exact return type, but the behavioral details are sufficient for correct invocation.

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 70% so the baseline is 3, but the description adds real value for group_by by enumerating valid values and explaining the 'other' bucket and field:<name> behavior. It also points to list_submissions for shared filter semantics, though it leaves most individual parameters to 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?

The description opens with 'How many submissions match, instead of the submissions themselves,' a specific verb+resource statement that clearly differentiates it from list_submissions. The title and description are aligned on the count operation.

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 explicitly says when to call it: 'Call this before listing when you do not know how big an answer is, so you can narrow it rather than paging blindly.' It also identifies list_submissions as the filter-compatible sibling and the listing alternative, giving the agent a clear routing rule.

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?

The annotations carry only generic false hints, so the description carries the behavioral burden. It discloses non-obvious behavior: unspecified configuration gets defaults, plan rules apply, and a refused configuration 'creates nothing,' implying an atomic failure rather than a partial create.

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, with the purpose front-loaded in the first sentence and no filler. Each remaining sentence adds either default behavior, plan constraints, or a required-parameter condition.

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 10-parameter nested create with 90% schema coverage, the description supplies the missing high-level semantics: defaults, plan limits, atomic refusal, and the return value. It deliberately delegates configuration details to update_form rather than duplicating them, which is a reasonable trade-off. It could be slightly more explicit about the full response shape, but the endpoint URL statement covers the key return need.

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 high at 90%, so the baseline is 3, but the description adds a useful global rule: 'what you leave out gets the defaults,' which tells the agent which parameters can be safely omitted. It also re-emphasizes the contextual team_id requirement. It appropriately avoids repeating field-level details already present in 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 clear action and object: 'Creates a form.' It also names the key return artifact ('returns it with the endpoint URL to post submissions to'), and the create/update/get/list distinction is obvious from the verb and sibling 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?

Gives concrete call guidance: pass only name plus optional configuration, omitted fields inherit defaults, and team_id is required only in multi-team connections. Plan-level constraints also set expectations for when creation may be refused. It references update_form rather than explicitly contrasting the two, but the usage context is clear.

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?

The description goes beyond the annotations by disclosing that the signing secret is returned only once and should be stored, and it names specific error conditions (webhook_limit_reached, webhook_url_taken). This is meaningful behavioral context for a create operation, though it does not fully describe response shape or all side effects.

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 convey purpose, a security-critical warning, limits, error codes, and a prerequisite with no filler. The structure front-loads the main purpose and then covers constraints, making it efficient and easy to scan.

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 create operation with no output schema, the description covers the most important response aspect (one-time signing secret) and key constraints/errors. It does not describe the full returned webhook object, but the schema plus these details are sufficient for a competent agent 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 the schema already documents all parameters. The description adds context about the webhook's behavior and limits but does not explain individual parameters, which is acceptable given the schema's completeness.

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 clearly identifies the verb ('Adds') and resource ('a webhook'), and adds the behavioral detail that it receives every submission as a JSON POST. It does not explicitly differentiate from sibling update_webhook/delete_webhook, but the action is unambiguous enough to recognize.

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 useful context for when the tool can be used: a form supports up to 10 webhooks, one per URL, and the plan must include webhooks. It does not state when to prefer an alternative such as update_webhook, so exclusion guidance is missing.

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?

The description adds the permanence of the deletion and the detail that attachments remain in storage, which goes beyond the destructiveHint annotation. It clarifies the irreversible nature and a specific side effect, providing useful behavioral context that the annotation alone does not 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?

The description is a single sentence that front-loads the action and permanence, with no filler or redundant information. It is concise and to the point.

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 simple two-parameter delete operation with no output schema, the description covers the key behavioral aspects: permanence and attachment handling. The agent has enough information to invoke the tool correctly, and the idempotentHint annotation covers idempotency without needing description space.

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 schema provides complete descriptions for both parameters, including source hints and format details. The description does not add any parameter-specific meaning, so it remains at the baseline for high schema coverage. No extra value is contributed.

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 clearly states the verb 'deletes' and the resource 'submission', and adds the critical qualifier 'permanently' which distinguishes it from reversible operations like restore_submission. It is specific and unambiguous.

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 implies use when permanent deletion is intended and warns that it cannot be undone, but it does not explicitly mention alternatives like restore_submission or mark_submission_spam, nor does it state when not to use this tool. The guidance is implied rather than explicit.

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?

The annotations already flag the operation as destructive and idempotent, and the description adds genuinely non-obvious behavior: queued or retried deliveries may still complete, and recreating the webhook issues a new secret. This goes well beyond what the structured fields 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?

Three short sentences, with the core removal behavior first, followed by the queued-delivery exception and the re-creation secret side effect. Every sentence adds distinct information and none 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?

For a two-parameter, well-documented mutation with comprehensive annotations, the description covers the meaningful behavioral edge cases and side effects. No output schema exists, but nothing necessary for correct invocation 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 coverage is 100%, with form_id and webhook_id already described and sourced from list_forms/list_webhooks. The description adds no additional meaning to these parameters, so the baseline score of 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?

The description uses a specific verb ('Removes') and names the webhook resource, and it clarifies the operational consequence ('no later submission is delivered to it'). It is clear, but it does not explicitly contrast with sibling webhook tools such as update_webhook, so it stops one step short of full 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 wording implies the tool is for permanently stopping future deliveries to a webhook, so an agent can infer a reasonable use case. However, it does not state when to prefer this over update_webhook or any alternative, and it gives no prerequisites or 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by enumerating exactly what data is returned (storage, spam protection, notification email, auto response, post-submit view, validation rules, webhooks, endpoint URL, submission counts). This contextual richness exceeds what annotations convey without contradicting them. No behavioral surprises are left unaddressed.

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 a single, dense sentence that front-loads the primary purpose ('One form with its full configuration') and then efficiently enumerates the included components. There is no wasted phrasing or redundant information. Every clause adds informational value, and the pointer to list_webhooks is integrated smoothly.

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?

Given the tool's simplicity (one parameter, no output schema), the description adequately covers what the agent needs to know: what data is returned, that webhooks are read-only and belong to a separate tool, and that the response includes submission counts. The absence of an output schema is compensated by the explicit content list, making the tool's behavior predictable.

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 input schema provides 100% coverage for the single parameter form_id, including format and origin (from list_forms). The description does not add any additional semantic nuance beyond the schema; it merely implies the parameter is required via the operation. Per the rubric, with full schema coverage the baseline is 3, and no extra meaning is contributed.

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 states the specific verb 'get' and resource 'a form', and clearly defines the scope as 'full configuration' with an explicit list of components (storage, spam protection, notification email, etc.). It distinguishes itself from siblings like get_form_fields (fields only) and list_forms (list) by emphasizing completeness. The mention of webhooks being read-only and pointing to list_webhooks further differentiates it.

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 provides a clear usage context: it retrieves the full configuration of a single form. It explicitly notes that webhooks are read-only here and directs to list_webhooks, which is a concrete alternative for that sub-resource. However, it does not explicitly contrast with get_form_fields or state when not to use this tool, so it stops short of a full when/when-not specification.

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?

Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses non-obvious behavior: the 2,000-submission window, 200-name limit, ordering by frequency, last-seen dates, and the empty-page risk for renamed fields. This is exactly the kind of practical behavioral detail an agent needs.

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 the core behavior and then delivers dense, purposeful caveats. No sentence is wasted, and it avoids repeating the title or schema.

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 adequately explains what the agent will receive: field names, counts, last-seen dates, ordering, and limits. It could be slightly more explicit about the exact JSON structure, but the operational meaning is sufficiently clear.

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 sole parameter, form_id, is fully documented in the schema with format and provenance ('from list_forms'). The description adds no additional parameter-specific meaning, so the high schema-coverage 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 specifies a clear verb and resource: it lists field names from the newest 2,000 submissions, ordered by frequency, with counts and last-seen dates. This distinguishes it sharply from siblings like get_form or list_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?

The description gives concrete usage context: read counts before filtering, watch for stale or renamed fields, and use 'q' when a field may be hidden by the 200-name cap. It stops short of explicitly naming the alternative sibling tool, but the guidance is clear and actionable.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a bit of value by naming the return contents (fields, attachments, metadata) but does not describe not-found behavior, response structure, or other runtime traits.

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 sentence with no filler, front-loaded with the essential resource and scope. Every word 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 simple read operation with complete parameter schemas and safety annotations, the description is reasonably complete. It mentions what the returned submission includes, though it omits any mention of error behavior and does not route agents away from relevant siblings.

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 form_id and submission_id are fully documented in the schema. The description adds no extra meaning about parameters, but the schema carries the full burden, matching the baseline of 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?

The description states a clear verb and resource: retrieving one submission, and specifies what is included (fields, attachments, metadata). It does not explicitly name sibling tools to distinguish itself, though 'One submission' implies a single-item fetch versus a list.

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 is given on when to use this tool instead of alternatives like list_submissions, search_submissions, or get_submission_deliveries. The singular phrasing is the only hint, and no exclusions or conditions are 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds substantial behavioral detail: the 20-submission limit, handling of unknown ids, meaning of each status, the possibility that very recent submissions have no rows yet, and the 18-month retention period. This goes well 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?

The description is dense but front-loaded, opening with the core purpose and then adding status interpretations and edge cases. Every sentence contributes new, useful information—no fluff. The structure is logical and easy to parse.

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 burden of explaining return values and interpretation. It covers the statuses, what each means, and edge-case behavior like missing ids, recent submissions, and retention. This is complete enough for an agent to use the tool correctly without additional documentation.

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 the schema already documents form_id and submission_ids including maxItems. The description adds no new parameter-specific meaning—'up to 20' repeats the schema, and 'Ids the form does not have are left out' describes output behavior rather than parameter semantics. This is 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?

The description clearly states what the tool does: it reports the delivery history of up to 20 submissions, including every email, webhook, Zapier zap, and integration, plus a rolled-up status. It distinguishes itself from siblings like get_submission and list_webhook_deliveries by focusing on per-submission delivery outcomes rather than form data or a global delivery list.

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 clear context for when this tool is useful—when you need to know what happened to specific submissions, including delivery paths and statuses. It does not explicitly name alternatives or state when not to use it, but it implicitly frames the use case well enough that an agent can decide.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations by explaining what the returned entries represent (SMTP servers vs. verified sending domains) and how the output should be consumed. This enriches the agent's understanding of the result without contradicting the hints.

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 carry exactly the needed information: the scope, the semantic distinction between server types, and the actionable next step. It is front-loaded with the resource and purpose, with no filler or repetition.

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 parameterless, read-only, idempotent list tool, this description is complete. It explains what is listed, why it is relevant, and how to use a returned value. The absence of an output schema is mitigated by the explanation of server types and the guidance about `server_id`.

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 has zero parameters and the schema coverage is 100%, so the baseline of 4 applies. The description adds no parameter documentation because none is needed, but it does clarify the meaning of returned server types, which supports future parameter use via `server_id`.

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 clearly states the tool lists email servers configured by teams in the dashboard and explains the practical purpose: use one as a form's notification sender. It also distinguishes the two server variants (`email_server` as SMTP, `premium_server` as verified domain), going well beyond the title and making the resource unambiguous.

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 provides clear usage context: this tool is for obtaining email servers to use as form notification senders, and it explicitly instructs where the resulting id belongs (`self_email_notification.sender.server_id`). It doesn't name alternatives or exclusions, but there are no competing email-server-specific siblings, so the guidance is practically sufficient.

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 read-only, idempotent, non-destructive behavior. The description adds useful context beyond annotations: newest-first ordering, next_cursor pagination, and connection-scoped visibility. These are behavioral traits an agent needs to correctly interpret results.

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 concise sentences with zero filler. The first packs resource, scope, ordering, and pagination; the second covers the optional filter. Every phrase contributes 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 simple paginated list endpoint with three optional parameters, the description covers scope, ordering, pagination, and filtering. The input schema handles parameter mechanics. No output schema exists, but the mention of next_cursor adequately signals the pagination 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?

Input schema has 100% parameter description coverage, so the description does not need to repeat limit or cursor details. It adds slight value for team_id by saying 'list one team only,' which reinforces the schema's conditional requirement, but this is marginal.

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?

Description clearly states the resource ('Forms'), the scope ('the connection can see'), and the ordering ('newest first'). This distinguishes it from sibling tools like get_form and list_submissions even without naming them.

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 instruction 'Pass team_id to list one team only' gives concrete conditional guidance for narrowing results. It does not explicitly name alternatives or say when not to use the tool, but the scope and filter condition are clear enough for an agent to select it appropriately.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses pagination via next_cursor, the AND-combination of filters, the absence of totals, and unsupported operations like 'not equal'. This gives the agent a full picture of the tool's 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?

The description is long but information-dense; every sentence adds operational guidance. It is front-loaded with the core purpose and then proceeds logically through workflow, filters, and limitations. While not terse, the length is justified by the tool's complexity.

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?

Given 13 parameters, nested filter objects, and no output schema, the description covers pagination, filter composition, limitations, and fallback strategies. It also instructs the agent to state when a requested operation is not possible. Nothing critical 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 coverage is high (77%), so the description need not re-explain each parameter. However, it adds crucial cross-parameter semantics: how filters combine with AND, the recommended search order, and the use of 'fields' to limit payload. This exceeds the baseline for high schema coverage.

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 states clearly that this lists submissions for one form, newest first, and distinguishes itself from other search tools by providing a specific search order. It also explicitly lists what this tool cannot do, preventing misuse.

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 provides a concrete workflow: start with a page of recent submissions, widen with get_form_fields, use q for unknown fields, then narrow with field filters. It also references count_submissions and get_form_fields for specific scenarios and tells the agent when to say something is not possible rather than approximating.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context that the output includes permissions granted for each team, which goes beyond the annotations. However, it doesn't describe return format, pagination, or any special behavior. Given the annotations handle the core safety aspects, this is a 3 – it adds some value but not extensive behavioral detail.

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 a single, front-loaded sentence that states the primary function first, then adds a usage tip. Every word earns its place; there is no redundancy or filler. The structure is ideal for an agent scanning descriptions quickly.

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-only list tool with annotations covering safety, the description is sufficiently complete. It tells the agent what the tool returns (teams and permissions) and when to use it. There is no output schema, but the description's mention of permissions gives enough context. Minor gaps include lack of explicit mention of ordering or error behavior, but these are not critical for a simple list 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?

The tool has zero parameters, and the schema coverage is 100% (vacuously). Per the rubric, with no parameters, the baseline is 4. The description doesn't need to explain parameters, and it doesn't. It correctly focuses on what the tool returns rather than inputs, which 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?

The description clearly states the tool lists formcarry teams accessible to this connection and includes permissions. It specifies the resource (teams) and the action (list), and it distinguishes itself from sibling list tools (like list_forms) by focusing on teams. The additional note about calling it first when unsure which team a form belongs to reinforces its specific purpose.

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 provides an explicit usage scenario: 'Call first when you are not sure which team a form belongs to.' This gives clear guidance on when to use it. It does not explicitly mention when not to use it or alternatives, but the tool is unique among siblings and the context is sufficient for an agent to decide. A minor gap is the lack of a when-not clause.

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?

The annotations already mark this as read-only, idempotent, and non-destructive, so the safety burden is covered. The description adds useful behavioral context beyond the annotations: newest-first ordering, one entry per submission showing the latest outcome, HTTP status, error text, and pagination semantics.

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 dense sentences carry all essential information with no filler. The primary output semantics are front-loaded, and the filtering/pagination details are compactly appended.

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 adequately explains the return content: one entry per submission, latest outcome, HTTP status, and error text. Given the annotations cover safety and the schema covers required IDs, nothing essential is missing for an agent to call this tool 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 only 60%, and the description compensates well for the undocumented parameters: it explains the default and range of limit, defines before as the previous page's last occurred_at, and enumerates the status filter values. Form and webhook IDs are already documented in 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?

The description states a specific verb and resource: it lists the delivery log of a single webhook, newest first. It clearly distinguishes this from sibling tools like get_submission_deliveries or list_webhooks by scoping to 'one webhook' and describing the entry-level content.

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 usage context is implied: use this when you need a webhook's delivery log, filterable by status, with pagination. However, the description never explicitly contrasts it with alternatives such as get_submission_deliveries or list_submissions, so the when-not-to-use guidance is missing.

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 and idempotentHint, so the description adds value by disclosing the limit 'Up to 10 per form' and the exact fields returned. This gives the agent expectations beyond the safety profile, though it doesn't specify error behavior for invalid form IDs.

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: the first states the returned content, the second states the limit. No filler words, and the core 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?

For a one-parameter read-only tool with no output schema, the description conveys the returned fields and the 10-item cap. It could mention it returns a list, but that is strongly implied by the tool name and 'The form's webhooks' phrasing.

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 form_id parameter already has a helpful description with an example and source (from list_forms). The description adds no parameter-specific guidance, 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 clearly states the resource (the form's webhooks) and enumerates the returned fields (url, enabled, description, events, signing method). It distinguishes this listing tool from sibling webhook create/update/delete tools by focusing on reading existing webhooks.

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 phrase 'The form's webhooks' gives clear context: use this when you need to inspect webhooks configured on a specific form. It does not explicitly name alternatives but the distinction from create/update/delete webhook tools is self-evident, meeting the 'clear context, no exclusions' level.

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?

Beyond the annotations (readOnly=false, destructive=false, idempotent=true), the description discloses the concrete effects: moving to the spam folder and returning the id plus new spam flag. It also states reversibility, adding behavioral context that annotations alone do not provide. No contradiction with 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 concise sentences: the first states the action and return value, the second adds reversibility. Every clause earns its place, with no redundancy or 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 simple two-parameter mutation with 100% schema coverage, a well-defined return value, and annotations covering idempotency and safety, the description provides all essential information. No output schema exists, but the description explicitly mentions the response contents, so the agent can anticipate the outcome.

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 both form_id and submission_id are already well documented with examples and origins ('from list_forms', 'from list_submissions'). The description adds no parameter-level detail, so the baseline score of 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?

The description uses a specific verb ('Moves') and a clear resource ('a submission to the spam folder'). It also distinguishes itself from the sibling restore_submission by naming it as the reversal counterpart, making the tool's role unambiguous.

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 provides clear context: this tool is for moving submissions into the spam folder, and it explicitly names restore_submission as the way to reverse the action. It does not explicitly contrast with delete_submission or state when spam is preferred over deletion, but the reversal note gives practical usage guidance.

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?

Goes well beyond the annotations by disclosing that the action is asynchronous, that the webhook is signed afresh, that paused webhooks still process it, and that redelivery repeats the endpoint's behavior. It also names a specific error condition (submission_not_stored), making the tool's behavior highly predictable.

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?

Every sentence carries essential information: the queueing behavior, the async response, the paused-webhook exception, the side-effect warning, and the refusal condition. It is dense but efficient and front-loads the core purpose.

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?

The description covers the key behavioral context needed to call the tool correctly: async semantics, where to observe the outcome, handling of paused webhooks, and the main error condition. A small gap is that it does not describe the success response format, but 'answers when it is queued' provides enough orientation.

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?

All three parameters are fully described in the schema with source guidance such as 'from list_forms' and 'from list_submissions or the delivery log.' The description adds little parameter-specific meaning, so the schema carries this dimension.

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 action (queues one submission for redelivery), the target resource (this webhook only), and the key distinguishing detail that it signs the payload afresh. The scope is unambiguous and clearly differentiates it from related webhook and submission 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?

Explains the async behavior ('answers when it is queued, not when it is delivered') and directs the agent to the delivery log for the outcome. It also notes that paused webhooks still receive the redelivery and that the tool is refused when submissions are not stored, giving practical context for when it applies.

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 idempotentHint=true, so the agent knows this is a destructive but idempotent operation. The description adds valuable behavioral context: it returns the whole list after removal, and it returns a specific error 'recipient_not_found' when the address is not present. This goes beyond the annotations and helps the agent anticipate the outcome. It doesn't mention permissions or irreversibility, but the annotations cover the destructive nature.

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 zero waste. The first sentence states the action and scope, the second states the return value and error condition. Every word earns its place. The description is front-loaded with the core behavior.

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 simple 2-parameter tool with full schema coverage and annotations covering destructive/idempotent hints, the description is nearly complete. It explains the return value (whole list) and the error case (recipient_not_found). The only minor gap is that it doesn't explicitly state that the operation is irreversible or that the recipient list is per-form, but the schema's form_id description and the annotations cover the essential context. An agent can call this tool correctly with the given information.

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 the schema already documents both parameters (email and form_id) with descriptions. The description adds the semantic context that 'email' is the address to remove from the recipient list, and 'form_id' is the form whose recipient list is being modified. This is consistent with the schema but doesn't add much beyond it. Baseline 3 is appropriate since 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?

The description states a specific verb ('removes'), a specific resource ('one address from the list that receives the email on every submission'), and the scope ('keeps the others'). It clearly distinguishes this from add_recipient and other form-related tools. The title 'Remove a recipient' is also clear, and the description adds the crucial context that it's about the email notification recipient list.

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 implies when to use this tool: when you need to remove a single address from the email recipient list while preserving the rest. It doesn't explicitly name alternatives like add_recipient or say 'use add_recipient to add', but the sibling context and the phrase 'keeps the others' make the usage context clear. It doesn't explicitly state when not to use it, but the behavior is specific enough that an agent can infer the right scenario.

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 the tool non-readonly, idempotent, and non-destructive. The description adds useful behavioral detail: it answers with the submission id and new spam flag, and it explicitly warns that this only clears the spam flag, not deletion. No contradiction with 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 with no filler. The core action and response are front-loaded, and the caveat about deletions is separate and concise. Every sentence 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 simple two-parameter mutation, the description covers the action, scope, response content, and an important boundary (no deletion undo). The annotations handle idempotency and destructive risk, and the schema covers parameter formats. A small gap is the lack of explicit error or permission context, but this is not essential for calling the 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 description coverage is 100%, so both form_id and submission_id are already well documented in the schema. The description adds no parameter-specific semantics, which is acceptable because the schema carries the full burden.

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 uses a specific verb and resource: 'Moves a submission back to the inbox' and 'clears the spam flag.' This clearly distinguishes it from the sibling mark_submission_spam and makes the reverse action obvious. The response behavior is also stated up front.

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 clear context: use this when a submission should be restored from spam, not when dealing with deletion ('There is no undo for deletions; this only clears the spam flag'). It does not explicitly name an alternative sibling like mark_submission_spam, but the guidance is strong enough to prevent confusion.

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?

Beyond the readOnly/idempotent hints, the description discloses the 25-form scope, that results include the originating form, and that an incomplete result is signaled by complete false. This materially explains behavior an agent otherwise could not infer from annotations or schema.

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 dense sentences front-load purpose, then provide selection guidance, then cover partial-result behavior. No filler or redundant restatement of the schema.

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 complex 12-parameter search tool with no output schema, the description still conveys scope, return association, cross-tool filter equivalence, and post-processing instructions for partial results. Combined with a richly described schema, this is sufficient for correct invocation.

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?

With 75% schema coverage, the schema already documents most parameters. The description adds useful cross-tool guidance with 'Takes the same filters' and ties form_ids, team_id, and date-range parameters to narrowing partial results, though a few booleans (read, has_attachments) still rely on inherited filter semantics.

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 begins with a precise verb and resource: 'Searches the 25 most recently active forms the connection can read and returns matches with the form each came from.' It clearly differentiates from list_submissions by stating when to use which tool.

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 explicitly says to use search_submissions when you do not know which form holds what you are looking for and list_submissions when you do, because that one pages through a single form completely. It also instructs what to do when the answer carries complete false: say partial and narrow with form_ids, team_id or a date range.

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 indicate destructive and idempotent behavior, and the description adds genuinely valuable behavioral detail on top: nested objects are merged, lists like recipients and rules are replaced wholesale, and plan-excluded features are refused with the dashboard's message. This goes well beyond what the annotations alone communicate, and there is no contradiction.

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?

Every sentence earns its place: core behavior, merge semantics, updatable blocks, sibling routing, and plan behavior. The most important constraint is front-loaded, and the description is appropriately sized for a complex update operation without padding or schema restatement.

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 complex nested update tool, the description plus rich annotations and schema cover what an agent needs to invoke it correctly. It explains update scope, destructive list replacement, and failure behavior for plan limits. It does not describe the response format, but since no output schema exists and the invocation behavior is well covered, this is a minor gap rather than a blocking one.

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 schema already documents each parameter in detail (roughly 90% coverage), so the description is not required to restate field meanings. It adds important cross-parameter semantics: partial updates merge nested objects but replace lists entirely, which materially affects how an agent should construct the payload.

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 states a precise action — updating a form with partial-change semantics ('Changes only what you pass') — and enumerates exactly which blocks and fields are updatable. It also distinguishes itself from sibling tools by noting that 'Webhooks have their own tools.' This makes it unambiguous versus update_webhook and create_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?

The description gives clear context for when to use the tool: modifying an existing form's settings, with nested objects merged and lists replaced. It explicitly routes webhook-related changes to separate tools, though it does not contrast with create_form or get_form, which is still fairly clear from the title and update semantics.

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 flag readOnly=false, destructive=true, and idempotent=true. The description adds valuable behavioral context beyond the annotations by defining partial-update semantics ('Changes only what you pass') and guaranteeing that the secret persists unchanged. This is consistent with the annotations and adds useful operational detail.

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 no wasted words. The core partial-update behavior and mutable fields are front-loaded, and the secret guarantee is stated in one concise clause.

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?

The schema already documents the required IDs and their sources, and the description clarifies the scope of mutation, so an agent can form a correct call. The only notable gap is the absence of any mention of the response format, but with no output schema and a simple update operation this is a minor omission.

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 33%, with form_id and webhook_id described in the schema but url, events, enabled, and description left to bare type declarations. The description names those four mutable fields but does not explain their accepted values or semantics, so it only partially compensates for the low schema coverage.

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 precise action ('Changes') on a singular existing webhook and enumerates the four mutable fields: url, enabled, description, events. It also distinguishes itself from siblings by noting the secret does not change, making it easy to tell apart from create_webhook or redeliver_webhook.

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?

Implies usage as the tool for modifying fields on an already-created webhook, as opposed to creating or deleting one. However, it never names sibling alternatives or states when not to use it, so the boundary is inferred rather than explicit.

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