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

No annotations are provided, so the description carries the full burden. It states that a collector is created and gives payload constraints, but it does not disclose permissions, side effects, rate limits, or what the created collector contains or returns. This is a meaningful transparency gap for a write operation.

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 well-structured and front-loaded with the primary purpose, followed by a compact parameter breakdown. The JSON example is warranted and earns its place, though the 'optional' notation repeated per field adds slight redundancy.

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?

It adequately explains the request payload, and an output schema exists, so return-value documentation is not required. However, it lacks usage context and behavioral caveats for a creation endpoint with a nested payload, making it complete for parameter details but not for decision-making context.

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 has 0% description coverage, so the description must compensate. It documents survey_id and defines the payload object with a required type enum, optional fields, status values, ISO date format, and boolean field, which adds substantial meaning beyond the bare 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 'Creates a new collector for a survey,' giving a specific action and resource with its parent entity. This clearly distinguishes it from sibling tools like update_collector, delete_collector, and list_collectors.

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?

There is no explicit guidance about when to use this tool versus update_collector or delete_collector, and no conditions for choosing among collector types such as weblink, email, sms, or popup. The intended usage must be inferred from the name and the verb 'creates.'

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is 'creates' and notes that collector_id must be of type 'email', but it does not disclose side effects, whether the created message is a draft or is immediately sendable, authentication requirements, or failure behavior. This leaves important behavioral context unspecified.

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 compact and front-loaded: the purpose sentence comes first, followed by a structured Args block. Every line serves a purpose, either defining a constraint or documenting a payload field, with no filler or redundant wording.

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 tool with a nested payload and no schema-level descriptions, the definition is largely complete: it covers payload structure, required/optional fields, the type enum, and the collector prerequisite. An output schema exists, so return-value documentation is not required. It loses one point because it omits the relationship between creating and sending a message, which is relevant context for correct tool selection.

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 0%, but the description thoroughly documents both parameters. collector_id is explained with the email-type constraint, and payload is broken down field-by-field with required/optional markers, valid enum values, and example values. This fully compensates for the empty schema and gives an agent everything needed to construct a valid 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 opens with a specific verb and resource: 'Creates a new email message for a collector.' This clearly identifies the operation and distinguishes it from sibling tools like surveymonkey_send_collector_message, surveymonkey_list_collector_messages, and surveymonkey_create_collector, which act on different entities or actions.

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 no when-to-use guidance relative to alternatives. It does not state that creating a message is separate from sending it, nor does it mention when an agent should choose this tool over surveymonkey_send_collector_message or surveymonkey_list_collector_messages. The only weak guidance is the implied purpose from the name and opening sentence.

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?

With no annotations, the description carries the full behavioral disclosure burden, but it only says 'creates a new contact' and lists parameters. It does not mention side effects, whether duplicate emails are rejected, permission requirements, or how this relates to contact lists, so an agent cannot predict non-obvious 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 short, front-loaded with the core action, and uses a compact Args list. Every sentence serves a purpose and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter creation tool with an output schema, the basics are covered. However, it omits context about whether the contact is associated with a list and when to prefer this over sibling contact tools, so the agent has to infer important routing and side-effect details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description enumerates all three parameters and marks email as required while first/last are optional. This compensates for the lack of property descriptions, though it adds little beyond what the schema's required array and defaults already convey.

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 action and resource: 'Creates a new contact.' This distinguishes it from contact-list, survey, question, and other sibling operations. It does not explicitly compare itself to update_contact or create_contact_list, but the verb 'creates' plus 'contact' is 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?

No guidance is given for when to use this tool versus siblings such as create_contact_list, update_contact, or list_contacts. The description simply states what it does, leaving the agent to infer appropriate invocation context.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the mutation ('creates') and does not mention permissions, duplicate-name behavior, idempotency, or what happens after creation.

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 extremely concise and well-structured: a one-sentence action followed by an Args block. Every part is useful, and there is 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 one-parameter create operation, the description is minimally viable, especially since an output schema exists. However, the absence of annotations and lack of usage or behavioral caveats leave meaningful gaps for an AI agent evaluating whether and how to invoke this 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?

The Args block gives the single parameter a role, 'name for the new contact list,' which adds a small amount of meaning beyond the schema's bare title. However, with 0% schema description coverage, it lacks useful details such as format, length, uniqueness, or constraints.

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 action and resource: 'Creates a new contact list.' This is clear and distinguishes the tool from sibling create tools by object type, though it does not explicitly contrast it with any sibling.

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

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

There is no guidance on when to use this tool versus related contact or contact-list operations, nor any mention of prerequisites or exclusions. The only usage signal is implied by the verb 'creates,' which is insufficient among more than 40 sibling tools.

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?

There are no annotations, so the description carries the full behavioral burden. It only states that a page is created and documents payload fields; it does not disclose prerequisites, side effects, validation behavior, or 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?

The description is short, front-loaded with the core purpose, and uses a compact code block for the payload structure. Every sentence and line 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?

The output schema covers return values, so that omission is acceptable. However, the description lacks usage-vs-alternatives guidance and behavioral caveats, leaving some uncertainty for an agent deciding among page CRUD tools.

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 is nearly empty (0% description coverage), and the description compensates by clarifying survey_id and providing a structured payload example with optional fields. It does not fully specify types or constraints for each nested field, but is meaningfully helpful.

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 starts with a specific verb and resource: 'Creates a new page in a survey.' This clearly distinguishes it from page-update, page-delete, and page-list sibling tools without needing to inspect schemas.

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

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

The description states what the tool does but provides no guidance about when to use it versus alternatives, no prerequisites, and no exclusions. An agent must infer usage from the tool name and sibling list.

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?

There are no annotations, so the description carries the full burden. It discloses input structure and allowed family/subtype combinations, which is helpful, but it does not mention authorization needs, error behavior, or side effects such as question ordering or whether the question is appended. For a mutating operation, more behavioral context would be valuable.

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 well-organized: a one-line summary, a clear Args section, a structured payload example with inline annotations, and a compact list of common family/subtype values. Every section earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the nested payload and lack of schema descriptions, the definition is largely complete: it covers all required parameters, optional flags, answer structures, and valid family/subtype combinations. Minor gaps are the lack of explicit notes about page_id belonging to the survey_id and any permission prerequisites, but the provided context and sibling tools make the call executable without those details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates. It explains survey_id and page_id, and provides a detailed payload schema with required/optional fields, nested structure, examples, and a list of valid family/subtype pairings. This adds substantial meaning beyond the bare input 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 a specific verb and resource: 'Creates a new question on a survey page.' This clearly distinguishes the tool from the sibling get/update/delete question operations, and the summary line is unambiguous about what the tool does.

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 creation context is clear, and the payload documentation gives concrete guidance on how to use the tool correctly. It does not explicitly name alternatives or exclusions, but because this is the only create-question tool and the operation is stated directly, the usage context is effectively communicated.

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?

