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

No annotations are provided, so the description must convey behavioral side effects. It only says 'acknowledges,' but the action bitmask in the schema shows the tool can also close problems, change severity, suppress, etc. This significant behavioral scope is undisclosed, making the description inadequate 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 no redundant information. It is front-loaded and easy to parse, though it omits important details, making it slightly under-specified rather than efficiently 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 the tool's complexity (action bitmask with multiple behaviors), the description is too minimal. It does not mention the ability to close problems or change severity, nor does it describe expected outcomes or return values. The detailed schema partially compensates, but the description itself is 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 descriptions cover 100% of parameters, providing detailed explanations, including the action bitmask and field purposes. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Acknowledges') and resource ('one or more events/problems in Zabbix'), distinguishing it from sibling tools such as zabbix_get_events and zabbix_get_problems. No ambiguity about what it 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 implies the tool is for acknowledging events/problems but provides no explicit guidance on when to use it versus alternative tools or when not to use it. The context of the tool name and sibling list makes the usage inferable, but explicit exclusions are missing.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states that it creates an action, but does not mention that it writes to the Zabbix backend, may require authentication permissions, or could have side effects such as triggering automated responses. There is no context about reversibility or preconditions.

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

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

The description is a single, front-loaded sentence that precisely states the tool's purpose. Every word earns its place; there is no filler or redundant 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?

Given the complexity (15 nested parameters, no output schema), the description is too minimal. It doesn't explain how 'filter' and 'operations' work together to define an action, what the expected return value is, or what prerequisites must exist. The schema is comprehensive for parameters, but the description fails to provide an operational overview or context for the action creation workflow.

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

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

Schema description coverage is 100%, so the baseline is 3. The tool description itself adds no parameter information, but the input schema provides detailed descriptions for all 15 parameters, including semantics, defaults, and nested structures. The description does not compensate beyond the schema but doesn't need to.

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 'Create' and identifies the resource as 'a new action in Zabbix' with its purpose 'for automated responses to events'. This clearly distinguishes it from sibling tools like zabbix_get_actions, zabbix_update_action, and zabbix_delete_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 implies use when you need to create a new Zabbix action, but it gives no explicit guidance on when to use it vs alternatives or any prerequisites (e.g., existing host groups, media types). It doesn't state exclusions, but the purpose is clear enough to infer basic usage.

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 must carry the full behavioral burden. It only restates the tool's purpose (create) without disclosing any side effects, permissions, idempotency, or error behavior. This is essentially a tautology of the tool name and provides no additional 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 a single, front-loaded sentence with no wasted words. It is appropriately concise, though it is minimal to the point of under-specification for a tool with complex nested parameters. Still, it earns its place and is not padded.

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 nested objects and no output schema, but the description says nothing about return values, prerequisites, or how correlations fit into Zabbix's event management. It is too sparse to fully guide an agent, relying entirely on schema field descriptions for 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 100%, so the baseline is 3. The description adds no parameter information, but the schema fully documents each parameter, including nested structures like filter and operations. The description does not need to compensate for schema gaps.

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

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

The description clearly states the tool's action ('Create') and resource ('event correlation' in Zabbix), distinguishing it from sibling tools like zabbix_get_correlations or zabbix_delete_correlations. It is specific and unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention scenarios where creating a correlation is appropriate, nor does it distinguish from create-related tools for other resources. The description is purely declarative and offers no usage 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?

There are no annotations, so the description carries the full burden. It specifies that a new dashboard is created, but does not disclose any permissions required, side effects (e.g., whether it can overwrite an existing dashboard), or what happens on success/failure. It also doesn't mention whether the operation is idempotent.

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 sentence, front-loaded with the verb 'Create', and no unnecessary words. It is appropriately short for a simple CRUD 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 is complex (8 parameters, nested widget structures), yet the description is only a one-liner. It does not provide any high-level context about dashboard structure, page/widget requirements, or ownership defaults. The schema covers parameter details but the description offers no synthetic guidance.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters in detail. The description adds no additional parameter meaning, such as typical values or relationships, so it meets the baseline for high schema coverage.

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

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

The description clearly states the action (creating) and the resource (a Zabbix dashboard), with 'new' distinguishing it from update/delete/get dashboard tools. It is specific to dashboards, not maps, despite both being visualization 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 no guidance on when to use this tool versus updating or deleting dashboards, nor any prerequisites or context. It does not mention alternatives or when not to use it.

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

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

There are no annotations, so the description carries full burden. It fails to disclose any side effects, prerequisites (e.g., host must exist), permissions, or whether the rule is enabled by default. The single sentence offers zero behavioral insight beyond the action itself.

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

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

The description is a single sentence with no wasted words, aligning with conciseness. However, it is not front-loaded with key differentiators or usage context. It is efficiently worded but lacks substance for a tool of this complexity.

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

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

With 12 parameters, nested objects, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, required versus optional fields, or how to construct valid requests. It only restates the tool's name, leaving the agent to rely solely on 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 100%, with every parameter having a description. The tool description adds no additional parameter meaning, so the baseline score of 3 applies. It does not clarify relationships between parameters or provide examples 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 clearly states the verb 'Create' and the resource 'Low-Level Discovery (LLD) rule in Zabbix'. This distinguishes it from update/delete/get discovery rule siblings, though it could be more specific about the Zabbix API context.

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 (e.g., zabbix_create_item, zabbix_get_discovery_rules). It simply states the action with no context or exclusions, offering no help for 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?

