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 implies a write operation ('Add') but does not mention side effects, ordering behavior, whether it requires an existing form, or how it interacts with other items. This is a significant gap 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 one short, front-loaded sentence with no wasted words. While it is efficient, it may be too terse given the tool's complexity, but conciseness itself is strong.

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 tool has 9 parameters, 4 required, no annotations, and a similar sibling (add_multiple_choice_question). The description never explains how to invoke it properly, what the output schema provides (though an output schema exists), or how it differs from alternatives. Essential context for an agent to select and use the tool correctly is missing.

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

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

Schema description coverage is low (11%), with only 'index' briefly described in the schema. The description adds minimal parameter meaning by hinting at 'choiceType' and 'options' via the phrase 'radio, checkbox, or dropdown choices', but it fails to explain the other nine parameters such as formId, questionTitle, shuffle, and 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 ('Add') and resource ('radio, checkbox, or dropdown choices'), making the core function clear. It does not explicitly differentiate from the sibling 'add_multiple_choice_question', but the enumerated choice types provide some distinction.

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 guidance on when to use this tool versus alternatives like add_multiple_choice_question or add_scale_question. There is no mention of prerequisites, exclusions, or context in which this tool is preferred.

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 exist, so the description carries the full burden of behavioral disclosure. It only states the mutation ('Add') without mentioning side effects, permissions, ordering behavior, or what happens to the existing form. For a tool with seven parameters, this is 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 one sentence, front-loaded with the action and artifact, and contains no filler. It is appropriately concise, though the terseness comes at the cost of completeness, which is captured in other dimensions.

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 seven parameters, no annotations, and low schema coverage, the description omits call-level guidance such as which boolean toggles produce date-only versus date-time questions and how this differs from add_time_question. The presence of an output schema helps with return values, but the overall context is still incomplete.

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

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

Schema description coverage is only 14%, with only index receiving a real description, yet the tool description does not explain includeTime, includeYear, required, or description. The phrase 'date or date-time' hints at includeTime but does not map the parameters to behavior.

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 names a specific action ('Add') and a specific artifact ('a date or date-time question'), so an agent can distinguish it from add_text_question and add_choice_question. It does not restate the tool name and is unambiguous about what kind of question it creates.

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 sentence tells when to prefer this tool over add_time_question or the other question-adding siblings, and no exclusions or prerequisites are mentioned. The intended usage context is only implied by the tool name and the brief 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It states a mutation ('Add') but does not mention permissions, reversibility, side effects, or behavior around the index/position. The only additional behavioral detail is that the image must come from a public URL, which is 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 a single, front-loaded sentence with no filler. Every word serves the purpose of stating the action. It is appropriately concise for a tool with a simple add operation.

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

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

The tool has 8 parameters, 3 of them required, and is a mutation operation, yet the description gives no context about how the item is added, what the index means, or what happens to existing items. An output schema exists but does not compensate for the missing behavioral and contextual information.

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

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

Schema description coverage is only 13% (only 'index' has a description), so the description must compensate for the other seven parameters. It provides limited context for sourceUri as a public URL, but does not explain formId, altText, alignment, width, title, or description. This is insufficient for an 8-parameter tool.

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 'Add' and resource 'image', with the source 'public URL' clearly stated. It distinguishes from sibling tools like add_text_item and add_video_item by specifying the media type. An agent can immediately tell what this 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 description provides no guidance on when to use this tool versus alternatives such as add_video_item or add_text_item. It does not mention any conditions, prerequisites, or exclusions. Usage must be inferred entirely from the tool name and the word 'image'.

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 'Add', with no mention of append-versus-insert semantics, the default RADIO gridType, required/shuffle behavior, or any side effects. The schema's index description hints at insertion behavior, but the description itself does not surface it.

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 text is short, fluff-free, and front-loaded with the core action, but it is under-specified for a tool with nine parameters. The brevity is closer to under-specification than to disciplined conciseness.

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 no annotations, very low schema coverage, and nine parameters, a one-clause description is far from complete. The presence of an output schema reduces the need to explain return values, but the description still lacks essential guidance about parameter semantics, defaults, and placement behavior needed to call the 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?