With no annotations, the description carries the burden of explaining the tool's side effects. It states that a new survey is created and notes that pages may be added at creation time, but it does not mention auth requirements, error behavior, or what happens after successful creation. This is adequate but not rich.

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 a one-sentence purpose, then a well-organized Args section. The JSON structure is detailed but every line is relevant to constructing a valid survey_definition; there is no filler or redundancy.

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 complex nested survey definition and sparse schema, the description provides enough structure to create a basic survey with pages and questions. It does not cover every possible SurveyMonkey field or validation constraint, but the output schema exists and the provided examples cover the common creation flow well.

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 is nearly empty (only 'survey_definition' as an object with additionalProperties: true), and schema description coverage is 0%. The description fully compensates by providing a detailed JSON structure with required fields, optional fields, and nested pages/questions, adding substantial 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?

The description opens with 'Creates a new SurveyMonkey survey,' which names a specific verb and resource. This clearly differentiates the tool from siblings like surveymonkey_update_survey, surveymonkey_patch_survey, and surveymonkey_delete_survey.

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 clearly frames the tool as a create operation, making it obvious it should be used for new surveys rather than updating or deleting existing ones. It does not explicitly name alternative tools, but the create-versus-update context is strong enough for an agent to route correctly.

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?

No annotations are provided, so the description carries the burden. It discloses that a webhook definition is created and that authorization is optional and sent in the callback header, which is useful behavioral info. However, it does not describe side effects such as whether the webhook is activated immediately, what the response contains, or any permission/rate-limit requirements. The 'Creates' verb and callback details give some transparency, but the lack of response/error context is a gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently organized with a clear payload structure and a compact list of supported event types. Every part earns its place; the only minor inefficiency is that the supported event_types list could arguably be shortened or linked, but it is directly useful for constructing valid webhooks because the schema has no enums.

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 is complete for constructing a call: all required payload fields, the object_type enum, object_ids semantics, and HTTPS subscription_url are specified. Since no output schema is present and annotations are absent, describing the response format would have been useful, but the description still provides enough to invoke the tool correctly. The supported event_types list also compensates for the missing enum definitions in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the payload schema is an open object with additionalProperties:true, so the description must fully compensate. It thoroughly documents the payload structure with each field, whether it is required, the enum for object_type, the object_ids list semantics, subscription_url HTTPS requirement, and the optional authorization header. This is exemplary compensation for a schema that otherwise provides no semantic information.

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: 'Creates a new webhook,' which clearly differentiates it from sibling tools like surveymonkey_get_webhook, update_webhook, delete_webhook, and list_webhooks. The payload structure and supported event_types further clarify the 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 implies when to use this tool: when creating a webhook, providing detailed payload requirements and supported event types. It does not explicitly state when not to use it or mention alternatives, but the clarity of the payload definition and event list gives strong contextual guidance. Since siblings are list/get/update/delete, no explicit exclusion is necessary.

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?

No annotations are provided, so the description carries the full behavioral burden. It explicitly warns 'irreversible operation' and states that responses are also deleted, which is essential risk information. It does not mention auth requirements or error behavior, but for a single-resource delete the destructive warning is the most important disclosure.

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 compact and front-loaded: the action comes first, followed by the irreversible warning and the parameter line. The Args section is slightly redundant with the schema, but it does not bloat the description.

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 simple one-parameter surface and presence of an output schema, the description covers the essential operational context: what is deleted, the destructive nature, and the required input. It does not specify behaviors like not-found handling, but that is not critical for an agent to invoke 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?

The description repeats 'collector_id: Collector ID,' which mostly mirrors the schema's own property title. However, because there is only one parameter and the schema has 0% description coverage, this short clarification still gives a minimal semantic anchor for the agent. It does not add much beyond the schema, but little is needed for such an obvious parameter.

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 action ('Deletes a collector') and adds the critical scope 'and all its responses,' which distinguishes it from sibling delete tools for questions, responses, webhooks, and contacts. The resource and effect are clear enough that an agent would not confuse it with update/get/list operations.

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 makes the usage context clear: use this when the collector and all its responses should be permanently removed. It does not explicitly name alternatives or conditions when not to use it, but the one-line action is unambiguous enough for a simple delete operation.

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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the action. It does not mention that deletion is irreversible, whether related data is affected, or what happens when the contact does not exist.

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 extremely concise with the core action front-loaded. Every line serves a purpose, and the Args line, while redundant with the schema, is short and does not add clutter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations and no usage guidance, the description is too thin. While the output schema may cover return values, the description lacks critical context about deletion permanence and any preconditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it merely repeats the schema title: 'contact_id: Contact ID.' It adds no details about where to find the ID, what format it should be, or how it relates to contacts in lists.

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: 'Deletes a contact.' This clearly distinguishes it from sibling delete tools such as delete_survey, delete_page, and delete_contact_list by naming the exact object being deleted.

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 offers no guidance on when to use this tool versus alternatives like delete_contact_list or delete_response. It does not mention prerequisites, side effects, or situations where this tool should or should not be used.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the operation deletes a contact list, without mentioning consequences such as whether contacts within the list are also removed, irreversibility, permissions, or other 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?

The description is very short, front-loads the action, and documents the only parameter. It is appropriately concise for a one-parameter tool, though it offers very little beyond the bare minimum.

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 tool is simple with one required parameter and an output schema is present, so return values are covered. However, as a destructive operation it omits side-effect and prerequisite context, making completeness only adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides 'list_id: Contact list ID.', which clarifies the parameter slightly beyond the schema's 'List Id', but for a single string ID this adds only minimal semantic value.

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 ('Deletes') and resource ('a contact list'), making it clear that this tool is for deleting contact lists. It does not explicitly contrast with sibling delete tools, but the resource is 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?

No guidance is provided on when to use this tool versus alternatives. Sibling tools include delete_contact, delete_survey, delete_collector, and delete_contact_list, but the description offers no selection cues 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?

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly warns that the operation is irreversible and discloses the cascade effect that all questions on the page are deleted. It does not mention permissions or failure modes, but the key destructive traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it states the action, the irreversible warning, and then lists the two arguments. Every sentence adds meaningful information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple destructive tool with two required parameters, the description covers the action, scope, and irreversibility, and an output schema exists so return values need not be described. It omits authentication or error details, but those are not essential for invoking 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 0%, so the description must compensate for missing parameter documentation. It merely restates the parameter names as 'Survey ID' and 'Page ID,' adding little beyond the schema property titles. It does not explain how to obtain these IDs or clarify any format expectations.

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 deletes a page and all its questions from a survey. This clearly distinguishes it from sibling tools like delete_survey, delete_question, get_page, or update_page.

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 makes the scope and effect explicit, so an agent can infer when to use this tool rather than deleting a question or updating a page. It does not explicitly name alternatives or exclusions, but the effect statement is clear enough for correct selection.

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?