No annotations are provided, so the description carries the full burden. It merely states 'Create a new host group' without disclosing potential side effects, permission requirements, idempotency, or error behavior. For a mutating tool, this is a significant transparency 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, front-loaded sentence with no filler. Every word earns its place, making it appropriately concise for a simple 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 tool is simple with one well-documented parameter, so the description covers the essential operation. However, it omits any mention of return values, error conditions, or relationship to other Zabbix entities (e.g., hosts), leaving minor but relevant gaps for an 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 100% (the 'name' parameter is described as 'Name of the host group'). The description adds no additional meaning beyond the schema, so it meets the baseline for high 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 ('Create') and a clear resource ('host group'), and it distinguishes this from sibling tools like zabbix_update_hostgroup and zabbix_delete_hostgroups. The purpose is immediately 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of context such as the need to create host groups before assigning hosts. The description states only the action itself, offering no decision support.

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 for disclosing behavior. It only states 'Create a new icon map' which implies a mutation, but it does not describe side effects (e.g., whether duplicate names are allowed), required permissions, or the response format. For a write operation with zero annotation coverage, this is a significant gap in 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 a single sentence that is front-loaded with the action and object. Every word earns its place, with no wasted phrasing. It is appropriately sized for a simple create tool.

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

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

For a simple create operation with a fully described schema, the description is adequate but not complete. It lacks guidance on prerequisites such as how to obtain icon IDs or the significance of inventory field numbers. There is no mention of the return value or error conditions, which would be helpful given no output schema exists. Overall, it is minimal but sufficient for a straightforward creation task.

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

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

The input schema provides descriptions for all three parameters (name, default_iconid, mappings), achieving 100% schema description coverage. The tool description adds no additional meaning beyond what the schema already explains. Per the rubric, baseline 3 is appropriate when the schema does the heavy lifting, and the description doesn't compensate further.

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

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

The description clearly states the tool's purpose: 'Create a new icon map in Zabbix for mapping inventory fields to icons'. The verb 'Create' combined with the specific resource 'icon map' and the purpose 'mapping inventory fields to icons' is unambiguous. It distinguishes from sibling tools like 'zabbix_create_map' (likely for network maps) and 'zabbix_update_icon_map'.

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 when you need to create an icon map, but provides no explicit guidance on when to choose this tool over alternatives like 'zabbix_create_map' or when to use 'zabbix_update_icon_map' instead. There are no exclusions or prerequisites mentioned. The purpose is clear enough that an agent could infer the right context, but explicit guidance is missing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a new item is created, but does not disclose side effects, required permissions, idempotency, or what happens if the item key already exists. The absence of return-value information and error conditions makes behavioral transparency weak.

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 zero wasted words. It communicates the core purpose efficiently, matching the high-conciseness standard of exemplary descriptions. No unnecessary details or repetition.

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

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

For a tool with 14 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It does not explain expected return values, prerequisites (e.g., host must exist), or behavior on validation failures. The description is minimal and leaves critical context unaddressed.

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

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

The input schema provides descriptions for all 14 parameters with 100% coverage, so the schema does the heavy lifting. The description adds no additional parameter semantics beyond 'Create a new item', which is simply the tool's action. Baseline score of 3 is appropriate.

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

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

The description 'Create a new item in Zabbix' clearly states a specific action (create) and resource (item), distinguishing it from sibling tools like zabbix_update_item, zabbix_delete_items, and zabbix_get_items. However, it lacks additional context about what an item is or the scope of creation, so it does not fully differentiate from other create 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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contrast with sibling tools like zabbix_create_trigger or zabbix_create_host. Agents are left to infer appropriate usage solely 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that a new maintenance period is created, with no details about permissions, return value, conflict handling, or idempotency.

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

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

The description is a single sentence with minimal waste, though the phrase 'in Zabbix' is redundant given the tool name. It is appropriately short but could be more concise by removing that 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?

Despite a fully described schema, the description lacks any mention of return values, prerequisites, or behavior on failure. With no output schema and a complex 9-parameter input including nested timeperiods, this description is inadequate for an agent to fully understand the operation's 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 provides descriptions for all 9 parameters, so the schema already covers parameter semantics. The tool description adds no additional parameter-level information, meriting the baseline score of 3.

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

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

The description uses the specific verb 'Create' with the resource 'maintenance period' and context 'in Zabbix', clearly identifying the operation. It distinguishes from sibling tools like update/delete/get maintenance.

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. There is no mention of prerequisites, scheduling considerations, or relationship to update/delete maintenance operations.

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 must convey behavioral traits. It only says 'Create' which implies a mutation, but it does not disclose side effects, required permissions, idempotency, error behavior, or that it likely returns a map ID. This is a significant gap for a complex create 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 a single, direct sentence with no fluff or repetition. It is concise and front-loaded. However, it offers very little substance for a tool of this complexity, so while efficient, it could be more informative without excessive length.

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 high complexity (34 parameters, nested objects, no output schema), the description is far too sparse. It does not mention what the function returns, prerequisites like needing existing iconmapids or host IDs, default behaviors, or any operational context. The schema covers parameters, but the description fails to provide higher-level 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 provides 100% parameter description coverage and is exceptionally detailed (e.g., enum-like definitions for drawtype, label_type, permissions). The description itself adds no parameter-level meaning. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the action ('Create'), the resource ('a new network map'), and the purpose ('for network topology visualization'). This verb+resource structure distinguishes it from sibling tools like zabbix_update_map and zabbix_delete_maps.

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 usage guidance is provided. The description does not mention when to use this tool instead of alternatives, what prerequisites exist (e.g., valid icon IDs, existing elements), or any exclusions. There is no reference to sibling tools for comparison.

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. It only repeats the action implied by the name, offering no information about permissions, side effects, error handling, or idempotency. This is essentially zero added value.

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, succinct sentence that immediately states the action and scope. It wastes no words and is appropriately 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?