With schema description coverage at only 11%, the description needed to compensate, but it names no parameters except implicitly echoing the gridType enum via 'radio or checkbox'. Rows, columns, formId, title, index, required, and shuffleRows remain unexplained by the description.

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 ('Add') and resource ('grid') and names the two supported variants ('radio or checkbox'). It is reasonably distinguishable from sibling question-adders by the grid resource, though it does not explicitly contrast with tools like add_choice_question or add_multiple_choice_question.

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 its siblings. The description does not mention alternatives, exclusions, or conditions such as 'use this for multi-row/multi-column grids rather than single choice questions', leaving usage entirely implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it discloses nothing. It does not mention that this is a mutating operation, how options are handled, where the question is inserted, or any 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 text is short but under-specified rather than appropriately concise. It provides no useful structure or operational detail, so its brevity is a liability, not a strength.

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 an output schema being present, the description is grossly incomplete for a tool with 6 parameters and many closely related siblings. It omits the core action, the form context, parameter roles, and the distinction from add_choice_question.

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

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

Schema description coverage is only 17%, so the description must compensate for undocumented parameters. It does not mention formId, questionTitle, options, index, required, or description at all. Agents are left to infer meaning from parameter names alone.

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 is a noun fragment, not a statement of what the tool does. 'Compatibility alias for a radio-button question' restates the tool's name in different words and never says it adds a question to a form, leaving the action implicit. It does not distinguish this from sibling tools like add_choice_question.

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 such as add_choice_question, add_scale_question, or other question adders. 'Compatibility alias' hints at a legacy or compatibility purpose but never states a condition or preference.

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 only says 'Add', implying a mutation, but does not disclose side effects, constraints, or behavior. It doesn't mention the rating scale range, icon types, or that it appends to the form. This is insufficient for an agent to predict the tool's effect.

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 short sentence, which is concise, but it's too under-specified to be useful. It lacks structure like usage context or parameter hints, and the brevity sacrifices informational value.

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 has 7 parameters with low schema coverage and no annotations, the description is far from complete. It doesn't explain the required parameters, how to specify the question, or what the response looks like. An agent would have to infer too much from the schema alone.

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

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

Schema description coverage is only 14%, meaning most parameters lack descriptions. The description text does not explain any parameters or compensate for schema gaps. For example, it doesn't mention that ratingScaleLevel must be between 3 and 10 or that iconType has specific 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 states a specific action ('Add') and resource ('star, heart, or thumb rating'), which distinguishes it from siblings like text or choice questions. However, it doesn't explicitly mention that it's a question added to a form, and the context of the form is implied by the tool name rather than stated. Still, the purpose is clear enough to differentiate from other add_* 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?

There is no guidance on when to use this tool versus alternatives like add_scale_question or add_choice_question. The description doesn't mention scenarios, prerequisites, or exclusions, so an agent gets no routing information.

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 exist, so the description bears the full behavioral burden, and a single clause discloses essentially nothing beyond the fact that something is added. No mention of default append behavior, index insertion, the required flag default, or the mutation's effect on the form. The verb 'add' implies a write but fails even a minimal mutation warning.

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

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

One short sentence is superficially concise but this is under-specification, not conciseness. The sentence earns its place only by naming the resource; it economizes away every piece of value-add context an agent would need.

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 9-parameter form-mutation tool with no annotations and 21 siblings, one sentence is far from complete. The output schema covers return values and the index param has a schema description, but the agent still lacks where the question lands, when to prefer this over alternate question tools, and the meaning of the label and required parameters. Not a 1 only because the schema carries the hard constraints.

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

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

Schema description coverage is only 11% (just index), so the description needed to compensate for low/high, lowLabel/highLabel, questionTitle, and formId semantics — and it adds nothing. The phrase 'linear numeric scale' only weakly hints that low/high are endpoints. The schema's type and bound constraints (low 0-1, high 2-10) partially compensate and keep this just above the worst case.

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 — 'Add a linear numeric scale' — which distinguishes it from add_text_question or add_choice_question by question type. However, it never says this is a form question/item, and with the conceptually adjacent add_rating_question sibling, the scale-vs-rating distinction is left unstated. The resource is named but its place in the form model is carried by the tool name, not the description.

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 zero when-to-use guidance. It does not contrast with add_rating_question or add_choice_question, states no conditions or exclusions, and never mentions form context or prerequisites. Among 21 siblings, the agent gets no routing aid at all.

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 explaining behavior. It only says 'Add,' implying a mutation, but does not disclose what happens to existing items, whether the section is inserted at a position, whether the operation is reversible, or any side effects. This is insufficient 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 a single concise sentence with the primary action front-loaded. While it is short and efficient, it omits important behavioral and parameter context, so it is slightly under-specified rather than fully concise.

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 four parameters, no annotations, and an output schema, the description is too thin. It does not explain how to choose the insertion index, what the title should represent, or how sections affect form structure. The agent lacks critical context to invoke this correctly beyond basic parameter names.

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

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