With no annotations provided, the description carries the safety burden. The prominent 'WARNING: irreversible operation' explicitly flags that this is a destructive, permanent action. It does not mention permissions or effects on response data, but the key behavioral risk is disclosed.

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 compact and front-loaded: the action comes first, followed by the irreversible warning, then a minimal args list. Every line earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete operation with three required IDs, the definition provides the essential information: what is being deleted, where it lives, and required parameters. The only gaps are the lack of return-value details and explicit consequences beyond irreversibility, which are minor for this 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 Args block names all three parameters and labels them as Survey ID, Page ID, and Question ID. This slightly clarifies their roles, though it mostly restates the schema property titles and adds little detail about formats or how the IDs relate.

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 'Deletes a question from a survey page,' which clearly identifies the action, resource, and scope. This distinguishes it from sibling tools like delete_survey and delete_page without ambiguity.

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

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

Usage is implied by the verb and object: use this tool when removing a question from a survey page. However, the description does not explicitly say when to use it versus alternatives, nor does it provide any when-not-to-use 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?

With no annotations provided, the description carries the full burden of disclosure. It prominently warns that the operation is irreversible, which is the most critical behavioral trait for a delete operation. It does not detail permissions or cascading effects, but the irreversibility warning provides strong transparency.

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 short and front-loaded with the irreversible warning, which is appropriate for a destructive tool. The Args block is slightly redundant with the input schema, but it keeps the essential information immediately visible without unnecessary prose.

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 tool, the description covers the core action, the irreversibility, and the required identifiers. However, it lacks any usage context, alternative tool routing, or behavior on failure, and the output schema does not fully compensate for the missing operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the schema's lack of detail. However, the 'Args' section only restates the parameter names with trivial descriptions: 'Survey ID' and 'Response ID to delete.' It adds no meaningful information about formats, constraints, or usage beyond what the parameter titles already provide.

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 'Permanently deletes a specific response,' identifying the action, resource, and permanence. It distinguishes this tool from sibling tools like get_response or list_responses by making the destructive intent explicit.

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 does not explicitly say when to use this tool versus alternatives such as get_response or list_responses. The context of 'deletes' implies usage, but there is no guidance on conditions, 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?

No annotations are provided, so the description carries the full burden. It does well by disclosing that deletion is permanent, irreversible, and removes all responses as well as the survey itself. This covers the most important behavioral consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences plus one argument line. The irreversible warning is front-loaded, and there is no filler or repetition. 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 one-parameter destructive tool, the description covers the target, the cascade to responses, and irreversibility. The output schema exists, so return-value details need not be in the description. It lacks explicit usage/alternative guidance and permission prerequisites, but the essential context 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?

The schema has 0% description coverage and only a bare 'Survey Id' title. The description's 'Args: survey_id: ID of the survey to delete' adds the semantic role of the parameter and confirms it identifies the deletion target. Minimal but sufficient for a single obvious parameter.

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 deletes a survey and all its responses.' This clearly disambiguates from sibling tools like surveymonkey_delete_response and surveymonkey_delete_collector by naming the target resource and cascade scope.

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?

Provides no guidance on when to choose this tool over the many sibling delete tools, nor any mention of conditions or alternatives. Usage is only implied by the tool name and description, not explicitly 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the action is deletion, but does not mention that deletion is permanent, whether it has any side effects, or what permissions are required. For a destructive operation, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with the core action, and easy to scan. The Args section is simple and appropriately sized for a one-parameter tool. It loses one point because the parameter line is largely redundant with the schema title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter delete operation with an output schema, the minimum invocation information is present: the webhook_id. However, without annotations or guidance about preconditions, irreversibility, or error behavior, the definition is only minimally adequate. The output schema covers return values, so that absence is not penalized.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to add semantic meaning to the parameter. 'webhook_id: Webhook ID' merely repeats the schema property title, adding no information about format, source, or constraints. This provides minimal value beyond the structured 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 clear, specific action and resource: 'Deletes a webhook.' Among the sibling CRUD tools, it is unambiguous that this tool is for removing an existing webhook rather than creating, reading, or updating one. The Args line reinforces the target by webhook_id.

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 provided about when to choose this tool over alternatives such as update_webhook or get_webhook. The only usage signal is the verb 'Deletes,' which must be inferred rather than explicitly stated. There are no prerequisites, exclusions, or alternative routing details.

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?

With no annotations provided, the description carries the behavioral burden. It discloses meaningful behavior: automatic pagination, the 10,000-response cap, CSV output with headers, and optional date/status filters. This goes well beyond a bare mutation or read statement, though it could mention error behavior or what happens if more than 10,000 responses exist.

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 well-structured and front-loaded: main purpose first, then pagination behavior, then parameter documentation, then return format. Every line earns its place, and the Args/Returns format makes it easy for an agent to parse and apply.

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 parameter count, lack of annotations, and the presence of an output schema, the description is thorough enough. It documents all four parameters, explains the automatic pagination, sets the response limit expectation, and specifies the CSV return format with headers. An agent can select and invoke this tool correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter is explained with useful semantics: survey_id is the survey identifier, start/end dates are ISO 8601 filters, and status is a filter with examples such as 'completed' and 'partial'. This adds significant meaning beyond the schema's bare property titles.

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 specific verb and resource: 'Exports all responses for a survey as CSV.' It clearly states the output format and that all answers are included, distinguishing it from sibling tools like surveymonkey_list_responses or surveymonkey_get_response, which are focused on reading response data in a different 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 implies usage for CSV export of all survey responses and mentions automatic pagination, which helps an agent understand the tool's scope. However, it does not explicitly state when to prefer this tool over alternatives such as surveymonkey_list_responses_bulk or surveymonkey_get_response, nor does it mention exclusions or conditions.

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?

With no annotations, the description carries the disclosure burden and does state that the operation returns data, signaling a read-only behavior. It does not mention error handling, authentication, or that the collector must already exist, but for a simple getter this is acceptable.

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 compact and front-loaded with the main purpose, followed by a minimal args section. Every sentence earns its place; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter getter with an output schema, the core call information is present: what it does and which argument is required. It is slightly incomplete because it lacks usage guidance and any detail on where collector_id comes from, but it is adequate for a simple retrieval.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate, but 'collector_id: Collector ID' merely restates the parameter name and schema title. It adds no format, source, or lookup guidance.

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 clear verb-resource pair ('Returns the details of a specific collector') and the singular 'specific' distinguishes it from list_collectors. It does not explicitly name an alternative, and 'details' is broad, so it misses the top score.

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?

There is no explicit guidance on when to choose this tool over alternatives such as list_collectors or other get_* siblings. Usage is only weakly implied by the phrase 'specific collector'.

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?