This is a complex tool with 27 parameters and type-specific requirements (Email needs SMTP fields, Webhook needs webhook_* fields, etc.). The description is too minimal to help an agent determine which parameters apply to the chosen media type. It lacks critical usage context despite the rich 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 100%, so the schema fully documents all 27 parameters. The description adds no parameter semantics beyond the schema, which aligns with the baseline of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Create a new media type in Zabbix' with examples of types. It distinguishes from sibling tools via the verb 'create' (vs. update/delete/get/test).

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 vs alternatives (e.g., zabbix_update_media_type for modifying existing ones). No prerequisites, type-specific parameter selection, or context for when to choose one media type over another is 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a proxy is created, with no information about side effects, idempotency, required permissions, or what the API returns. The description is essentially a restatement of the tool name and provides no insight into behavior beyond the action itself.

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

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

The description is a single sentence with no filler or redundancy. It is concise and front-loaded with the verb and object. However, it is so brief that it lacks useful context beyond the tool name, which slightly lowers the score from 5 to 4.

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 complexity (22 parameters, no output schema, no annotations), a single vague sentence is insufficient. The description does not explain the purpose of a proxy in distributed monitoring, the distinction between active and passive modes (though operating_mode is in schema), or any caveats. A more complete description would mention that creating a proxy is a prerequisite for distributing monitoring tasks and that certain parameters are conditional on operating_mode.

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

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

Schema description coverage is 100%, so all 22 parameters are documented in the input schema. The description itself adds no parameter information (e.g., it does not explain the significance of operating_mode or the relationship between address and operating_mode). Per the rubric, baseline is 3 when coverage is high; the description neither enhances nor detracts from schema-provided 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 ('Create a new proxy') and the resource ('proxy in Zabbix for distributed monitoring'). It distinguishes this from sibling tools that create other resources (e.g., zabbix_create_map, zabbix_create_hostgroup) and from proxy-related operations like update/delete.

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 (e.g., zabbix_update_proxy for modifying an existing proxy). It does not mention prerequisites, such as the need for valid Zabbix credentials, or scenarios where creating a proxy is appropriate. There is no 'use this when...' 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 disclosing behavioral traits. However, it only says 'Create a new script' without explaining side effects, required permissions, error conditions, or return values. This adds no transparency beyond what the tool name already implies.

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 as a single, clear sentence. It front-loads the essential verb and object without redundancy, though it under-specifies details that might be expected in a more complete 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 complexity (17 parameters, 4 required, no output schema), the description is severely incomplete. It does not explain return values, required fields, or the overall behavior of script creation, relying entirely on the schema for parameter details and failing to contextualize when and why this tool is used.

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 100% coverage with descriptions for all 17 parameters, including types, ranges, and meanings. The tool description itself adds no parameter-specific information, so the baseline score of 3 applies as the schema fully documents the parameters.

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 (Create), the resource (a new script), and the context (in Zabbix). This distinguishes it from sibling tools like zabbix_update_script, zabbix_delete_scripts, and zabbix_execute_script, which perform different operations on scripts.

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, prerequisites, or context. It does not mention that this is for creating a new script as opposed to updating or executing an existing one, so the agent receives no usage direction beyond the general operation 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'Create a new business service' without revealing side effects, prerequisites, return values, or any other behavioral context, which 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, front-loaded sentence with no redundant information. It is concise and every word serves a purpose.

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

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

The tool has 12 parameters and no output schema, yet the description only states the basic action. It does not mention expected return values, service hierarchy constraints, or any other high-level context needed to fully understand the operation. The rich schema partially compensates, but the description remains 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 100%, meaning every parameter has a description in the schema. The tool description adds no additional parameter meaning, but the high coverage warrants a baseline score of 3.

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

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

The description clearly states the tool's function: creating a new business service in Zabbix. It uses a specific verb and resource, distinguishing it from related service tools like zabbix_update_service and zabbix_delete_services.

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 creating a new service but provides no explicit guidance on when to use it versus alternatives. It does not mention any exclusions or scenarios where other tools should be preferred, leaving usage context 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 merely repeats the generic 'create' semantics without any additional context such as required permissions, duplicate handling, side effects, or return behavior. This is insufficient for a state-changing 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?

A single, direct sentence with no filler words. It is appropriately concise for a simple create operation and front-loads the core purpose effectively.

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 output schema and no annotations, the description leaves out essential context: return values, prerequisites, failure modes, and idempotency. The minimal one-liner is too sparse for an agent to invoke the tool 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?

The input schema already includes descriptions for all four parameters (host, name, groups, description), achieving 100% schema coverage. The description adds no extra parameter-level detail, so the baseline score of 3 applies.

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

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