Schema description coverage is only 25% since only 'index' has a description. The description does not explain 'title', 'formId', or 'description' beyond the vague implication that they relate to a section. It adds minimal semantic value and fails to compensate for the low schema coverage.

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

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

The description states a specific action ('Add') and a resource ('section/page break') and is distinct from sibling tools like add_text_question and add_image_item. However, the phrase 'section/page break' is slightly ambiguous about whether it adds a section, a page break, or both, which prevents a 5.

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

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

No guidance is given about when to use this tool versus alternatives. There is no mention of organizing questions into sections, no exclusions, and no reference to sibling tools. The agent must infer usage from the tool name and sibling names.

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 only says 'Add non-question explanatory text', which implies a mutation but doesn't disclose what resource is modified (the form), whether the form must exist, or any side effects. For a mutating tool with zero annotation coverage, 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 a single short sentence with no filler and the core purpose is front-loaded. It is efficient, though the brevity borders on under-specification rather than valuable conciseness. Still, for what it does say, it is well-structured.

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 4 parameters, including an insertion index, and it performs a mutation. The description doesn't explain that it adds an item to a form, the meaning of the index parameter, or what happens to existing items. Although an output schema exists, the description leaves critical context missing 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?

Only 1 of 4 parameters (index) has a description in the schema, giving 25% coverage. The tool description doesn't mention formId, title, description, or index at all, so it adds no meaning beyond the schema. With low schema coverage, the description should compensate, but it doesn't.

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 'Add' and identifies the resource as 'non-question explanatory text', which clearly differentiates it from sibling add_text_question and other add_* tools. An agent can determine its purpose immediately without reading the schema.

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

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

The phrase 'non-question' implies this is for explanatory text rather than questions, providing some usage context. However, there is no explicit when-to-use guidance, no mention of alternatives, and no exclusions. The agent must infer usage from the name and sibling 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 reveals only that the tool creates something ('Add'), without mentioning side effects, required ownership of the form, whether items can be inserted at a position, or any destructive behavior. This is a minimal mutation description with no additional behavioral context.

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 efficient sentence with no wasted words and front-loads the core purpose. It is not padded, though it could include more substantive guidance without becoming bloated.

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 6 parameters, no annotations, and a large sibling set including add_text_item and many add_*_question tools, this one-sentence description is insufficient. An output schema exists, so return values need not be described, but usage routing, parameter semantics, and behavioral details remain under-specified.

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

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

Schema description coverage is only 17%, and the description adds almost no parameter-level meaning. It hints that 'paragraph' distinguishes short-answer from paragraph questions, but does not clarify formId, questionTitle, required, or description. The schema's property names are somewhat self-explanatory, but the description fails to compensate for the low coverage.

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

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

The description states a specific action ('Add') and a specific resource ('short-answer or paragraph question'), clearly identifying this as a free-text question tool. It distinguishes from obvious siblings like add_choice_question or add_date_question by type, though it does not explicitly name any alternative.

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 'short-answer or paragraph' implies this tool is for open-ended text questions rather than choice, scale, date, or content-item tools. However, it gives no explicit guidance about when to use it versus siblings like add_text_item, and no exclusions or prerequisites are stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Add,' implying a mutation, but does not mention side effects, permission requirements, or behavior around the index parameter. It lacks any details beyond the basic action.

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

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

The description is a single, front-loaded sentence with no fluff. It is concise and easily understood. While it may be too brief to cover all parameters, conciseness itself is well handled.

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 mutation tool with 6 parameters and minimal schema coverage, the description is incomplete. It does not clarify the purpose of key parameters like `duration`, `required`, or `index`, nor does it explain the relationship between `time-of-day` and the boolean `duration` flag. The output schema exists, but the description still leaves too much to inference.

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

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

Schema description coverage is only 17% (only the index parameter has a description). The description adds minimal meaning by hinting at the 'duration' concept, which likely maps to the `duration` boolean parameter, but it does not explain formId, questionTitle, description, required, or index. This does not compensate for the low schema coverage.

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

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