With no annotations, the description carries the burden of behavioral disclosure. 'Returns' makes clear this is a read-only fetch and does not suggest side effects, but it does not disclose error behavior, authentication needs, or what happens when the contact_id does not exist.

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 short and front-loaded with the core purpose. The Args block is somewhat redundant with the schema, but the overall size is appropriate 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?

The output schema exists, so return values are already covered. Still, the description lacks usage guidance and behavioral detail about not-found cases, making it minimally complete for a one-parameter getter but not richly contextual.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. However, 'contact_id: Contact ID' merely restates the parameter name and title from the schema, adding no new meaning such as where the ID comes from or its expected format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Returns the details of a specific contact.' This distinguishes it from list-style tools like surveymonkey_list_contacts and from get_contact_list, though it does not explicitly name any sibling or scope limitation.

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 explicit guidance is given about when to use this tool versus alternatives. The phrase 'specific contact' weakly implies a single-contact lookup by ID, but there are no stated exclusions, prerequisites, or comparisons to sibling tools.

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?

With no annotations, the description carries the burden of explaining behavior. 'Returns the details' indicates a read-only retrieval and gives a basic sense of the outcome, but it does not disclose potential errors, required permissions, or whether any side effects could occur. This is adequate but thin for a tool with no annotation safety 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?

The description is extremely concise and front-loaded with the core purpose. The Args block adds necessary parameter clarification without any fluff, and 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 single-parameter retrieval tool, the description is nearly complete: it states what the tool returns and identifies the required input. The presence of an output schema means return-value details do not need to be in the description, though some usage guidance relative to sibling list tools would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the parameter documentation. It does provide a meaningful gloss for list_id ('Contact list ID'), which clarifies that the parameter refers to a contact list identifier rather than another entity type. For a single simple parameter, this is sufficient semantic support.

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 action ('Returns') and the resource ('a specific contact list'), making it easy to understand what the tool does. It does not explicitly differentiate itself from siblings like surveymonkey_list_contact_lists, but the phrase 'specific contact list' implies a singular retrieval as opposed to listing.

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 provided about when to use this tool versus alternatives such as surveymonkey_list_contact_lists or surveymonkey_get_contact. There are no exclusions, prerequisites, or context cues beyond the parameter requirement, so the agent must infer usage from the tool name and description.

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?

With no annotations provided, the description carries the full burden. The phrase 'Returns information' plus the specific purpose of token verification clearly indicates a read-only operation with no side effects. It could explicitly state 'no modification is made,' but for a zero-parameter identity endpoint this is sufficiently transparent.

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 no redundant wording. The core function is front-loaded in the first sentence, and the second sentence adds practical usage guidance. Every phrase 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 no-parameter tool with an output schema, the description covers all an agent needs: what the tool does, what key fields it returns, and when to use it. No missing information would prevent 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?

There are zero parameters and schema coverage is 100% (empty properties object), so no parameter documentation is needed. The description still adds value by specifying the returned fields (username and email), which is the relevant semantic content.

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: 'Returns information about the current SurveyMonkey user.' It clearly distinguishes this from all sibling tools, none of which target the current user/account, making the purpose 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 explicit use context: 'Useful to verify the token is working and to see the username and email.' While it doesn't name alternatives, no sibling tool offers the same functionality, so no exclusion is needed.

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?

There are no annotations, so the description carries the behavioral burden. It communicates a read-only behavior ('Returns') and names the scope (a specific survey page), but it does not disclose failure behavior, ownership constraints, or any API-specific traits. This is adequate for a simple read operation but not rich.

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 extremely concise and front-loaded with the core purpose, followed by a straightforward parameter list. There is no redundant prose, and the structure makes the required inputs immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values do not need to be described. The tool is simple and the two required parameters are named, but the description omits guidance on where the IDs come from and when to use this tool over list_pages. It is minimally viable but leaves some context to be inferred.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to compensate. It only repeats the parameter names as 'Survey ID' and 'Page ID', which adds little beyond the schema titles and the parameter names themselves. It does not explain how to obtain these IDs, their formats, or that page_id must belong to survey_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 uses a specific verb ('Returns') and resource ('details of a specific survey page'), clearly identifying it as the singleton getter for a page. The word 'specific' plus the required page_id distinguishes it from sibling tools like list_pages, create_page, update_page, and delete_page without ambiguity.

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: if you need the details of one survey page, this tool returns them. It does not explicitly say when not to use it or mention alternatives such as list_pages for enumerating pages or update_page for modifying a page.

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?

With no annotations, the description carries the full behavioral disclosure burden, but it only says 'Returns the full definition', which largely restates the tool's purpose. It does not mention lookup constraints, error conditions, ownership requirements, or side-effect guarantees beyond the read-only implication of 'get'.

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 short and front-loaded with the main behavior. The Args section is somewhat redundant with the parameter names, but it does not bloat the definition.

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 straightforward three-ID getter, the description plus output schema is minimally viable. However, it is incomplete in providing usage context, alternative tool routing, or parameter semantics, so an agent is left to infer when and how to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate. The Args section only says 'Survey ID', 'Page ID', and 'Question ID', which mostly restates the parameter names and does not explain relationships, formats, or how the IDs are nested or required.

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 ('Returns') and resource ('full definition of a question'), and notes that answer choices are included. This clearly differentiates it from sibling list/delete/update question tools and from get_page/get_survey.

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 call this tool versus list_questions, get_survey_details, or other siblings. The description provides no when-to-use or when-not-to-use context.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly sets the expectation that this tool returns metadata only and not answers, which is a meaningful non-obvious behavior. It does not discuss auth, rate limits, or errors, but for a simple read-style getter this is acceptable.

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 extremely concise and front-loaded. The first sentence states the core behavior, the second sentence covers the alternative, and the Args list is minimal and scannable. 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 fetch operation with an output schema present, the description covers the key decision point: metadata vs answers. It does not need to explain return values since an output schema exists, and the sibling distinction is fully handled. Slightly more detail on read-only behavior would be nice but is not critical.

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 Args section merely restates 'Survey ID' and 'Response ID', which adds no meaningful information beyond what the schema titles already provide. Since schema description coverage is 0%, the description should compensate with additional context, but it does not.

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 'Returns metadata for a specific response' and explicitly notes '(no answers)', which immediately distinguishes it from the sibling surveymonkey_get_response_details. The verb, resource, and scope are all specific.

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 directs users to use surveymonkey_get_response_details when answers are needed, providing a clear when-not/alternative condition. This leaves no ambiguity about which sibling to choose based on the need for answer data.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does state that the tool returns response answer data and that the simple parameter 'returns simplified answer format,' which discloses core behavior. However, it does not mention error behavior, rate limits, or any other operational traits, so it is adequate but not rich.

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 purpose sentence followed by a terse, readable Args block. Every line adds useful information, there is no filler, and the main 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?