The description clearly states the action ('Create') and the target resource ('a new template in Zabbix'), distinguishing it from sibling tools like zabbix_update_template and zabbix_delete_templates. The verb+resource combination is specific and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives such as zabbix_update_template, nor does it mention prerequisites (e.g., host groups must exist). It only implies usage for creating a new template, but offers no explicit context 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 of behavioral disclosure. However, it only restates the creation action and offers no details about permissions, idempotency, side effects, failure modes, or what happens if the trigger already exists. This adds little beyond the tool name itself.

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

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

The description is a single sentence with no wasted words. It front-loads the core purpose and is appropriately sized for a simple create operation, even if it lacks behavioral 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?

Despite the schema being rich, the description is too sparse to be contextually complete. It does not mention prerequisites (e.g., required host or existing items for the expression), what the tool returns (likely a trigger ID), or the implications of the 'status' and 'priority' fields. For a create tool with no annotations or output schema, this is a significant gap.

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

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

Schema description coverage is 100%, with all six parameters clearly documented (e.g., 'expression' as 'Reduced trigger expression', 'status' as '0 - enabled, 1 - disabled'). The description itself provides no additional parameter information, so the baseline score of 3 applies.

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

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

The description clearly states the action ('Create') and the resource ('a new trigger in Zabbix'), which distinguishes it from sibling tools like zabbix_update_trigger and zabbix_delete_triggers. The verb+resource structure is specific and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as zabbix_update_trigger for modifying existing triggers or zabbix_delete_triggers for removal. There are no prerequisites, contextual conditions, or exclusions mentioned. The usage is only implied by the verb 'Create'.

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 does not disclose side effects, permissions needed, or behavior on duplicate usernames.

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

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

The description is a single sentence, which is concise, but it essentially restates the tool name without adding meaningful structure. It is under-specified rather than efficiently informative.

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 14 parameters and no output schema, the one-line description is insufficient to guide usage. It lacks context about required parameters, return values, or typical use 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 100%, so the baseline is 3. The description adds no parameter-specific information beyond what is already 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 uses the specific verb 'Create' and clearly identifies the resource as 'a new user in Zabbix', distinguishing it from sibling tools like zabbix_update_user, zabbix_delete_users, and zabbix_get_users.

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, nor any prerequisites such as ensuring user groups already exist.

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 mentions 'create' implying a mutation, but does not disclose any side effects, failure conditions, duplicate handling, required permissions, or return values. This is a significant transparency 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 a single, concise sentence that immediately communicates the tool's purpose without any filler. It is front-loaded and every word earns its place.

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

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

This is a simple create tool with a well-documented schema and no output schema. The description is adequate for understanding the basic purpose, but it lacks contextual details such as typical usage scenarios, edge cases, or behavioral notes. While the schema covers parameters, the description alone does not fully equip an agent to understand the operation's implications.

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 description coverage is 100%, with each parameter having a clear description (e.g., 'Name of the user group', 'Permissions of the user group'). The tool description adds no parameter information, but the schema already provides complete semantics, so a baseline of 3 is appropriate.

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

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

The description clearly states the action (create) and the resource (new user group in Zabbix), making it distinct from sibling tools like zabbix_get_usergroups, zabbix_create_user, and others. It leaves no ambiguity 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?

There is no guidance about when to use this tool versus alternatives, no prerequisites, no mention of how it relates to updating user groups, and no context about typical usage scenarios. The description only states the action without any usage 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. It merely states a create operation without revealing side effects, permission requirements, idempotency, or behavior on duplicate names. The description does not mention the hostid parameter's global vs per-host behavior, which is important for a create 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, grammatically correct sentence. It is front-loaded with the action and resource, contains no fluff, and every word adds 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?

For a simple create tool with a fully described schema, the description suffices. It does not explain return values (no output schema), but that is not critical for a create operation. The omission of potential use cases (e.g., mapping items) is minor.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides, and that is acceptable here since the schema is thorough.

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 ('Create') and the resource ('value map'), and specifies the purpose ('mapping numeric values to text'). This distinguishes it from siblings like 'zabbix_create_map' for network maps.

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's use case (creating value maps) but does not explicitly state when to use it over alternatives like 'zabbix_update_value_map' or reference other tools. There is no exclusion criteria or '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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a mutating operation but does not mention irreversibility, required permissions, what happens if action IDs are invalid, or any side effects. For a delete operation, this is a significant gap in 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 a single, focused sentence that immediately conveys the action and resource. It contains no filler or redundant phrasing, making it highly concise and 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 the lack of annotations and output schema, the description is too sparse to be contextually complete. It does not explain the effect of deletion, potential errors, or any behavioral nuances. While the parameter is well-schema'd, the overall context (e.g., irreversibility, permissions) 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?