The description uses a specific verb and resource: 'Add a time-of-day or duration question.' It clearly distinguishes the tool from siblings like add_date_question by specifying time-of-day and duration. It could be more explicit about the form context, but it is not a tautology.

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 add_date_question or add_text_question. The description does not mention exclusions, prerequisites, or specific scenarios. Usage must be inferred entirely from the tool name and 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. 'Add' implies a create/mutation operation, but it does not disclose whether the operation is destructive, requires authentication, is idempotent, or what happens to existing items. The behavioral profile is almost entirely absent.

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 short sentence with no filler, so it is structurally concise and front-loaded. However, it is under-specified to the point of being nearly tautological with the tool name, providing almost no actionable detail beyond the name itself. It is not bloated, but it also does not earn its place with useful 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 an 8-parameter tool with no annotations and only 13% schema description coverage, this description is substantially incomplete. It does not mention the required formId parameter, the placement semantics of index, or how the video item fits into the form structure. While an output schema exists, the description still leaves critical invocation details to inference.

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

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

Schema description coverage is only 13%, and the description adds essentially no parameter semantics. It does not clarify the format of youtubeUri, the meaning of formId, or how index, title, caption, width, and alignment interact. The phrase 'YouTube video' adds little beyond what the parameter name youtubeUri already conveys.

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 a specific verb and resource: 'Add a YouTube video.' This distinguishes it from siblings like add_text_item and add_image_item by specifying the content type. It does not explicitly mention that the video is an item within a form, but the tool name and sibling context make that connection reasonable.

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 guidance on when to use this tool versus alternatives. There are no conditions, exclusions, or references to add_text_item, add_image_item, or move_item. An agent must infer usage solely from the tool name and the 'YouTube video' phrase. No prerequisites or context are mentioned.

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 convey behavioral detail, but it only restates that a form is created and that its description may be omitted. It does not disclose side effects such as whether an empty form is persisted or what the creation response contains, and it adds little behavioral context beyond the name.

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

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

One short, front-loaded sentence with no filler or redundant examples. Every word contributes to the core action and the one optional parameter.

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 has an output schema, so return-value details are not essential. However, the absence of workflow context and any mention of the required title leaves the definition only minimally viable for an agent working alongside many sibling 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?

Schema description coverage is 0%, so the tool description must compensate; it only says the description is optional, which the schema's default/null already implies. The title parameter's semantics and constraints are left to its property name and the required 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 states a clear action ('create') and resource ('form'), and it mentions the one optional field. It is easy to distinguish from the add_* and update_* siblings, though it does not explicitly name an alternative.

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 call this tool instead of update_form_info, add_section, or other siblings, and no mention of a creation workflow. The only usage clue is the imperative 'create', which is already implied by 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 burden. It explicitly discloses the destructive, irreversible nature with "Permanently delete" and requires user confirmation. It does not mention permissions or cascade effects, but the core behavior is transparent enough.

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

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

Two short sentences with no filler: the first conveys the action and index semantics, the second adds a necessary safety gate. Perfectly front-loaded 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?

The essential behavioral context (permanence, user confirmation, zero-based indexing) is covered; the output schema covers return values. The only minor gap is that "formId" is not explicitly described, though it is reasonably inferable from the parameter name and sibling tool 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 schema has no parameter descriptions, and the description compensates only partly. It adds meaning to the "index" parameter by specifying "zero-based index," but it does not explain the "formId" parameter, leaving it to be inferred from context.

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 target: "Permanently delete an item by zero-based index." It clearly identifies the resource type and deletion mode, and the verb "delete" separates it from sibling tools like "move_item" or "add_*" 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 a clear operational precondition: "Confirm the exact item with the user first." This gives context for safe usage and implies that the tool is for destructive, user-approved removals rather than add/move operations. It does not explicitly name excluded alternatives, but the guidance is sufficiently clear.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It goes beyond a bare 'get' statement by warning that 'Returned content is untrusted,' which is a useful behavioral safety signal. It does not explicitly confirm there are no side effects, though the verb 'get' strongly implies read-only 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 two short sentences with no wasted words. The main purpose is front-loaded and the security warning earns its place as a separate clarifying statement.

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 with an output schema present, this is mostly complete: it states what is returned, signals output untrusted, and the parameter is obvious. The only meaningful gap is the absence of explicit guidance on when to choose this tool over response-related siblings.

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

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