Given an output schema exists, the description does not need to explain return values. It provides complete parameter semantics and basic behavior, so an agent has enough to invoke the tool correctly. The main contextual gap is the lack of guidance on how this tool relates to the similarly named surveymonkey_get_response sibling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates by explaining all five parameters: survey_id, response_id, page_ids, question_ids, and simple. It adds real meaning beyond the bare schema titles, including filter defaults and the effect of the simple flag.

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 a clear action and resource: 'Returns a specific response with all answer data.' This identifies what the tool does and the data scope. It does not explicitly differentiate itself from the similarly named sibling surveymonkey_get_response, 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?

There is no guidance on when to use this tool versus alternatives like surveymonkey_get_response, surveymonkey_list_responses_bulk, or surveymonkey_export_responses_csv. The description only states what the tool does and lists parameters, leaving the agent to infer selection criteria.

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?

No annotations are provided, so the description carries the full burden. It discloses the return behavior (metadata fields) and an exclusion (no questions), which is useful. It does not mention side effects or permissions, but for a simple get operation this is adequate. It adds value beyond the schema by clarifying scope.

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 two sentences plus an Args line, all front-loaded with the primary purpose and the key exclusion. There is zero waste and the structure makes it 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?

The tool is simple (one parameter, no nested objects) and has an output schema. The description covers what it returns, what it excludes, and how to get the excluded data. It doesn't mention prerequisites, but for a get-by-ID operation that is not critical. The description is complete for an 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 0%, so the description must compensate. The Args section merely repeats the schema's 'Survey ID' without adding format, source, or usage hints. For a single simple parameter this is minimal but not enriching; it adds no meaning beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Returns metadata for a specific survey' and enumerates the kind of data (title, response count, dates). It explicitly differentiates from the sibling surveymonkey_get_survey_details by saying it does NOT include questions, so an agent can tell them apart.

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 not to use this tool and names the alternative: 'Does NOT include questions — use surveymonkey_get_survey_details for that.' This gives clear routing guidance. The context of when to use (when metadata is needed) is implied but unambiguous.

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?

With no annotations, the description carries the burden of disclosing behavior. It states the main trait—returning the full definition with pages and questions—but it does not mention read-only status, authorization, payload size, error behavior, or any operational caveats.

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 main purpose sentence is front-loaded and concise. The Args section is short but redundant with the schema, which keeps it from being a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and an output schema exists, so the return behavior is partly covered. However, with no annotations and no usage guidance, the description leaves an agent to infer when to call it and whether the 'full survey definition' behaves differently from related list/get endpoints.

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 has 0% description coverage and the description only repeats 'survey_id: Survey ID,' which adds no meaning beyond the schema's existing property title. It does not explain where to find the ID, expected format, or how it is used.

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 ('Returns') and a specific resource ('the full survey definition'), and explicitly notes that the definition includes all pages and questions. This clearly distinguishes it from sibling page/question-level tools such as get_page and list_questions.

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?

There is no guidance about when to choose this tool over the many sibling survey/page/question/collector tools. The description implies its purpose but does not state alternatives 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?

With no annotations provided, the description carries the full burden. 'Returns the details' appropriately signals a read-only operation, but it does not disclose possible errors (e.g., 404 for invalid ID), authentication requirements, or any response behavior beyond the existence of an output 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?

The description is concise and front-loaded with the core purpose. The separate Args section is redundant with the input schema, costing a small penalty, but otherwise there is no wasted text.

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 single-resource getter, the description is minimally viable: it names the operation and the required parameter. The presence of an output schema relieves it from explaining return values, but it lacks usage context and any hint about where webhook_id comes from.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should add meaning beyond the schema. However, 'webhook_id: Webhook ID' merely restates the schema property title and adds no detail about format, origin, or how the value is used.

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 and resource: 'Returns the details of a specific webhook.' This distinguishes it from list/create/update/delete webhooks, though it does not explicitly name siblings or contrast with 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?

No guidance is given about when to use this tool vs. list_webhooks, how to obtain a webhook_id, or what prerequisites exist. The only implication is that the caller already has a specific webhook ID.

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?

There are no annotations, so the description carries the full behavioral burden. It only says 'Lists,' which implies a read operation, but it does not explicitly state that there are no side effects, discuss required permissions, error behavior for invalid/non-email collectors, or any other behavioral constraints. This is a significant gap for a tool with no annotation support.

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 compact and well-structured: a purpose line followed by a parameter list. It avoids fluff and front-loads the main action. The defaults are repeated from the schema, which is slightly redundant, but the arg explanations are necessary given the empty schema descriptions.

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?

This is a simple list operation with an output schema already defined, so return values are covered. The description includes the required parameter, the email-collector constraint, and pagination options. Missing are explicit usage alternatives and a clear read-only statement, but these are partially covered by the word 'Lists' and the overall simplicity of 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 0%, but the description compensates by explaining each parameter: collector_id is a Collector ID that must be of type email, and page/per_page are described with their defaults. This adds meaning beyond the raw schema, especially the critical email-type constraint.

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 'Lists email messages for a collector,' which names a specific verb, resource, and scope. It clearly differentiates itself from sibling tools like list_collectors and list_collector_recipients by specifying 'email messages' and the email-type collector constraint.

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 context—use this when you need email messages for a collector—and a precondition ('must be of type email'). However, it does not explicitly mention alternatives, when not to use it, or how it relates to sibling tools like list_collector_recipients or send_collector_message.

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?

With no annotations, the description carries the full burden for behavioral disclosure. It reveals only that this is a listing operation and exposes pagination parameters, but it does not explain pagination behavior, ordering, rate limits, or whether any recipient statuses or filters apply. The Args block mostly repeats schema titles and defaults rather than adding 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 front-loaded with a one-line purpose statement followed by a compact parameter list. No filler or redundant prose is present.

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 three-parameter list operation with an output schema, the description gives the minimum needed to make a call: purpose and parameters. It is not complete enough to support nuanced tool selection or behavior expectations because it omits usage guidance and behavioral detail, but it is not inadequate for a straightforward 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 description coverage is 0%, so the description needed to compensate, but the Args entries simply restate the property names and defaults already in the schema ('Page number (default 1)', 'Results per page (default 50)', 'Collector ID'). It adds no constraints, value formats, or provenance guidance for collector_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 opening line 'Lists email recipients for a collector' names a specific verb (lists), resource (email recipients), and scope (a collector). This clearly separates it from siblings like list_collectors and list_collector_messages, which operate on different resources.

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

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

The description provides no guidance on when to choose this tool over siblings, no mention of prerequisites such as obtaining a collector_id, and no exclusions or alternatives. It only states what the tool does, leaving the selection decision to the agent.

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?