The input schema has 100% coverage with the parameter description 'Array of action IDs to delete', so the schema fully documents the parameter. The description adds no additional meaning or context about the parameter. Baseline of 3 is appropriate since the schema handles the 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 verb ('Delete') and resource ('actions'), which is a specific Zabbix object type. It distinguishes itself from sibling tools by naming the resource, but it does not elaborate on what 'actions' are or the exact scope, so it is clear but not fully differentiated from other delete 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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when it is appropriate to delete actions, or any exclusions. The only implied usage is that it deletes actions, but there is no explicit context or comparison to create/update actions.

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 full burden. It only states 'Delete event correlations' without disclosing the permanence, side effects on dependent objects, required permissions, or error behavior. A delete operation's destructive nature is implied but not explicitly stated.

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 no unnecessary words. It front-loads the action and resource efficiently.

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 mutation tool with no annotations and no output schema, this description is too sparse. It omits any warning about irreversibility, what happens to dependent correlations, or expected return behavior, leaving the agent under-informed.

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 full coverage (100%) with a description for 'correlationids', so the baseline is 3. The description adds no extra detail about parameter formatting or semantics 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 clearly identifies the action (delete) and resource (event correlations) with specificity, distinguishing it from sibling get/create/update correlation tools. Although it mirrors the tool name, it adds 'event' to clarify the resource type.

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 delete tool versus alternatives. No mention of cleanup scenarios, prerequisites, or contrast with other delete tools. The description simply states the action.

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 must carry the burden of behavioral disclosure. It only restates the delete action without detailing permanence, cascading effects, permissions, or idempotency. The description offers no additional context beyond the tool's 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?

The description is a single, concise sentence that fully conveys the core purpose without unnecessary words or repetition. It is appropriately sized for a simple delete operation.

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

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

For a one-parameter delete tool, the description and schema provide the minimum viable information. However, the lack of behavioral context (e.g., irreversible deletion, impact on related data) and absence of annotations leave gaps. It is adequate but not 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?

The input schema already provides 100% coverage with a clear description for the dashboardids parameter ('Array of dashboard IDs to delete'). The tool description adds no extra semantic value, so the baseline of 3 applies.

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

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

The description states a specific verb ('Delete') and resource ('dashboards from Zabbix'), clearly distinguishing it from sibling tools like zabbix_create_dashboard or zabbix_get_dashboards. It is unambiguous and actionable.

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 vs. alternatives. It does not mention prerequisites, consequences, or situations where another tool (e.g., zabbix_update_dashboard) would be more appropriate. The name implies its use but there's no explicit direction.

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 full burden but adds no behavioral detail beyond the tool name. It does not mention cascading deletions of discovered entities, permission requirements, or irreversibility.

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 that conveys the essential action. No wasted words.

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

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

The description is sufficient for basic invocation but omits important context about side effects and permissions. Given the lack of annotations and output schema, it should provide more operational detail for a mutation 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 input schema fully documents the single `itemids` parameter with a description, and the tool description doesn't provide additional semantic context. Baseline 3 applies.

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

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

The description clearly states the tool deletes Low-Level Discovery (LLD) rules, a specific resource distinct from other delete tools. This makes the purpose unambiguous and differentiates it from sibling deletion 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?

No guidance is provided on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. It relies entirely on the user's inferred intent from the name.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Delete host groups' with no mention of permanence, side effects on associated hosts/templates, permission requirements, or potential failure modes. This is a significant gap for a destructive 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 a single concise sentence with no redundant words. It is appropriately sized for a simple tool, though it could include more context without being verbose. The structure is clean and front-loaded with the action.

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 straightforward but destructive, with no annotations and no output schema. The description fails to explain important context such as consequences, required permissions, or interaction with other resources (e.g., hosts linked to a group). It is minimal and inadequate for an agent to safely invoke 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?

The input schema provides 100% coverage with a clear description for groupids ('Array of host group IDs to delete'). The tool description adds no additional parameter semantics, but since the schema already covers all parameters, the baseline of 3 applies.

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

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

The description clearly states the action 'Delete' and the resource 'host groups' with the target system 'Zabbix'. It is specific and distinguishes from siblings such as zabbix_create_hostgroup, zabbix_update_hostgroup, and zabbix_get_hostgroups.

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, such as when to use update instead of delete, or any prerequisites like checking for dependencies. The description only offers the basic purpose without 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 present, so the description must carry the full burden. It does not disclose consequences of deletion such as irreversibility, permission requirements, or side effects on dependent objects. The description adds minimal behavioral context beyond the verb 'Delete'.

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 unnecessary words. It efficiently conveys the tool's purpose without any 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?

As a mutation tool with no annotations or output schema, the description is minimal but covers the basic action. It lacks important operational context such as irreversibility or usage prerequisites, making it adequate yet incomplete for a delete operation.

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

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

The schema provides 100% coverage for the single parameter 'iconmapids', including its description, so the baseline is 3. The description text adds no additional meaning or context for the parameter beyond what the schema already specifies.

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 the specific verb 'Delete' and the resource 'icon maps', clearly distinguishing it from sibling tools like zabbix_get_icon_maps, zabbix_create_icon_map, and zabbix_update_icon_map. It unambiguously states 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?

No guidance is provided on when to use this tool versus alternatives. It simply states the action without mentioning prerequisites, conditions, or context in which deletion should occur.

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 merely states 'Delete' without disclosing that deletion is permanent, whether it cascades to associated data, or any auth requirements. This is insufficient for a destructive 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 a single concise sentence that front-loads the action. There is no wasted text or unnecessary detail, making it perfectly efficient for a simple tool.

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

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

For a simple deletion tool with one parameter, the description conveys the core purpose. However, it lacks context about irreversible effects, usage scenarios, and potential side effects, leaving the agent with unanswered questions for a destructive action.

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 describes the single parameter 'itemids' as 'Array of item IDs to delete' with 100% coverage. The tool description adds no extra meaning beyond the schema, so baseline 3 applies.

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

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