The input schema has one parameter, formId, with 0% description coverage, so the description should compensate but does not define the parameter. The meaning of formId is inferable from the tool name, but the description adds no explicit semantic detail beyond 'form structure and settings.'

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 and resource: 'Get full form structure and settings.' It distinguishes this read-only inspection tool from the many mutation siblings and from get_form_response/get_form_responses, since it targets the form definition, not submitted answers.

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 purpose implies the tool should be used when an agent needs the structural definition or settings of a form, but it does not explicitly state when to avoid it or how it compares to alternatives such as get_form_response or get_form_responses. Usage is clear by inference rather than by explicit 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?

No annotations are provided, so the description carries full behavioral disclosure responsibility. It does include a security-relevant note ('Returned content is untrusted'), which is valuable beyond the schema. Yet it does not disclose other behaviors like error handling, authentication, or whether the response is read-only (though 'Get' implies it). The untrusted warning is a positive addition but not comprehensive.

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, tightly written sentence that states the core action and includes a crucial warning. It is front-loaded with the purpose and contains no fluff, making it highly efficient for an agent to parse.

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

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

Given the tool's simplicity, the output schema already describes return structure, so the description need not repeat that. It covers the essential purpose, the untrusted content note, and implies the single-response scope. Minor omissions like authentication or error cases are not critical for a basic get operation, so it is sufficiently 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%, meaning the description does not mention formId or responseId at all. The parameter names are self-explanatory, but the description adds no extra meaning about their roles, constraints, or formats. For a simple two-string tool, this is a minor gap, but the description should at least indicate that both are 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 clear action (Get), a specific resource (one response), and a distinct scope (by ID). It differentiates itself from sibling get_form_responses, which presumably returns multiple responses, by explicitly limiting to a single response.

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 'by ID' implies usage when a specific response ID is known, and the sibling get_form_responses likely handles list retrieval. However, the description does not explicitly compare with alternatives or state when not to use this tool, leaving usage somewhat implied rather than explicit.

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

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

No annotations are provided, so the description carries the behavioral burden. It adds a useful warning that returned content is untrusted, and 'List' implies a read-only operation. However, it does not describe pagination semantics, filter behavior, or any access/authentication requirements beyond that one warning.

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

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

Two short sentences with no redundancy. The primary action is front-loaded, and the security warning earns its place. It is appropriately sized for a straightforward listing tool.

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

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

An output schema exists, so return values are covered elsewhere. The description is adequate for a simple list call, but it lacks filter syntax, pageToken guidance, and explicit differentiation from get_form_response. With no annotations, an agent is left to infer some operational 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%, so the description must compensate. It only vaguely references 'pagination/filter support' and does not explain the filter string format, how pageToken should be used, or the relationship between pageSize and pagination. The parameter names are self-explanatory, but meaningful invocation details are absent.

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 ('List responses') and names pagination/filter support. It is distinguishable from the sibling get_form_response by the plural 'responses' and 'List', but it does not explicitly contrast itself against that 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?

The description implies this is the tool to use for listing multiple responses, especially with pagination/filtering. However, it gives no explicit guidance about when to choose this over get_form_response or other siblings, and no exclusions or prerequisites are mentioned.

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 disclosure burden. It reveals that positions are zero-based, but does not state that this mutates the form, whether the operation is reversible, what validation applies, or what permissions are required.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to the core meaning, making it concise and easy to parse quickly.

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

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

Despite an output schema being present, the description still fails to cover essential context: it does not explain which form owns the item, what item types are valid, or whether movement has any permanent side effects. For a mutation-like operation with three required parameters and zero annotation support, the description is too minimal to be fully actionable.

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 undocumented parameters. It only adds meaning to fromIndex and toIndex via 'zero-based positions', while formId is left entirely unexplained and no distinction between source and destination index is made.

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 ('Move'), a resource ('item'), and a key detail (zero-based positions), so the tool's core function is clear. It does not explicitly contrast with sibling tools like delete_item or add_text_item, but the move action is distinct enough to be identifiable.

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 guidance about when to use this tool versus alternatives such as delete_item or reordering via other means. It also does not mention any prerequisites or conditions under which moving an item is appropriate, leaving usage to inference.

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, but it only says 'set' without disclosing whether values are overwritten, whether null leaves a setting unchanged, or what side effects occur. It doesn't mention permissions, reversibility, or failure 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 a single front-loaded sentence with no wasted words; every term earns its place. Its brevity is a strength even though other dimensions suffer from lack of detail.

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 mutation tool with no annotations and only 0% schema coverage, a seven-word description is insufficient to support correct invocation. It doesn't explain how the optional/null parameters behave, when to use this versus siblings, or what the output represents; the output schema covers return type but not usage 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 description maps 'quiz mode' and 'email collection' to the isQuiz and emailCollectionType parameters, but it adds no detail beyond the property names. At 0% schema coverage, it should explain null semantics and the emailCollectionType enum choices; it doesn't, and it also omits the required formId context.

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 names a concrete action ('set') and identifies the affected resources ('quiz mode' and 'email collection'), which clearly differentiates it from sibling tools like set_publish_settings. It doesn't explicitly call out what it is not, so it stops short of full sibling differentiation.

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

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