No annotations are provided, so the description carries the behavioral burden. 'Lists all collectors' signals a read-only operation and scopes it to a survey, but it does not disclose pagination behavior, whether only one page is returned, or any rate-limit considerations. This is adequate but not rich.

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 short and the main point is front-loaded: 'Lists all collectors for a survey.' The Args block is compact and readable, though it partially duplicates the input schema, preventing a perfect score.

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 tool is a simple listing operation with only three parameters and an output schema available, so the essentials are present. However, there is no guidance about alternatives, no mention of pagination semantics, and no behavioral disclosure beyond the one-line summary, leaving some gaps for a full selection decision.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description's Args section mostly restates the parameter names and titles: 'Survey ID', 'Page number', 'Results per page'. It adds defaults, but those are already in the schema. It does not clarify limits, formats, or how paging interacts with the returned list.

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: 'Lists all collectors for a survey.' The word 'all' and the scope 'for a survey' clearly distinguish this from the sibling get_collector, which retrieves a single collector, and from create/update/delete collector 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?

The description provides clear context: use this tool when you need to list collectors belonging to a survey. It does not explicitly mention alternatives or exclusions, but the task-specific wording is enough for an agent to recognize when this tool 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the operation is a read-only listing, but does not mention response behavior, pagination semantics beyond parameter defaults, authentication needs, or any limitations. This is a minimal disclosure for a tool with zero annotation coverage.

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 compact and front-loaded with the core purpose in the first sentence, followed by a brief parameter list. Every line adds useful information without 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 list tool with an output schema and fully documented parameters, the description is mostly complete. It covers what the tool does and the meaning of each argument. It falls short only in lacking explicit usage guidance and behavioral caveats, but the tool is low-complexity and low-risk.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by defining all three parameters: list_id as the contact list ID, page as the page number, and per_page as results per page with defaults. This adds meaning beyond the bare schema types and titles.

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: 'Lists contacts that belong to a specific contact list.' This clearly distinguishes the tool from siblings like surveymonkey_list_contacts (all contacts) and surveymonkey_list_contact_lists (all lists), so an agent can tell it apart.

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 intended use is implied by the description: call this when you have a specific contact list ID and need its members. However, it does not explicitly compare against alternatives such as list_contacts or explain when not to use it, leaving some inference to the agent.

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?

With no annotations provided, the description must carry the behavioral disclosure burden. It communicates a read-only listing behavior and reveals pagination via page/per_page defaults, but it does not mention response structure, ordering, permissions, or any rate-limit implications. This is adequate for a simple list tool but not richly transparent.

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 two compact sentences, front-loading the core purpose first and then documenting the two parameters. Every sentence is informative and there is no filler or redundancy.

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 tool has only two optional parameters, no nested objects, and an output schema is present, so the description need not detail return values. The purpose and pagination behavior are covered, and sibling context is not needed for correct invocation. It is nearly complete, with only minor missing context around response shape or usage scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does explain both parameters: 'Page number' and 'Results per page', adding meaningful semantics beyond the bare schema titles and defaults. It does not specify constraints like minimum/maximum values, but the simple pagination parameters are well covered.

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 ('Lists') and a specific resource ('all contact lists in the account'), making the tool's purpose immediately clear. The phrase 'contact lists' distinguishes it from sibling tools like surveymonkey_list_contacts, which lists individual contacts.

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 clearly implies this is the go-to tool for enumerating all contact lists in the account, but it does not explicitly explain when to prefer it over alternatives such as surveymonkey_get_contact_list or surveymonkey_list_contacts. There are no explicit usage exclusions or alternative routing.

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?

With no annotations, the description carries the full burden. It discloses pagination, filtering, searching, and sorting behavior through the Args list, and 'Lists' implies a read-only operation. However, it does not mention authentication needs, rate limits, or whether search is partial or exact.

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 compact and well-structured: a one-sentence purpose followed by a clean Args list. Every line carries parameter semantics that the schema lacks, so nothing is redundant or wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list operation with an output schema present, the description covers all inputs and their constraints. The main gap is the lack of usage context or relationship to sibling contact tools, but invocation-level completeness is strong.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by explaining every parameter's meaning, allowed values, defaults, and role. This is essential value beyond the schema, which only provides bare titles and defaults.

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 states a clear verb and resource: 'Lists contacts in the account.' It is specific enough to distinguish from get_contact, create_contact, and list_contact_lists, though it does not explicitly name any siblings.

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?

There is no guidance about when to use this tool versus alternatives like list_contact_list_members or get_contact. The scope is implied by the name and one-line description, but no exclusions or routing cues are provided.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It uses a clearly read-only verb, 'Lists', and documents pagination parameters, which partially conveys behavior. However, it does not explicitly state that the operation is non-mutating, mention auth requirements, or describe error behavior, so behavioral transparency is adequate but minimal.

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: one clear purpose sentence followed by a compact Args block. Every phrase earns its place, with no filler or redundant elaboration.

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 operation, the description plus input schema and output schema provide enough information to invoke the tool correctly with survey_id and optional pagination. The main missing context is explicit guidance about choosing it over sibling page-related tools, but that is a moderate gap given the clear purpose statement.

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 has no descriptions, but the description compensates by explaining each parameter: survey_id is the survey identifier, page is the page number, and per_page is the results-per-page count. This adds meaning beyond the bare schema titles, especially for per_page.

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 'Lists the pages of a survey', which is a specific verb plus resource and clearly distinguishes this from singular get_page operations or question/response listers. The plural 'pages' and mention of 'survey' make the tool's scope immediately obvious.

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 no guidance on when to choose this tool over alternatives such as surveymonkey_get_page or surveymonkey_list_questions. It does not state exclusions, prerequisites, or a recommended path for single-page retrieval, leaving the agent to infer usage purely from the tool 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?

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only listing operation by using 'Lists', and it exposes pagination defaults. However, it does not disclose API limits, whether the response is paginated across questions or pages, or how the page_id relates to the pagination page parameter.

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, leading with the core purpose and then listing arguments without fluff. It uses a clear structured Args block, though the per-parameter descriptions could add more value without making the text significantly longer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value documentation is not required, but the description still leaves a key conceptual gap: how page_id is obtained, how pagination interacts with the survey page, and whether the call lists all questions on that page. The ambiguity between the two 'page' meanings is a real usability gap for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all parameter meaning. It gives one-line definitions for all four parameters, but they largely restate the parameter names. The distinction between 'Page ID' and 'Page number for pagination' is confusing, and the description does not clarify that page_id refers to a survey page while page refers to result pagination.

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 'Lists questions on a specific page of a survey' with a clear verb, resource, and scoping qualifier. It clearly differentiates from sibling tools like get_question (single question), create_question, and update_question by describing a list operation. The only minor ambiguity is between page_id and pagination page, but the core purpose is 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?

No guidance is given about when to use this tool versus alternatives such as list_pages, get_survey_details, or get_question. There are no exclusions or conditions to help an agent choose this over a sibling. The agent must infer usage purely from the name and one-line description.

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?