The description 'Delete items from Zabbix' uses a specific verb and resource, clearly distinguishing it from sibling deletion tools like zabbix_delete_triggers or zabbix_delete_templates. It leaves no ambiguity about the tool's function.

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, no prerequisites, and no exclusions. It does not mention any context like needing to unlink templates first or when deletion is appropriate.

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 states the deletion action and does not mention irreversibility, required permissions, or any side effects on active maintenance windows.

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, 'Delete maintenance periods from Zabbix', with no redundant words. It is appropriately front-loaded with the verb and object.

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 tool with one fully documented parameter, the description plus schema is functionally sufficient for basic invocation. However, with no annotations or output schema, it lacks important context about the destructive nature and potential operational impact.

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 covers 100% of parameter semantics, with 'maintenanceids' clearly described as an array of maintenance period IDs to delete. The tool description adds no additional parameter-related 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 uses the specific verb 'Delete' and names the resource 'maintenance periods from Zabbix', clearly stating what the tool does. It also distinguishes itself from sibling tools like create/update/get maintenance by indicating the delete operation uniquely.

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 when maintenance periods need to be removed, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites. There is no guidance about listing IDs first via get_maintenance or considering update_maintenance for edits.

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 disclosing behavioral traits. 'Delete network maps' implies a destructive action, but it does not state whether deletion is permanent, whether it can be undone, or if it has cascading effects on related entities. This lack of detail leaves the agent under-informed about the impact of invoking the 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, well-structured sentence that is appropriately sized for a simple delete operation. It front-loads the action and object, with no filler words. However, because it omits crucial behavioral context, it is concise at the expense of completeness, so it does not earn 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?

Given the tool's simplicity (one parameter, no output schema), the core purpose is adequately conveyed by the description and schema. However, the absence of any warning about the destructive nature or irreversible effects makes the description incomplete for an operation of this type. A minimal viable description would include at least a note that deletion is permanent.

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

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

The input schema provides a complete description for the single parameter (sysmapids: 'Array of network map IDs to delete'), giving 100% schema coverage. The tool description adds no additional parameter semantics, but the baseline of 3 applies when the schema already covers the parameter meaning.

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

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

The description clearly states the tool's function with a specific verb ('delete') and resource ('network maps'), distinguishing it from sibling tools that delete other entities like users or hostgroups. It is concise and unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, edge cases, or how this relates to other map-related tools like zabbix_update_map or zabbix_get_maps. The description solely states the action without contextualizing usage.

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 the action ('delete') without revealing that this is a destructive, likely irreversible operation, nor any prerequisites or cascading effects. This is a significant gap for a deletion 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 that conveys the tool's core purpose without unnecessary words. It is appropriately sized for the tool's simplicity.

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 tool with one well-documented parameter, the description and schema together provide enough information for an agent to select and invoke the tool correctly. It lacks behavioral warnings, but the operation itself is clear and complete given the simplicity.

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 already provides a full description for the sole parameter ('Array of media type IDs to delete'), and schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description states 'Delete media types from Zabbix' with a specific verb (delete) and resource (media types), clearly distinguishing it from sibling tools that create, update, or get media types. It is unambiguous and immediately understandable.

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 tool is used when media types need to be removed. The resource is specified, making the context clear, though it does not explicitly mention alternatives like update_media_type for modifications or get_media_type for listing.

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 disclosing behavioral traits. It simply restates the tool name and does not reveal that deletion is irreversible, what impact it has on associated objects, or any permission requirements. This is a destructive operation with zero additional 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, short sentence that is easy to read but simply repeats the tool name with 'from Zabbix'. It is concise in length but does not earn its place by adding new information beyond the name. It is not overly verbose, so it avoids a lower score, but it offers minimal 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?

The tool is a deletion operation with no output schema and no annotations. The description fails to provide essential context such as the irreversible nature, side effects on hosts or other configurations, or any validation requirements. For a destructive tool of this complexity, the one-line description is inadequate.

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

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

The input schema provides 100% coverage for the only parameter, 'proxyids', with a clear description: 'Array of proxy IDs to delete'. The description text adds no extra parameter semantics, but since the schema is well-documented, the baseline of 3 is appropriate.

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

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

The description 'Delete proxies from Zabbix' clearly states the action (delete) and the resource (proxies), distinguishing it from sibling tools like zabbix_get_proxies, zabbix_create_proxy, and zabbix_update_proxy. It is a specific verb+resource that leaves no 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 gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, cautionary cases, or explicit exclusions, such as not using it if proxies are still referenced by hosts. There is no context about when deletion is appropriate.

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 to indicate safety profile, and the description does not disclose behavioral traits such as irreversibility, potential impacts on running script executions, or permission requirements. For a delete operation, this lack of transparency 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, clear sentence that front-loads the action and resource. It contains no fluff and is appropriately sized for the simple functionality.

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 that this is a destructive operation with no annotations and no output schema, the description is incomplete. It fails to mention that deletion is permanent, lacks usage guidance, and does not describe any response or error conditions, leaving the agent without essential context for safe 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 input schema provides 100% coverage with the description 'Array of script IDs to delete' for the scriptids parameter. The tool description adds no further meaning, but the schema already sufficiently documents the parameter, so a baseline score of 3 is appropriate.

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

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