There is no guidance on when to choose this tool rather than update_form_info or set_publish_settings, and no mention of prerequisites or exclusions. The only implicit signal is that it is for quiz mode/email collection settings, which is not enough to guide tool 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, the description carries the behavioral disclosure burden. It clearly reveals that this tool mutates publication and response-acceptance state, and it adds an important safety requirement to get user confirmation first. It does not mention permissions or side effects, but the output schema covers return expectations.

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

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

Two short sentences with no filler. The primary action is front-loaded, and the essential user-confirmation instruction follows immediately.

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-required-boolean toggle tool with an output schema, this is largely complete: it explains both toggles, includes the key safety rule, and does not need to re-explain return values. The main missing piece is explicit sibling differentiation, which is already reflected in the usage dimension.

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 usefully maps 'publish/unpublish' to isPublished and 'enable/disable responses' to isAcceptingResponses, but formId remains implicit and no additional parameter relationships or value effects are described.

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 a precise dual action: publish/unpublish the form and enable/disable responses. It identifies the resource and the state changes, but it does not explicitly contrast with related siblings like set_form_settings, so it stops short of a 5.

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

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

It provides an explicit operational rule: confirm with the user before changing availability. However, it does not state when to prefer this tool over set_form_settings or other form-management siblings, nor does it give exclusions or alternatives.

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 only states that the tool mutates grading-related fields; it does not disclose whether existing grading is overwritten, whether the question must already exist, whether feedback can be cleared by setting null, or any 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 a single front-loaded sentence with no filler. Every phrase conveys a distinct piece of information relevant to selecting and invoking the tool.

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

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

The description covers the core operation and all substantive parameters, and the presence of an output schema means return-value details are unnecessary. However, with no annotations and no schema field descriptions, it lacks behavioral depth and any guidance on prerequisites or alternatives, leaving it only minimally 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 adds useful meaning by mapping pointValue to 'quiz points', correctAnswers to 'answer key', and whenRight/whenWrong to 'right/wrong feedback'. However, formId and itemIndex are not glossed, and the exact shape of the answer key is left to the schema.

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

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

The description uses a specific verb ('set') and resource ('question item'), and enumerates exactly what is configured: quiz points, answer key, and right/wrong feedback. This clearly distinguishes it from sibling tools like add_question/delete_item and form-level settings 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?

There is no guidance about when to use this tool versus alternatives, no prerequisites, and no exclusions. The only contextual clue is the phrase 'for a question item', which implies it applies to an existing item but does not explicitly say so.

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 ('Update') and the fields, without clarifying whether omitted or null values clear fields, whether changes are reversible, or what response is returned.

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

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

The description is a single front-loaded sentence with no filler words. Every term contributes meaning, and the key update target is stated immediately.

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 has an output schema, so the description does not need to explain return values. However, it leaves important gaps around null/omitted field behavior and when to choose this tool over sibling settings tools, making it adequate but incomplete.

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

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

With 0% schema description coverage, the description must compensate, but it only names title and description while leaving formId implicit. It adds the useful 'visible' and 'and/or' nuances, but it does not explain the required formId or the meaning of null 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?

The description states a specific verb ('Update') and resource ('visible form title and/or description'), making the tool's purpose clear. It is distinguishable from sibling tools like add_section or set_form_settings, though it does not explicitly name alternatives.

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 the tool: when you need to update the form's visible title or description. However, it provides no explicit guidance about when not to use it or how it differs from related settings tools such as set_form_settings.

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