With no annotations, the description carries the disclosure burden and does disclose a core behavioral trait: returns metadata only and excludes answer content. It also documents filter, sort, and pagination behavior. It does not mention auth or error behavior, but for a read-only list operation this is acceptable.

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 prose is minimal and front-loaded with purpose and the alternative tool, followed by a compact structured argument list. No redundant sentences or restatements of schema titles.

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 nine-parameter tool with no schema-level descriptions and no annotations, the description covers the operation, the parameter semantics, and the main sibling distinction. An output schema exists, so return-value shape does not need to be restated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must document the parameters itself. It explains every argument, adds constraints not present in the schema (max 1000, ISO 8601, allowed status values, sort field/order), and clarifies defaults.

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 states the specific action (lists responses for a survey) and the key scope restriction (metadata only, no answers). It immediately distinguishes itself from the sibling surveymonkey_list_responses_bulk, so an agent can tell them apart.

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?

Provides an explicit routing rule: use this tool for metadata-only response lists, and use surveymonkey_list_responses_bulk when answer data is needed. This is clear context for choosing among siblings.

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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses useful behaviors such as pagination defaults, the max per_page of 1000, ISO 8601 date formats, the 'simple' format switch, and supported status filters. However, it does not mention authentication requirements, rate limits, or any caveats about large bulk responses.

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 a one-sentence purpose statement followed by a compact, scannable Args list. Every argument line earns its place by providing concrete semantics, defaults, or allowed values, 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?

Given the 10-parameter surface area and no annotations, the description covers the required invocation details well: required survey_id, filtering options, pagination, and date formats. The presence of an output schema means return values need not be described. It falls slightly short only in not explaining when to choose this over the closely related list_responses 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 0%, so the description is the only source of parameter meaning. It comprehensively documents all 10 parameters with types, defaults, allowed values, separator conventions, and date formats, adding substantial value beyond the bare schema titles.

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 a clear verb and resource: 'Lists responses for a survey including all answer data.' This conveys the core purpose and the emphasis on full answer data, though it does not explicitly distinguish itself from the sibling surveymonkey_list_responses or surveymonkey_export_responses_csv.

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 usage through the tool name 'bulk' and the phrase 'including all answer data,' but it never states when to prefer this tool over list_responses or when to use an export tool instead. There are no explicit exclusion conditions or alternative routing.

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?

There are no annotations, so the description carries the behavioral transparency burden. It discloses that this is a read-style listing operation, explains pagination behavior, sort defaults, and the per_page maximum of 1000. It does not mention authentication requirements, rate limits, or explicitly confirm the absence of side effects, leaving some behavioral context unstated.

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 a one-sentence purpose and followed by a compact Args block. Each parameter line is informative and scannable, with no filler, repetition of schema defaults, or unnecessary prose. 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?

Given an output schema is present and all 8 optional parameters are fully described, the description provides nearly complete invocation context. The remaining gaps are minor: no guidance on choosing sibling tools, no error/edge-case notes, and no authentication or rate-limit context. Still, an agent can call this tool correctly with confidence.

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 coverage is 0%, but the description fully compensates by documenting all 8 parameters. It adds semantic value beyond the schema: valid sort_by values, sort_order direction choices, title substring matching, ISO 8601 date formats, folder filtering, and default values. This is exactly the kind of parameter clarification an agent needs.

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 a specific verb and resource: 'Lists surveys in the account with pagination and optional filters.' This clearly states what the tool does and its scope, and it is easily distinguishable from sibling tools like surveymonkey_get_survey or surveymonkey_get_survey_details, which target a single survey.

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 makes the core use case obvious—listing surveys—and the parameter list shows how to filter, sort, and paginate. However, it does not explicitly compare with alternatives or say when to prefer this over a sibling such as get_survey, get_survey_details, or list_responses. Usage is implied rather than explicitly routed.

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?

With no annotations, the description carries the full behavioral burden. It communicates an account-level read-only listing operation, which is useful, but it does not clarify whether pagination means the result may not actually include all webhooks in one call, nor does it disclose permission requirements or rate-limit 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 compact and front-loaded: one clear purpose sentence followed by a minimal parameter list. Every sentence earns its place and there is no redundant or filler content.

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 list operation with an output schema present, the description adequately covers scope and pagination parameters. It is slightly incomplete only in that it does not explicitly note pagination behavior or route users to get_webhook for individual lookups.

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 has 0% description coverage, so the description's Args section provides necessary meaning: 'page' is the page number and 'per_page' is results per page, with defaults. This adds value beyond the schema, though it omits potential details like valid ranges or maximum allowed values.

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 action and resource: 'Lists all webhooks in the account.' This is a specific verb-plus-resource statement that naturally distinguishes it from sibling webhook tools such as get_webhook, create_webhook, update_webhook, and delete_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?

The phrase 'all webhooks in the account' implies this is the enumeration tool, but the description does not explicitly say when to prefer it over get_webhook or provide any exclusions, prerequisites, or alternative routing. Usage context is only implied 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?

With no annotations, the description carries the behavioral burden. It does disclose the PATCH semantics and that only provided fields are changed, which is helpful. However, it does not mention authorization requirements, error behavior, idempotency, or what happens with unsupported fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. The Args section and example are cleanly structured with no redundant sentences, making it easy for an agent to scan and apply.

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 and the presence of an output schema, the description covers the essential operational details: what the tool does, how to specify the patch, and common fields. It is missing explicit guidance on when to prefer the full-update sibling, but overall it is adequate 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?

The schema provides zero parameter descriptions, but the description fully compensates: it explains survey_id as the survey identifier and defines patch as an object containing only fields to change. It adds practical value by listing common fields and giving a concrete example.

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 a specific action and resource: 'Partially updates a survey (PATCH).' The word 'Partially' directly distinguishes this from the sibling update_survey tool, so an agent can tell them apart without inspecting schemas.

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

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

The description clearly establishes the usage context: partial, field-level updates via a patch object containing only the fields to change. It does not explicitly name alternatives or provide a 'when not to use' statement, but the partial-update framing makes the intended use obvious enough.

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?

With no annotations, the description carries the full burden. It usefully discloses that the send goes to all recipients and that an empty scheduled_date means immediate sending. However, it does not mention that sending is a side-effectful, likely irreversible action or that a message must already exist for the collector, and there are no annotations to fill that gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a one-sentence action followed by three tight parameter bullets. It is front-loaded and contains no filler, so every line 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 send operation, the description captures the core action and parameter semantics, and an output schema exists so return values need not be explained. However, it omits the workflow context that an agent needs: that a message should be created first, that the collector must have recipients, and that sending may have external consequences.

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?