The description 'Delete scripts from Zabbix' uses a specific verb and resource, clearly indicating the action. It distinguishes itself from sibling tools like zabbix_get_scripts, zabbix_create_script, and zabbix_update_script by focusing solely on deletion.

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, nor are any prerequisites or caveats mentioned (e.g., scripts in use cannot be deleted, deletion is permanent). The description lacks any context about appropriate usage scenarios.

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

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

The description merely restates the mutation ('Delete') without any additional behavioral disclosure. There are no annotations to fall back on, so the description should explain irreversibility, cascading deletions, permissions, or error behavior, but it does not.

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

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

A single short sentence that states the operation without verbosity or filler. It is front-loaded and easy to parse.

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

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

Given the tool's simplicity (one array parameter, no output schema), the description is minimally sufficient to select and invoke the tool, but it omits consequences of deletion and expected return state. Compared to well-documented alternatives, it lacks important situational context but is not severely incomplete due to the complete 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?

The input schema fully documents the single 'serviceids' parameter with a description, so the tool description adds no extra semantic value. Since schema coverage is 100%, the baseline of 3 applies; there is no need for the description to elaborate.

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 'Delete business services from Zabbix' uses a specific verb and resource, clearly distinguishing it from sibling delete tools like zabbix_delete_users or zabbix_delete_templates by naming 'business services' specifically.

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 like zabbix_create_service or zabbix_update_service. The description does not state prerequisites, whether deletion is permanent, or how to handle dependencies. This is a minimal statement with no contextual usage guidance.

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

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

With no annotations, the description must disclose behavioral traits. It conveys that the tool deletes templates but omits critical details such as irreversibility, cascading effects on linked hosts or dependent items, required permissions, or error behavior. This is a significant gap for a destructive 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 one sentence and thus highly concise and front-loaded. However, it essentially restates the tool name, providing no extra information beyond what the name already conveys, so it does not add value commensurate with its brevity.

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 inadequate for a destructive tool with no annotations and no output schema. It fails to explain the consequences of deletion, whether templates must be unlinked first, or what becomes of associated entities, leaving the agent with incomplete information to reason about tool 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 input schema fully describes the only parameter (templateids) as an array of IDs, so the description adds no additional meaning. According to the rubric, high schema coverage (100%) establishes a baseline of 3, which is appropriate here.

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 (Delete) and the resource (templates), making the tool's purpose unambiguous. It is distinct from sibling tools that delete other entities, though it does not explicitly differentiate from related actions like unlinking templates.

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 (e.g., zabbix_unlink_templates_from_host). The description only states the action without any context about prerequisites, use cases, or conditions that would help an agent choose between this and similar 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?

No annotations are provided, so the description must disclose behavioral traits on its own. While 'Delete' implies a destructive action, it doesn't mention irreversibility, required permissions, or potential side effects on associated data like problems or events. This is a significant gap for a delete 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 succinct and front-loaded, stating the action in one short sentence. It is appropriately concise for a tool with a single parameter, though it could benefit from slightly more detail without becoming verbose.

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

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

Given the tool's simplicity (one parameter, no output schema) and the schema's thorough coverage of the parameter, the description is minimally viable. However, it lacks information on return values, error conditions, or the permanent nature of the action, so it falls short of 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?

The input schema already describes the single parameter 'triggerids' as 'Array of trigger IDs to delete', covering 100% of the parameter semantics. The description adds no extra meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description 'Delete triggers from Zabbix' uses a specific verb and resource, making the tool's purpose clear. It is unambiguous and distinguishes from sibling tools that operate on different resources, though it doesn't explicitly mention any scope or alternative 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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions such as whether triggers should be disabled first or if there are dependencies. It merely states the action.

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 transparency. It only states that users are deleted but does not disclose that deletion is likely permanent, whether it requires special permissions, or what the operation returns. 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 a single, concise sentence with no filler words. It is front-loaded with the action, though it could be slightly more informative without becoming verbose.

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 absence of annotations and an output schema, the description should explain return values, side effects, or prerequisites. It does none of these, leaving the agent without enough context to predict the tool's full impact or response.

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 already describes the 'userids' parameter as an array of user IDs to delete, and schema coverage is 100%. The description adds no additional semantic meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb 'Delete' and a clear resource 'users', clearly stating it deletes user accounts. This distinguishes it from sibling tools like zabbix_create_user, zabbix_update_user, and zabbix_get_users, 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 implies usage for removing users from Zabbix but does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites, side effects, or conditions. For a simple delete tool, this is minimally acceptable but lacks 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states only that the tool deletes value maps, but does not disclose that deletion is permanent, whether any authorization is required, or any cascading effects on hosts/items that reference the maps. This is insufficient for a destructive 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 extremely concise and front-loaded with the action verb, containing no fluff. However, it is so minimal that it misses opportunities to include caveats or usage notes, though it is appropriately sized and well-structured for the simple 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?

Despite having a well-documented parameter schema, the description lacks any context about the destructive nature, prerequisites (fetching value map IDs), or side effects. For a delete operation with no output schema or annotations, this is inadequate. The description is not complete enough to allow safe invocation without additional research.

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

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

The schema already provides 100% coverage of the single parameter with a clear description ('Array of value map IDs to delete'). The tool description adds no additional parameter semantics. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

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

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