Since the input schema has 0% description coverage, the Args block is essential. It clarifies message_id as the message to send and scheduled_date as an ISO 8601 datetime with an explicit default behavior. collector_id is mostly a restatement of the schema title, but the other parameter meanings are meaningfully expanded.

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 'Sends an email message to all recipients of a collector,' which is a specific verb, resource, and scope. This clearly distinguishes the tool from siblings like surveymonkey_create_collector_message and surveymonkey_list_collector_messages.

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 guidance on when to use this tool versus alternatives, such as when to call create_collector_message first or list_collector_messages. The only signal is the verb 'sends,' so usage context is implied rather than explained.

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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the operation is a PATCH update, but it does not explain side effects, authorization needs, whether the update is partial or full replacement, reversibility, or what the API returns. The field list gives some context but leaves important behavioral traits undisclosed.

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 compact and front-loaded: one clear opening sentence followed by a terse, well-organized argument list. Every line adds useful information, and there is no 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?

The description is adequate for basic calls: it identifies the two required parameters and the most common updatable fields. However, it omits important operational context such as prerequisites, error behavior, and the effect of omitted fields. Since an output schema exists, return-value documentation is not required, but behavioral gaps keep this from being fully 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 0%, so the description must compensate. It does a good job of explaining the payload parameter by listing common fields and the status enum values ('open'|'closed'). The collector_id description is thin but adequate, and the payload semantics are meaningfully enriched beyond the bare 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 'Updates a collector (PATCH)', which is a clear verb+resource statement and includes the HTTP method. This immediately distinguishes the tool from sibling get/create/delete/list collector tools, even without mentioning them explicitly.

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 the tool is used to modify an existing collector rather than create, read, or delete one, but it does not explicitly state when to choose this over create_collector or delete_collector. There are no explicit alternatives or exclusion conditions, so usage guidance is only implicit.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Updates an existing contact (PATCH)' and lists common fields, but does not mention idempotency, partial-update semantics, required permissions, error behavior, or what the response contains.

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 compact and well-organized: a one-line purpose, followed by clearly delineated Args with an example. Every sentence adds useful information and there is 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 update tool, the description covers the essential purpose and parameter semantics. However, since there is no output schema and no annotations, it does not disclose what the tool returns or any notable behavioral edge cases, leaving some gaps for an agent deciding whether 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?

The schema only provides types and titles, so the description adds meaningful value by clarifying that payload contains fields to update, listing common fields ('email', 'first_name', 'last_name'), and giving an example payload. This compensates for the schema's lack of detail on the payload object.

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 operation: 'Updates an existing contact (PATCH).' This specifies both the verb and resource, and the PATCH method distinguishes it as a partial update among the contact sibling tools like create_contact, delete_contact, get_contact, and list_contacts.

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 for existing contacts rather than creating new ones, but it does not explicitly name alternatives or state when not to use this tool. There is no direct comparison with create_contact or delete_contact, so the guidance 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.

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

With no annotations provided, the description carries the full behavioral disclosure burden. It states that the operation updates a page and lists updatable fields, but it does not mention permissions, partial-update semantics, side effects, error conditions, or what happens to unspecified fields. This is a minimal disclosure for a mutation tool.

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 compact and efficient. The first sentence states the core operation, and the argument list adds necessary parameter details without any filler or redundant explanation.

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 operation, parameters, and payload fields, and an output schema exists so return-value documentation is not required. However, with no annotations and no usage alternatives or behavioral caveats, the description leaves some gaps around edge cases and update semantics. It is adequate for a simple update tool but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It gives brief but meaningful explanations for each argument: survey_id, page_id, and payload. It also enumerates the acceptable payload fields ('title', 'description', 'position'), adding value beyond the bare schema. It could specify types or constraints for those fields, but it provides useful 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 clearly states the action: 'Updates a page in a survey (PATCH).' It identifies the specific resource (page), the parent context (survey), and the HTTP method, which distinguishes it from sibling tools like create_page, delete_page, and get_page.

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 the tool is for modifying an existing page, but it provides no explicit guidance on when to prefer this over related tools such as update_survey or create_page, nor any exclusion criteria. The usage context is only implied by the verb 'Updates' and the resource type.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says PATCH and 'fields to update', implying a partial mutation, but it does not mention permissions, idempotency, validation, side effects, or response behavior. This leaves significant operational uncertainty.

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 compact and front-loaded, with a clear purpose sentence followed by a terse argument list. There is no filler, and the structure makes it 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?

Despite having an output schema, this tool has 4 required parameters, a nested payload, and zero annotations. The description omits where the IDs come from, partial-update behavior, prerequisites, and error conditions. It is minimally viable but not complete enough for confident invocation in complex 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 0%, so the description needed to define parameters meaningfully. It merely restates 'Survey ID', 'Page ID', and 'Question ID' without adding semantics, and payload is only delegated to another tool's schema. The payload reference is useful, but the ID descriptions add little beyond the property names.

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 'Updates an existing question (PATCH)', giving a specific verb, resource, and HTTP method. 'Existing' clearly distinguishes this from create, delete, and get question siblings.

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 makes the usage context clear: use this when updating an existing question. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough to route an agent correctly.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly communicates that this is a full replacement (PUT) and that the provided definition must be the complete new definition, implying destructive overwrite. It does not mention permissions or error behavior, but the core behavioral trait is transparent.

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 compact and front-loaded. The first sentence conveys the core operation, the second gives the routing rule, and the Args section is 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 full-replace operation with two parameters, the description covers what the tool does, when to use it, and what the parameters mean. An output schema exists, so return-value details are not needed in the description. Minor omissions like authentication requirements or side-effect warnings are not critical given the clear 'fully replaces' language.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for both parameters: survey_id is 'ID of the survey to update,' and survey_definition is 'New complete definition (same schema as surveymonkey_create_survey).' The cross-reference to create_survey is particularly helpful given the schema's generic object type.

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: 'Fully replaces a survey's definition (PUT).' It clearly distinguishes this full-replacement update from the partial-update sibling, so an agent can tell tools apart at a glance.

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

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

Explicitly says 'Use surveymonkey_patch_survey for partial updates,' which gives the agent a concrete decision rule and names the alternative. This is strong when-to-use 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?

With no annotations, the description carries the behavioral burden; it does disclose that this is a PATCH partial-update operation, which signals mutation and merging semantics. However, it omits side-effect details such as auth requirements, idempotency, or what happens on invalid fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: one clear operation statement followed by a minimal Args block. The pointer to create_webhook's schema avoids unnecessary duplication while preserving needed 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 two-parameter tool with an output schema, the description is almost complete: it identifies the operation, the target resource, the arguments, and reuses an existing schema for payload. Minor gaps in explicit usage guidance and behavioral side effects keep it from being fully 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 0%, so the Args section is essential. It defines webhook_id and, more importantly, says payload uses the same schema as surveymonkey_create_webhook, which compensates for the empty payload object 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 'Updates a webhook (PATCH)', combining a specific verb, resource, and HTTP method. This clearly distinguishes it from create/get/list/delete webhook siblings without ambiguity.

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 this tool is for modifying an existing webhook, but it never explicitly explains when to choose it over create_webhook or delete_webhook. Usage context is present by implication, not by direct guidance.

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