The description clearly specifies a unique verb-resource pairing ('Delete value maps from Zabbix'), which distinguishes it from sibling deletion tools for other Zabbix resources. There is no ambiguity about what action the tool performs.

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, prerequisites, or alternatives. It does not mention that value map IDs must be obtained first (e.g., via zabbix_get_value_maps), nor does it warn against deleting in-use maps. No usage context is given.

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 disclose behavioral traits. It merely states the action 'Execute a script' without mentioning potential side effects on the host, required permissions, synchronous/asynchronous behavior, or return values. This is a significant gap for a script execution 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 no filler words. It is front-loaded and efficient, earning a high score for conciseness, though its brevity contributes to under-specification 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?

With 4 parameters, no annotations, and no output schema, the description is too minimal. It does not explain the difference between host-context and event-context scripts, what happens after execution, or any side effects, leaving the agent without critical context 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 input schema has 100% description coverage for all four parameters, so the schema already provides parameter semantics. The description itself adds no additional param context, thus the baseline score of 3 applies.

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

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

The description uses the specific verb 'Execute' and clearly identifies the resource as 'a script on a host in Zabbix'. This distinguishes it from sibling tools like zabbix_create_script, zabbix_get_scripts, and zabbix_update_script, 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 implies the tool is for running scripts, but it does not explicitly state when to use it versus alternatives, prerequisites, or exclusions. There is no mention of needing a pre-existing script or permissions, so 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 does not state that the operation is read-only, what the output format entails (e.g., a string response), or any session/authentication requirements.

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. It states the core action and output formats efficiently.

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 a simple description, the tool has a complex options object with 15 entity types. The description does not explain the effect of an empty options object, how to use the options to select specific entities, or what the return value looks like. The schema helps but does not fill the overall contextual gap.

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

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

Schema description coverage is 100%, so the schema already documents the format enum and each sub-property of options. The description adds only the XML/JSON distinction already visible in the schema, offering no additional meaning.

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 uses the specific verb 'Export' and identifies the resource as 'Zabbix configuration' with output formats 'XML or JSON'. This clearly differentiates it from sibling tools like import_configuration.

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 such as zabbix_import_configuration. It does not explain whether an empty options object is valid or if at least one object type must be specified.

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 adds useful context by enumerating categories ('unacknowledged problems, long-running issues, unavailable hosts') and stating prioritization by urgency. However, it does not explicitly confirm read-only status, rate limits, or whether the response aggregates data from multiple endpoints, which would be valuable 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 a single sentence that effectively front-loads the core purpose. Every clause contributes value: it names the resource, specifies the criteria, and notes prioritization. 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?

Given the tool's moderate complexity (nested options object, no required params, no output schema), the description offers a solid overview of what to expect. It would benefit from mentioning the response format or any default limitations, but the current level is sufficient for an agent to operate. The lack of an output schema is partially compensated by the clear scope description.

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

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

Schema description coverage is 100%, with clear descriptions for maxItems and priorityFilter. The description adds minimal meaning beyond the schema; the mention of 'prioritized by urgency' loosely aligns with priorityFilter but does not explain parameter usage. Since the schema already documents parameters well, the baseline 3 is appropriate.

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

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

The description clearly states what the tool does with a specific verb ('Get'), resource ('actionable items'), and defining scope ('requiring immediate human intervention including unacknowledged problems, long-running issues, and unavailable hosts'). It distinguishes itself from sibling tools like zabbix_get_problems or zabbix_get_critical_issues by framing the output as action-oriented and prioritized by urgency.

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 scenarios by specifying the type of items retrieved, but it does not explicitly state when to prefer this tool over alternatives such as zabbix_get_problems or zabbix_get_critical_issues. No exclusion criteria or alternative references are given, leaving the decision somewhat to the agent's 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves actions and that filtering and output options are available, but it does not explicitly state that it is a read-only operation or describe any side effects, default behavior, or limitations. The term 'Get' implies safety, but deeper behavioral context is missing. This is a minimal but non-contradictory 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 a single, front-loaded sentence: 'Get actions from Zabbix with filtering and output options'. Every word is purposeful, with no filler or redundancy. It efficiently conveys the core functionality in just 10 words.

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

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

Despite 17 parameters and no output schema, the description provides no domain context about what a Zabbix 'action' is, how the various filters (hostids, triggerids, etc.) relate, or what the returned data structure looks like. The schema offers detailed parameter descriptions, but the description itself is too sparse to make the tool self-contained for an agent unfamiliar with Zabbix actions. It reads more like a label than a complete tool explanation.

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

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

Schema description coverage is 100%, so all 17 parameters are individually documented. The description's phrase 'with filtering and output options' adds a high-level summary but no parameter-specific semantics beyond what the schema already provides. It neither enriches nor detracts from the schema, meriting the baseline score of 3.

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

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

The description clearly states 'Get actions from Zabbix', identifying the verb (Get), resource (actions), and platform. It does not explicitly differentiate from sibling tools like zabbix_create_action or zabbix_update_action, but the verb alone makes the read-only purpose apparent, so it meets the 'clear but no sibling differentiation' criterion.

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, no prerequisites, and no exclusions. It merely states what it does. There is no mention that this tool is for listing/inspecting actions rather than modifying them, leaving the agent to infer usage from the verb 'Get' and the tool name.

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