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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about what actions are but does not disclose any additional behavioral traits such as response format, pagination behavior, or permission requirements. With strong annotation coverage, a 3 is appropriate.

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 only two sentences, with the core purpose front-loaded and the explanatory context kept minimal. Every word earns its place; no fluff or redundancy.

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

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

Given the high schema coverage, the presence of an output schema, and robust annotations, the description is sufficient for a read-only list tool. It lacks only minor enhancements like mentioning pagination behavior, but the schema already covers that, so nothing essential is missing.

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

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

Schema description coverage is 91%, so the input schema already documents all parameters in detail (limit, offset, output, search, hostids, etc.). The tool description adds no parameter-specific information, and the baseline of 3 applies because the schema carries the burden.

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

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

The description clearly states the verb 'Get' and the resource 'actions from Zabbix', and provides a concise explanation of what actions are (automated responses to problems). This makes it immediately distinguishable from sibling get tools like host_get or trigger_get.

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 the user needs to retrieve actions, but offers no explicit guidance on when to choose this tool over alternatives (e.g., when to use event_get vs action_get). It does not state exclusions or mention specific scenarios that would favor sibling tools.

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

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

The annotations already define this as read-only, idempotent, and non-destructive. The description adds the return contract—a dict with a 'version' key and an example value—which the annotations don't convey. No conflicting behaviors are indicated.

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

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

The description is short and structured, with a returns section for clarity. However, the first two sentences essentially repeat the same idea—'Get Zabbix API version information' and 'This tool retrieves the current version...'—creating minor redundancy that prevents a top score.

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

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

The tool is a simple, zero-parameter read-only operation, and the description covers what it does, why to use it, and what it returns. Nothing needed to invoke it correctly or understand its output 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?

There are zero parameters, so the baseline for parameter semantics is 4. The description adds no parameter details because none exist, and the schema already fully captures the empty parameter set.

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

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

The description opens with 'Get Zabbix API version information' and then clarifies its purpose as retrieving the current API version. It is specific about the verb 'get' and the resource 'Zabbix API version', and no sibling tool overlaps with this purpose.

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

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

The description states when this is valuable: 'useful for understanding API capabilities and ensuring compatibility with specific features that may be version-dependent.' It doesn't explicitly name alternatives or exclusions, but none of the sibling tools serve this purpose, so the guidance is sufficient.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context about the contents of the export (items, triggers, etc.) without contradicting annotations.

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

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

The description is well-structured with a brief introductory sentence followed by a bulleted list of included elements. It is moderately concise and front-loads the core purpose.

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

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

Given the presence of output schema (which details return format) and comprehensive annotations, the description is sufficiently complete. It explains the scope of export (what is included) which is essential for a complex export tool.

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

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

Schema description coverage is 100%. The description reiterates that hostids and templateids are for selecting hosts/templates but does not add significant new 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 clearly states it exports Zabbix configurations (verb 'export', resource 'configurations'), lists what is included, and distinguishes from sibling tools like configuration_import.

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

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

The description explicitly mentions use cases: backup, migration, disaster recovery, or sharing configurations. It does not mention when not to use or alternatives, but the context is clear and sibling tools provide contrast.

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

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

The annotations already indicate the tool is not read-only, but the description adds no further behavioral disclosure. It does not warn that importing can overwrite existing objects or delete missing ones when configured, which is important for a bulk import 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 brief, front-loaded, and free of filler. Every sentence contributes either the operation, the scope, or the intended use cases.

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 recognizing the tool, but it omits important behavioral context such as the ability to update existing objects or delete absent ones. The output schema covers return values, so the main gap is around side effects and destructive potential.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds mild context by naming hosts/templates and JSON/XML/YAML, but it does not explain rules or delete_missing behavior beyond what the schema provides.

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 operation as importing configurations into Zabbix and specifies resource types such as hosts and templates. It is easy to distinguish from export and individual CRUD tools, though it does not explicitly name or contrast any sibling tool.

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

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

The description provides concrete use cases: migration, cloning, and restoring configurations. It does not mention when not to use the tool or explicitly recommend alternatives like configuration_export or individual create/update 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?

The annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the operation's safety profile is known. The description adds conceptual background but does not disclose additional behavioral details such as pagination behavior, count mode, or filtering side effects. There is no contradiction with the annotations.

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

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

The primary purpose sentence is front-loaded and immediately tells an agent what the tool does. The two followup sentences are concise and briefly explain why these rules matter, without unnecessary verbosity. Still, it is not a fully crafted operational definition because it omits sibling differentiation.

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?

Considering the tool has 11 parameters, no required fields, and an output schema, the description is adequate but not comprehensive. It explains the domain and type of the return, but it does not provide guidance on common usage patterns, such as selecting by hostid or templateid, or calling out the potential confusion with related rules. An agent can likely proceed, but some context is left to the schema and judgment.

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 detailed descriptions for nearly all 11 parameters, covering about 91% of them with documentation for limit, offset, search, hostids, itemids, sortField, etc. The description itself does not need to repeat parameter-level information because the schema already 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 starts with a clear verb and object: 'Get discovery rules from Zabbix.' The following sentences provide relevant background on what discovery rules are, but the description does not distinguish this tool from similarly named siblings like drule_get or itemprototype_get, so it stops short of full clarity.

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

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

The description does not explicitly say when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The background about dynamic host and item management gives domain context, but an agent would not know when to choose this tool over the many other retrieval and discovery-related sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds background about what network discovery rules do, but does not disclose additional tool-specific behaviors such as pagination details, permission requirements, or rate limits. The added context is useful but not deeply behavioral.

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 definition is concise and front-loaded with the main purpose. The two background sentences explain the domain, though the second sentence partially repeats the first ('perform network scanning' vs 'scan for active devices...'). Minor redundancy keeps it from a 5, but there is no fluff.

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 a rich output schema, strong annotations, and high schema parameter coverage, the description is nearly complete for a read-only fetch tool. It provides enough domain context to clarify what 'drule' means, though it could be more explicit about when to reach for this instead of discoveryrule_get. The remaining gaps are 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?

The input schema has 89% description coverage, so most parameters already carry sufficient semantics. The tool description adds no per-parameter information beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting for parameter understanding.

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

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

The description begins with a specific verb and resource: 'Get network discovery rules from Zabbix.' It clearly distinguishes this from related sibling tools like discoveryrule_get by explicitly naming the resource type as 'network discovery (drule) rules' and explaining their scanning purpose.

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

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

The description implies usage by defining what network discovery rules are, but it does not explicitly state when to choose this tool over alternatives such as discoveryrule_get or host_get. No exclusionary guidance is provided, so an agent must infer the context from the resource description alone.

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 discloses that events can be closed if resolved, aligning with the destructiveHint annotation. It also provides context about the purpose (awareness/working on issue) that goes beyond the basic annotations, but does not list potential side effects or error conditions.

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

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

The description is concise, consisting of two sentences that front-load the main action and provide relevant details. It is well-structured and free of unnecessary fluff.

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

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

The description is complete for understanding the tool's purpose and primary behavior. Since an output schema exists, it does not need to explain return values. It covers the key action and the optional closing behavior, though it omits explicit error handling or prerequisites.

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 all parameters (action, message, eventids) with 100% coverage. The tool description adds no additional parameter semantics beyond what the schema provides, 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 clearly states the tool's purpose: to acknowledge events in Zabbix, with a specific action (acknowledge) and resource (events). It also mentions the ability to close resolved events, providing full intent.

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 explains the situational context (showing staff awareness and working on issues) and the effect (closing if resolved), which implies when to use it. However, it does not explicitly contrast with related tools like event_get or problem_get, leaving some inference needed.

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

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

Annotations already cover the read-only, idempotent, and non-destructive nature of the tool, so the description does not need to repeat that. The description adds domain context (events are state changes, can be acknowledged) but does not disclose additional behavioral traits like pagination behavior or default sorting beyond what the schema already documents.

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

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

The description is concise, starting with the core action and then adding a compact explanation of events. Each sentence adds relevant context without excessive verbosity, and the structure is logical (action first, then background).

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 high parameter schema coverage and the presence of an output schema, the description is sufficient to understand the tool's domain and purpose. It explains what an event is, which is essential for an agent to decide when to use it. The only minor gap is the lack of explicit mention of pagination, but the offset parameter description already covers that.

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 high (94%), so the parameters are well-documented in the input schema. The description provides general context about events that helps interpret parameters like objectids (trigger IDs) and time filters, but it does not add specific parameter-level semantics beyond what the schema already offers.

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 core action 'Get events from Zabbix' and elaborates on what events represent (state changes, trigger transitions, acknowledgments). It is specific about the resource but does not explicitly differentiate from sibling tools like problem_get or history_get, though the name and context make the purpose clear.

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. The description explains the concept of events but does not mention scenarios where event_get is preferable to problem_get, history_get, or trend_get. There is no discussion of trade-offs or selection criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe retrieval nature is captured. The description's 'Get graphs' is consistent with those annotations but adds no further behavioral context beyond what annotations and the input schema already provide.

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 core instruction 'Get graphs from Zabbix' is front-loaded and clear. However, the two sentences about dashboards, reports, and custom views are conceptual filler that do not materially help an agent select or invoke the tool correctly.

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 rich input schema with all optional parameters and an existing output schema, the tool is sufficiently documented for correct invocation. The description could be more complete by naming sibling tools, but the structured metadata carries the remaining load.

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 about 93%, and the input schema already documents most parameter semantics, including limit, offset, search, hostids, graphids, sortfield, select_hosts, select_items, and select_templates. The description adds no additional parameter explanation, 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?

Opens with 'Get graphs from Zabbix' - a specific verb and resource that clearly distinguishes graph_get from the many sibling *_get tools. The additional context about graphs visualizing item data over time further clarifies the resource domain.

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 useful background ('Graphs visualize item data over time') but never explains when an agent should use graph_get versus alternative tools like item_get or history_get. There is no when-not guidance or explicit alternative routing.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly does not contradict them. The description adds conceptual context about the nature of history data (raw values, timestamps) but does not disclose additional behavioral aspects like performance implications or permission requirements beyond what annotations provide. This is adequate given the annotation coverage.

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

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

The description is two sentences, front-loaded with the core purpose ('Get history data from Zabbix') followed by an explanatory sentence. It is concise and free of redundancy, though the phrase 'allowing detailed analysis of system behavior over time' is somewhat generic and could be trimmed without losing value.

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

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

Given the tool's complexity (8 parameters, required itemids) and the presence of a documented output schema, the description provides a sufficient high-level understanding. It does not explicitly mention prerequisites like time filters or default limits, but those are covered in the parameter schema. The description is complete enough for an agent to know what to expect and when to invoke it.

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

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

Schema description coverage is 100%, with each parameter having a clear description in the input schema. The tool description itself does not describe parameters, but per the rubric, a high coverage baseline of 3 is appropriate. The description's mention of 'timestamps' and 'individual data points' hints at the time and limit parameters but does not add specific syntactic or semantic detail beyond the schema.

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

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

The description clearly states the verb 'Get' and the resource 'history data from Zabbix', and distinguishes it from related tools like trend_get by specifying 'raw metric values' and 'individual collected data points with timestamps'. This makes the tool's purpose unambiguous and differentiates it from siblings.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as trend_get, event_get, or item_get. It implies the tool is for raw history data, but it does not state when to prefer it over trends or how to combine it with other tools. An agent would have to infer usage from the description alone, which is insufficient.

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 indicates this is a mutating operation (creates a host) but provides no details on idempotency, failure behavior (e.g., if a host already exists), or the response format. With annotations showing no hints, the description carries the burden but only discloses the basic 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 concise and well-structured, using short sentences to convey essential information without unnecessary verbosity. It efficiently states the purpose, required fields, and optional configurations, making it 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 that an output schema exists, the description appropriately avoids explaining return values. It covers the key aspects for usage, including required and optional parameters. It does not address edge cases or error handling, but for a create operation, this level of completeness is adequate.

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

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

All 8 parameters have descriptions in the schema, covering their meaning and examples (e.g., status as 0=enabled, 1=disabled). The 'params' field is clearly explained as a catch-all for fields not covered by the individual arguments, ensuring comprehensive understanding of parameter usage.

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 as creating a new host in Zabbix, with specific details about required fields (host name and groups) and optional configurations. It distinguishes itself from sibling tools like host_update by its explicit focus on creation, making its purpose unambiguous.

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

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

The description provides practical guidance on when to use this tool (when starting to monitor a new server or device) and what is required (at least a host name and groups). However, it does not explicitly contrast with host_update or host_delete, leaving some room for interpretation, though the 'create' semantics are clear.

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

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

The description explicitly states that the operation is destructive and 'will delete all associated data including history and alerts.' This goes beyond the provided annotations (destructiveHint=true) by detailing the irreversible nature and the extent of data loss, which is crucial for an agent to warn users or confirm before invocation.

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

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

The description is concise yet comprehensive, covering the action, scope, consequences, and a warning. It is well-structured with a clear first sentence and supporting detail, without unnecessary verbosity.

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

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

For a destructive tool with no other annotations beyond destructiveHint, the description adequately warns about data loss. However, it does not mention prerequisites (e.g., permissions) or what the response contains (though an output schema exists). It's solid but could add guidance on required access levels or clarification that deletion is immediate and irreversible.

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 fully documents the single parameter 'hostids' with a proper description ('List of host IDs to delete'). The tool description expands on the effect of this parameter by explaining that it permanently removes the specified hosts justifications, providing sufficient context for correct parameter usage.

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 hosts from Zabbix.' It specifies the target resource (hosts) and the operation (delete), which distinguishes it from sibling tools like host_get, host_create, and host_update. The description also notes that it removes one or more hosts, matching the parameter 'hostids' that accepts a list.

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

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

The description says it 'permanently removes one or more hosts from Zabbix' and warns 'Use with caution as this is a destructive operation.' This implies it should be used when permanent removal is intended, but it does not explicitly state when to use it over other deletion tools (e.g., item_delete) or provide exclusions. Sibling tools have distinct purposes, but the description alone doesn't guide selection beyond the resource name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds minor context (list of hosts, filtering) but does not disclose pagination behavior, response shape, or any performance implications. With annotations covering the core safety profile, this is acceptable but not rich.

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

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

The description is concise, with the main action in the first sentence and supporting detail in the second. It is front-loaded, free of fluff, and every sentence contributes to understanding. It does not repeat schema information unnecessarily.

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 18 parameters and a fully documented schema, the description covers the core functionality and typical use case. It does not explain every parameter (which the schema already does) but provides enough context for an agent to decide when to invoke the tool. The missing pagination detail is present in the offset parameter 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?

The input schema provides 100% parameter coverage with detailed descriptions for all 18 parameters. The tool description merely lists the filter categories (IDs, groups, templates, proxies, search) without adding new meaning beyond the schema. Since schema coverage is high, the baseline 3 applies.

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

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

The description clearly states a specific verb ('Get') and resource ('hosts from Zabbix'), and explicitly mentions optional filtering by various criteria. This distinguishes it from sibling tools like hostgroup_get or template_get, which target different resources. The purpose is unambiguous.

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

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

The description implies when to use it ('useful for discovering which hosts are available'), but does not explicitly contrast it with sibling getter tools or state when not to use it. The agent could benefit from a note like 'to filter by host groups, use hostgroup_get instead.' No exclusion or alternative 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?

Annotations declare readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds that host groups are containers and their purpose, but does not elaborate on behavioral traits like idempotency (annotation idempotentHint=false), required permissions, or potential side effects beyond creation. The description's value is moderate given annotation coverage.

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

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

The description is two sentences long, front-loaded with the primary action. Every sentence adds value: the first defines the operation, the second provides conceptual context. 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?

Given the tool's simplicity (one required parameter, output schema exists), the description adequately explains the purpose and role of host groups. It lacks explicit usage guidelines but is otherwise complete for a straightforward creation 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 covers 100% of parameters (only 'name') with a description 'Name of the host group.' The tool description does not add extra semantic detail about the parameter beyond what the schema provides. Baseline 3 is appropriate due to full 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: 'Create a new host group in Zabbix.' It distinguishes from sibling tools (e.g., hostgroup_delete, hostgroup_get, hostgroup_update) by focusing on creation. The additional explanation of host groups as containers adds context without ambiguity.

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

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

The description explains when host groups are useful (for permissions, templates, maintenance) but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. No direct comparison with sibling tools, leaving usage context implied rather than explicit.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds meaningful behavioral detail beyond those annotations by stating the deletion is permanent and by clarifying the precise side effect on hosts: they cease to be group members but are not themselves removed unless explicitly deleted. This is valuable context 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 compact: two sentences, no filler. The primary action is front-loaded, and the second sentence adds the important side-effect clarification. Every sentence earns its place.

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

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

For a simple one-parameter destructive tool, the description is complete: it names the resource, states permanence, explains what happens to hosts, and is supported by a fully described input schema, an output schema, and annotations covering mutability and destructiveness. Nothing essential for deciding to call the tool 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 schema has 100% description coverage: 'groupids' is already described as 'Group IDs to delete,' with minItems: 1 confirming that one or more IDs can be supplied. The description generally reinforces that idea but adds little new meaning about the parameter format, source, or behavior beyond what the schema already states.

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

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

The description opens with a specific verb and resource: 'Delete host groups from Zabbix.' It further clarifies the exact scope of the operation: 'Permanently removes one or more host groups,' and distinguishes the effect from deleting hosts by explaining that hosts remain unless explicitly deleted. This is enough to separate it from sibling tools like host_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 explains what the tool does but does not state when to prefer it over alternatives or explicitly name the sibling to use when hosts also need to be removed. It hints that hosts remain unless explicitly deleted, which implies a separate deletion path, but it never says 'use host_delete for that purpose.' No exclusions or selection criteria are provided.

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

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

The annotations already characterize the tool as read-only, idempotent, and non-destructive, and the description aligns with that by saying it 'retrieves' host groups. The description adds a generic 'optional filtering' trait and domain context, but does not disclose details like pagination behavior or response shape. No contradiction exists, but the behavioral transparency is mostly carried by the annotations.

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

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

The description is short, front-loaded with the core action, and quickly communicates the main behavior. There is minor redundancy between 'Get host groups from Zabbix' and 'Retrieves host groups with optional filtering,' but the sentence adds the filtering scope, and the third sentence gives useful domain context. Overall, it stays concise and digestible.

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 a list-oriented read tool when combined with rich annotations, a fully documented parameter schema, and an output schema. It explains why host groups matter in Zabbix and notes optional filtering, which is enough context for an agent to understand the operation. It lacks explicit sibling routing, but that gap is already captured in the usage-guidelines dimension.

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

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

Schema description coverage is 100%, so every parameter is already documented with meaningful descriptions. The tool description only says 'optional filtering' without referencing specific parameters like limit, search, or groupids, so it adds little semantic value beyond the schema. A baseline score of 3 is appropriate because the schema carries the parameter explanation burden.

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

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

The description clearly states a specific verb and resource: it retrieves host groups from Zabbix. It also adds that the retrieval supports optional filtering, which clarifies the scope of the operation. This makes the tool easy to distinguish from mutation tools like hostgroup_create, hostgroup_update, and hostgroup_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?

Usage is implied by the description: an agent should call this tool when it needs host groups, especially for organizing or managing Zabbix hosts collectively. However, no explicit alternatives or when-not-to-use guidance is provided, so the agent gets only weak support in choosing this over sibling tools like host_get or hostgroup_update.

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

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

Annotations provide no hints (readOnlyHint, idempotentHint, destructiveHint are all false), so the description must carry the burden. It states 'Update' and 'Modifies properties' implying state change, but does not disclose potential side effects, idempotency, or prerequisites like authentication.

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

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

The description is concise with three short sentences, no redundant information, and the first sentence immediately states the core purpose.

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

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

Given the tool's simplicity (2 parameters) and presence of an output schema, the description provides the essential information. However, it lacks mention of preconditions (e.g., group must exist) or error conditions.

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

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

Schema coverage is 100% so parameters are already described. The description adds value by reinforcing that only the 'name' field can be changed and that partial updates are supported ('Only specify the fields you want to change').

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 updates an existing host group, specifying the verb 'Update' and resource 'host group', which distinguishes it from sibling tools like hostgroup_create, hostgroup_delete, and hostgroup_get.

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 modifying an existing host group and emphasizes only specifying fields to change, but does not explicitly mention when not to use it or name alternatives.

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

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

Annotations already indicate it's a write operation (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). The description adds that it 'modifies properties' and supports partial updates, which is consistent but not extensive beyond annotations.

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

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

Three sentences: purpose, list of modifiable fields, and usage tip. No redundant information, every sentence 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 update tool with full schema coverage and an output schema (not shown but known), the description covers the operation's purpose, input semantics, and usage pattern completely.

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

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

Schema coverage is 100% with descriptive parameter names and descriptions. The description adds no new semantics beyond restating the fields and the partial update behavior, so 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 the tool updates an existing host in Zabbix and lists the specific properties modifiable (technical name, visible name, status, description), distinguishing it from sibling tools like host_create or host_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?

Provides a useful guideline: 'Only specify the fields you want to change,' indicating partial updates. While it doesn't explicitly exclude create/delete scenarios, the context from sibling tools makes it clear.

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

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

Annotations already indicate this is a mutating, non-idempotent operation, and the description reinforces that by saying 'Create a new item.' It adds useful context about what items represent, but it does not disclose potential side effects, such as duplicate-key behavior or required host relationships, beyond what the schema 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 short and front-loaded with the primary action. The supporting sentences about item semantics are useful but somewhat generic; they could be tighter, yet they do not add significant bloat.

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 rich input schema and annotations, the description provides enough baseline context to understand the tool's purpose. However, it misses practical guidance such as when interfaceid is required or how this relates to host_create/host_get, so completeness is adequate but not strong.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description offers a high-level conceptual mapping to the metric name, collection method, interval, and data type, but it does not add meaningful detail beyond the schema itself.

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

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

The description opens with 'Create a new item in Zabbix,' giving a specific verb and resource. It clearly differentiates this tool from the sibling item_get, item_update, and item_delete tools by establishing creation as the action.

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 explains what items are conceptually but does not state when to prefer item_create over the many related siblings. It provides no explicit when-to-use guidance, no alternatives, and no preconditions such as 'requires an existing host.'

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

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

Annotations already flag this as destructive and non-idempotent. The description adds useful behavioral context by stating that deletion is permanent and that historical data removal 'typically' happens but depends on Zabbix configuration, which extends beyond the annotation values.

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

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

Two concise, front-loaded sentences. The first gives the primary action and target; the second adds an important consequence about historical data. No filler or redundant restatement of the schema.

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

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

For a simple single-parameter tool with a destructive annotation and an output schema, the description covers the core behavior, permanence, and data-history implication. It could more fully discuss failure behavior with invalid item IDs, but the required information for calling it correctly is present.

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

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

The input schema already fully documents itemids as 'Item IDs to delete' with 100% coverage. The description adds little beyond the schema, though it does reinforce that one or more items can be removed, consistent with the minItems:1 constraint.

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

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

The description clearly states the action and resource: 'Delete items from Zabbix' and 'Permanently removes one or more items from monitoring.' It is unambiguous and naturally distinguishes the tool from sibling deletion tools like trigger_delete or maintenance_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 clearly implies this tool is for removing items when deletion is the goal, but it does not state when not to use it, mention softer alternatives like item_update or disabling an item, or reference sibling tools by name. Context is present but exclusion criteria are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about items being data sources but does not disclose behavioral traits like pagination behavior, response structure, or any rate limits. Since annotations carry the safety info, the description doesn't contradict them and adds minimal extra behavioral context.

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

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

The description is three short, well-structured sentences. The core action 'Get items (metrics) from Zabbix' is front-loaded, and the supplementary explanation about items is concise and adds value without padding. 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?

Given the presence of a rich output schema (which explains return values), 17 parameters with individual descriptions, and annotations covering safety, the description is sufficient. It correctly conveys that this is a read-only list operation for item definitions, not historical values. Minor gaps like explicit pagination handling are already covered in the offset parameter description, so nothing critical is missing.

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

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

Schema description coverage is 94% and each parameter (limit, offset, search, hostids, etc.) has a meaningful description in the schema. The tool description itself offers no additional parameter semantics beyond what is already documented, so it neither enhances nor detracts from the schema's clarity. 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 the action 'Get items (metrics) from Zabbix' with a specific resource and adds context about what items are. It distinguishes from item_create/update/delete by being a getter, but doesn't explicitly differentiate from itemprototype_get, so some ambiguity remains.

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 retrieving item metadata but provides no explicit guidance on when to use this tool vs. item_create, item_update, or itemprototype_get. There is no mention of alternatives or exclusion conditions, leaving the agent to infer context from tool names alone.

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

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

The annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already cover the safety profile, so the description only needed to add contextual value — which it does by defining what item prototypes are and how they relate to discovery rules. No contradiction with annotations: 'Get' aligns with readOnlyHint=true and destructiveHint=false. However, no operational behaviors (auth, rate limits, or the has_more/total paging semantics mentioned in the offset param) are disclosed here.

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?

Exactly two sentences with the action verb front-loaded and zero fluff. The second sentence, a parenthetical-style definition of item prototypes, earns its place by disambiguating the domain concept, though one could argue it's conceptually nice-to-have rather than strictly necessary for calling the tool. The structure is appropriately sized relative to the tool's 11-parameter surface area.

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 read-only tool with 0 required parameters, 91% schema coverage, and an output schema handle, the description covers the essentials. The only remaining gap is that the description never explicitly tells an agent when to prefer it over item_get — the sibling it's most easily confused with — but the discovery-rule gloss largely bridges that gap. The output schema covers return-value semantics.

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

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

With 91% schema description coverage, the schema's parameter docs carry the semantic load, and per the rubric the baseline is 3 even without parameter information in the description. The description adds no parameter-level detail, but that's acceptable here — the schema's param descriptions are thorough (e.g., the offset param documents paging behavior with has_more and total). The description correctly avoids duplicating this.

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

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

The description opens with a specific verb-resource pair ('Get item prototypes from Zabbix') that maps directly to the tool name, then adds a sentence explaining that item prototypes are template items created by discovery rules that dynamically generate actual items. This conceptual clarification implicitly differentiates it from siblings like item_get, item_create, and discoveryrule_get by situating the prototype in Zabbix's discovery flow.

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

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

The usage context is only implied through the concept description — an agent must infer that this tool is for template-level items rather than live items. There are no explicit alternatives named, no when-not-to-use guidance, and no mention of when to prefer item_get or discoveryrule_get, despite 54 sibling tools being available. The distinct-from-item-get signal is present but implicit rather than stated.

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

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

Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds that it modifies properties, but lacks additional behavioral details like side effects on monitoring.

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

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

Two sentences: one states purpose, one gives usage guidance. No wasted words, front-loaded with key information.

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

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

For a 6-parameter update tool, the description is sufficiently clear about what it does and how to use it. An output schema exists, so return values are covered.

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

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

Schema coverage is 100%, so baseline 3. The description lists some param examples (name, delay, units, status) but does not add significant 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 clearly states the tool updates an existing item in Zabbix and lists modifiable properties, distinguishing it from siblings like item_create and item_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 advises to specify only fields to change, which is helpful for partial updates. It does not explicitly mention when to use vs alternatives, but the naming provides sufficient 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?

Annotations are minimal (all false), so the description carries the burden of disclosing effects. It explicitly states that a maintenance window suppresses monitoring alerts, which is crucial behavioral information beyond what annotations convey. This directly informs the agent of the side effect on alerting. It stops short of detailing idempotency or failure modes, but the disclosed effect is highly relevant and well-articulated.

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 exceptionally concise, using only two sentences to convey purpose and usage context. Every word earns its place, with no redundant information. It front-loads the core action and immediately explains the practical benefit, making it easy for an agent to quickly parse and decide.

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 presence of an output schema and the straightforward nature of a create operation, the description is nearly complete. It covers the primary effect (alert suppression) and the typical use cases. Missing details like permission requirements or error conditions are not critical for a basic call. The description adequately equips an agent to invoke the tool correctly for standard scenarios.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description itself does not add parameter-specific meaning; however, the schema provides adequate context for each field, including a detailed explanation of the 'timeperiods' parameter and defaults. Since the description does not enhance parameter understanding beyond the schema, a 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 'Create a new maintenance period in Zabbix' with a specific verb and resource. It further differentiates itself from siblings like maintenance_update or maintenance_delete by emphasizing 'new' and explaining the purpose (suppressing alerts during planned upgrades). This unambiguous verb+resource combination distinguishes it from sibling tools without requiring schema inspection.

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

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

The description provides clear context for when to use the tool: 'useful for planned upgrades, patching, or system maintenance without triggering false alarms.' This gives strong guidance on applicability, though it does not explicitly name alternative tools or provide exclusions (e.g., 'use maintenance_update for existing windows'). The context is sufficient for most agents to recognize the intended 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?

Adds value beyond the destructiveHint annotation by specifying that alert generation resumes and historical suppression is retained for already-passed periods. This gives agents a precise mental model of the side effects.

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

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

Two tightly written sentences convey purpose, immediate effect, and a retention nuance without any fluff. Front-loaded with the verb and resource.

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

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

The description covers what happens after deletion (immediate alert resumption) and a critical edge case (historical retention for passed periods). With an output schema present and destructiveHint annotation, no critical information is missing for correct invocation.

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

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

Schema coverage is 100% since the only parameter (maintenanceids) is documented in the schema itself. The description does not add parameter-level meaning beyond what the schema already provides.

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

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

The description starts with

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 explains the effect of deletion (canceling alerts) but doesn't explicitly say when to use vs alternatives. However, the resource and verb make it clear versus maintenance_get/create/update siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not carry the burden of safety. It adds domain background about monitoring pauses but discloses no additional tool-specific behavior such as pagination or default output beyond what the schema already provides.

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

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

The description is two sentences: the first declares purpose, the second provides helpful context. It is crisp, front-loaded, and contains no filler.

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

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

For a read-only tool with zero required parameters, a rich schema, and an output schema present, the description sufficiently conveys purpose and domain. It is complete enough for an agent to select and invoke the tool, though explicit comparison to alternative maintenance tools would elevate it further.

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

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

With 89% schema description coverage, the parameters are already well-documented in the input schema (limit, offset, hostids, etc.). The description adds no parameter-specific information, but it does not need to because the schema handles it.

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

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

The description states the specific verb 'Get' and resource 'maintenance periods' from 'Zabbix', making the purpose immediately clear. The additional sentences define what maintenance windows are, which distinguishes this from sibling maintenance_create/update/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 action verb 'Get' implies this is for read-only retrieval, and the domain context explains maintenance windows, but there is no explicit guidance on when to use this tool versus alternatives. It neither names sibling tools nor specifies a 'when not to use' condition.

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

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

Annotations (readOnlyHint=false, destructiveHint=false) indicate mutation but no destruction. Description adds that properties are modified, but no further behavioral details (e.g., authorization, side effects). The description does not contradict annotations.

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

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

Three short sentences with no extraneous information. Front-loaded with main action, clearly structured.

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

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

Given full schema coverage, output schema existence, and sibling context, the description is complete for an update tool. It covers the purpose, key parameters, and update semantics.

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

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

Schema coverage is 100% with parameter descriptions. The description adds summary of mutable fields and the instruction to only specify changed fields, which provides practical guidance beyond raw 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?

Clearly states the tool 'updates' an 'existing maintenance period' in Zabbix, which is a specific verb-resource pair. Sibling tools like maintenance_create, maintenance_delete, and maintenance_get are distinct, so no confusion.

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

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

Explains that only fields to change need to be specified (patch semantics). While it implies usage context relative to siblings, it does not explicitly state when not to use it or list alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds domain context but no additional behavioral details beyond that. It does not contradict annotations. Since annotations carry the burden, a 3 is appropriate.

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

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

The description is two concise sentences that front-load the purpose and add valuable domain context. No wasted words, every sentence earns its place.

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

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

Given the tool's simplicity (read-only get with no required params), an output schema exists to cover return values, and the description explains what media types are. It provides sufficient context for an agent to call it correctly without further detail.

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 89%, so the schema already documents most parameters. The description adds no parameter-specific details, but with high coverage it doesn't need to. Baseline 3 is correct.

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

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

The description states a specific verb and resource ('Get media types from Zabbix') and adds domain context about what media types are used for (communication channels). It distinguishes from sibling get tools by the resource name, making it unambiguous.

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

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

The description provides clear context that this tool retrieves media types and explains their role in notifications, which implies when an agent should use it. It does not explicitly compare to sibling tools, but the resource is unique so no exclusion is necessary. Clear enough for an agent to select correctly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only domain context, not call-specific behavior such as time-range defaults or response pagination. No contradiction with annotations.

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

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

The first sentence front-loads the core purpose, and the two subsequent sentences add concise, useful domain context. It is well-sized with no redundant 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 rich schema, annotations, and output schema presence, the description is sufficient for basic invocation. The main gap is the lack of usage differentiation from similar read tools such as event_get and trigger_get.

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 high at 94%, so the schema already explains the parameters thoroughly. The description contributes no additional parameter semantics, which is acceptable at this coverage level.

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

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

The description clearly states the operation: get problems from Zabbix. It adds domain context by defining problems as active trigger states, which helps distinguish them from events or triggers, though it does not explicitly name sibling tools.

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

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

There is no explicit guidance on when to use problem_get versus related tools like event_get or trigger_get. The conceptual description implies use for active issue states, but it does not state alternatives or exclusions.

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

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

Annotations provide no hints (readOnlyHint=false, idempotentHint=false). The description only states creation, lacking details on side effects, error conditions, success/failure responses, or authentication requirements. This is insufficient for a mutation tool.

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

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

The description is concise with three sentences: first states the action, then explains the concept, then gives a typical use case. It is front-loaded and free of fluff.

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 few parameters. The description explains the proxy concept and typical use case. An output schema exists (not shown) to cover return values. However, it could mention prerequisites or whether names must be unique.

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

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

Schema coverage is 100%, so all parameters are described in the schema. The description adds no additional meaning beyond the schema's parameter descriptions, meeting the baseline but not exceeding it.

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 'Create a new proxy in Zabbix', specifying the verb and resource uniquely. It differentiates from sibling tools like proxy_delete and proxy_update by focusing on creation.

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 context ('useful for firewall-separated networks') but does not explicitly guide when to use this tool versus alternatives like proxy_update or host_create. There is no mention of when not to use or prerequisites.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description goes further by stating the deletion is permanent, explicitly noting that hosts assigned to deleted proxies need reassignment, and that data is typically retained. This adds valuable behavioral context beyond the annotations without contradiction.

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

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

The description is two short sentences. The first sentence states the action directly, and the second sentence elaborates on the consequences (host reassignment and data retention). Every sentence carries necessary information with no fluff, and it is front-loaded with the primary 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?

For a destructive delete operation with a simple single-parameter input and an existing output schema, the description covers the core behavior, permanence, and side effects. There is no missing critical information that an agent would need to decide to call this tool or interpret its effects. It is complete for the given complexity.

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 proxyids parameter is described as 'Proxy IDs to delete' in the schema. The tool description does not add any extra meaning about the parameter, so it relies entirely on the schema. Per the rubric, baseline 3 is appropriate when the schema fully documents the parameter.

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

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

The description clearly states the verb ('Delete') and the resource ('proxies from Zabbix'), and explicitly notes that it 'Permanently removes proxy definitions'. This distinguishes it from proxy_get (read) and proxy_update (modify), so the purpose is unambiguous.

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

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

The description conveys when to use the tool by describing the permanent removal and the consequential need to reassign hosts, implying that if reassignment is undesirable, alternatives like proxy_update should be considered. However, it does not explicitly name proxy_update or state 'do not use when you intend to modify', so it stops short of explicit routing.

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

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

The annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. However, the description adds no behavior context beyond the annotations, such as return format or side effects. It is neutral and does not contradict the annotations.

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

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

The description is two sentences. The first sentence is the core purpose, but the second sentence explains the concept of proxies, which is background information not essential for usage. While not verbose, the extra sentence is not directly tied to tool usage and could be trimmed for greater front-loading.

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

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

An output schema is present, so the description need not explain return values. The description, combined with the schema, is sufficient for the agent to understand the tool's role. The only missing element is explicit usage scenarios, which are already captured by the lower usage score.

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 89%, well above the 80% threshold, so the baseline is 3. The description itself does not elaborate on parameters, but the schema provides adequate explanation for most fields. The description adds no additional parameter 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 states a specific verb ('Get') and a clear resource ('proxies from Zabbix'). This directly distinguishes it from mutation siblings like proxy_create, proxy_update, and proxy_delete, and aligns with the readOnlyHint annotation.

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 explicit guidance on when to use this tool versus alternatives. It lacks any 'when to use' or 'when not to use' clauses, leaving the agent to infer usage solely from the verb 'Get' and the sibling names.

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

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

Annotations provide minimal behavioral hints (readOnlyHint=false, destructiveHint=false). The description adds that the tool modifies properties but lacks details on side effects, auth requirements, 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 three well-structured sentences with no fluff. The first sentence states the purpose, followed by details and usage guidance, making it highly efficient.

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

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

Given the tool's simplicity and presence of output schema, the description covers the core functionality and partial update behavior. It is complete for an update tool, though it could mention return value 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?

Schema coverage is 100%, providing baseline 3. The description adds value by mentioning specific fields (name, operating mode, description) and the partial update pattern, going beyond schema descriptions.

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 updates an existing proxy in Zabbix and lists modifiable properties (name, operating mode, description). This distinguishes it from sibling tools like proxy_create or proxy_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 advises to 'only specify the fields you want to change', implying partial updates. However, it does not explicitly state when to use this tool over alternatives, though the purpose implies it for existing proxies.

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 implies state-changing behavior but does not disclose potential side effects or risks. With annotations not providing destructiveHint or idempotentHint, more detail would be beneficial. However, it does indicate that scripts can modify host state.

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

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

The description is concise with two sentences that directly convey the tool's purpose and common use cases without unnecessary 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 presence of an output schema (not shown), the description sufficiently covers the tool's purpose and usage. It could mention that the script must exist and the host must be reachable, but overall it is fairly complete.

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

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

Schema coverage is 100% and parameter descriptions are clear. The description does not add additional semantics beyond what the schema already provides. 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 (execute a script), the resource (on a host in Zabbix), and provides specific use cases (remediation, config changes, diagnostics). It distinguishes the tool from siblings like script_get and host_get by explaining that it runs custom 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 mentions use cases but does not provide explicit guidance on when to avoid using this tool or prerequisites (e.g., script must exist, agent must be running). It lacks explicit alternatives, though none exist among siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful domain context about scripts being automation routines but does not disclose additional behavioral details such as pagination behavior, filtering semantics, or response characteristics. It does not contradict the annotations.

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

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

The description is short and front-loaded with the core operation. The two additional sentences about scripts are relevant context rather than fluff, giving the agent enough background without excessive length. It is efficient and readable.

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 rich input schema, output schema, and safety annotations, the description is largely sufficient for an agent to invoke the tool correctly. It adds useful domain context that is not present in structured fields. The main gap is the lack of explicit guidance about when to prefer this over sibling tools, but that is a usage-guideline concern more than a completeness 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 high at 91%, so the schema already documents most parameters. The description does not add parameter-level meaning and does not compensate for the small uncovered portion. It provides domain context that could help interpret parameters like hostids or search, but the schema carries the main burden.

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

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

The description opens with the specific verb-resource pair 'Get scripts from Zabbix', clearly indicating a read operation on the script resource. The following sentences define what scripts are, which helps distinguish this tool from execution-focused siblings like script_execute. It is clear but does not explicitly contrast itself with sibling 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 explains what scripts are but provides no guidance on when to use script_get versus alternatives such as script_execute, or when other get tools would be more appropriate. There are no exclusions, preconditions, or alternative routing cues, leaving the agent to infer usage from the resource name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds domain knowledge about services and dependencies, which is contextual, but it does not disclose additional behavioral traits like pagination (though the schema covers that) or any limitations. It does not contradict the annotations; it simply adds minimal behavior beyond what annotations already provide.

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

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

The description is concise: two sentences that state the tool's purpose and provide domain context. It is front-loaded with the action ('Get services from Zabbix') and follows with explanatory detail. There is no fluff or unrelated content, making it efficient for an agent to parse.

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

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

The tool is a read-only get operation with 10 parameters but an output schema exists, so return values are covered elsewhere. The description provides key domain context (services as business capabilities and hierarchical dependencies), which is essential for an agent to understand the resource. While it does not explicitly explain how to use parentids for dependency traversal, the schema covers that. The description is complete enough for the tool's read-only nature and schema richness.

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

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

Schema coverage is 90%, which is high, so the schema already documents most parameters (limit, offset, search, parentids, etc.) with descriptions. The tool description provides no additional parameter information, but the baseline for high coverage is 3. The description does not compensate for the few uncovered parameters, but it does not need to given the schema's richness.

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 retrieves services from Zabbix, naming the resource and action. It also provides useful domain context (services represent business capabilities and can form hierarchies), which helps differentiate it from other *_get tools. However, it does not explicitly distinguish from siblings like host_get or item_get, so it is clear but lacks explicit differentiation.

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

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

The description gives no guidance on when to use this tool versus alternatives. It explains what services are, but not when an agent should choose service_get over other get endpoints. No explicit exclusions or alternative tool mentions are provided. The tool's purpose is implied but 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds domain context about SLAs but does not disclose operational behavior such as pagination or default result scope; it is not contradictory.

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

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

The description is short and front-loaded with the actionable statement, followed by a brief, relevant explanation of what SLAs are. It stays within three sentences and avoids redundant restatement of the schema.

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

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

Given the rich optional-parameter schema, output schema, and safety annotations, the description is adequate for selecting and invoking this tool. It could add explicit mention of default 'all SLAs' behavior, but the schema already communicates that through slaids and limit defaults.

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

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

With roughly 90% schema description coverage and detailed parameter descriptions for limit, offset, search, slaids, serviceids, and count_output, the schema already carries the parameter semantics. The description adds no parameter-specific meaning beyond the schema.

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

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

The description opens with a clear verb and resource: 'Get SLAs from Zabbix,' so an agent can immediately identify the operation. It does not explicitly contrast with related siblings such as service_get, but the SLA resource is distinct enough that the purpose is unambiguous.

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

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

The description implies this tool is for retrieving SLA definitions when SLA data is needed, but it provides no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or exclusions, leaving usage boundaries to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is known. The description adds domain context (what templates are for) but does not disclose additional behavioral traits such as error behavior, idempotency nuances, or required permissions beyond what 'create' implies. It neither contradicts the annotations nor enriches them significantly.

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

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

The description is well-structured with a clear topic sentence followed by brief rationale. It is not overly verbose and front-loads the core action. The second sentence adds value by explaining why custom templates matter, though it could be trimmed slightly. Overall, it is efficient and easy to scan.

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

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

Given there is an output schema and the annotations cover the safety profile, the description adequately covers the use case rationale. It explains the purpose of templates and when creating one is beneficial. No critical information is missing for an agent to invoke the tool correctly, though it could mention that the 'host' is technically the template's technical name (a nuance already in the schema).

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

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

Schema coverage is 100%, so all parameters have descriptions. The high-level description ('Templates define the monitoring configuration...') provides background but does not add parameter-specific details beyond what the schema already offers. The baseline of 3 applies because the schema handles the bulk of parameter documentation.

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 'Create a new template in Zabbix.' with a specific verb and resource. It differentiates from sibling operations like template_update and template_delete by focusing on creation. The additional context about reusability and standardized monitoring further clarifies the purpose.

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

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

The description implies usage by explaining the benefit of templates ('enables standardized monitoring') but does not explicitly state when to use this tool versus alternatives like template_update. There is no mention of prerequisites or exclusions. The guidance is implicit rather than directive.

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

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

The description goes beyond the destructiveHint annotation by detailing the consequences: it mentions permanence, loss of items/triggers/graphs on affected hosts, and that hosts themselves remain unchanged. This adds valuable behavioral nuance beyond the simple destructive flag.

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

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

Two sentences with no filler. The primary action and permanent nature are front-loaded, and the side effect on hosts is explained concisely. Every sentence 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 one-parameter delete tool, the description covers the action, the permanence, and the impact on associated entities. With annotations already covering the destructive nature and an output schema present, nothing essential is missing for an agent to call this correctly.

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

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

The schema fully describes the parameter (templateids as an array of string IDs to delete). The description adds no additional parameter-level meaning beyond what the schema provides, so a baseline of 3 is appropriate given 100% 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: deleting templates from Zabbix. It specifies the resource (templates) and the action (delete), and distinguishes it from sibling delete tools (item_delete, trigger_delete, etc.) by focusing on templates. The effect on hosts is also stated, making the scope explicit.

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

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

The description makes it clear when to use this tool: when you need to permanently remove templates. It does not explicitly mention alternatives or exclusions, but the context is unambiguous given the name and sibling set. The description provides clear context without needing to state 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?

Annotations already declare this as read-only, idempotent, and non-destructive, so the description does not need to restate those. It adds useful context about templates being reusable collections and standardizing monitoring, which helps the agent understand the domain. It could mention response structure details, but the output schema exists, so not mandatory. No contradiction with annotations.

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

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

The description is concise: a single sentence stating the core action, followed by a short explanation of templates. It is front-loaded with the main purpose, and the additional context is useful. No filler or redundancy.

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

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

For a read-only getter with a rich schema (16 parameters, many with descriptions) and an output schema, the description covers the essential what and why. It does not detail every parameter, but the schema fills that gap. Considering the complexity, the description is adequate and complete enough for an agent to use the tool correctly without needing additional context.

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

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

Schema description coverage is 81%, so the schema already documents most parameters. The description adds value by explaining the concept of templates and the 'search' parameter behavior with an example, which goes beyond the schema. It also clarifies practical usage hints like paging with 'limit' and 'offset'. This justifies a score above baseline 3.

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

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

The description states a specific verb ('Get') and resource ('templates from Zabbix') and further clarifies what templates are, distinguishing this getter from sibling tools like template_create, template_delete, and template_update. This makes the tool's 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 explains what templates are and their role in standardizing monitoring, giving context for when this tool is relevant. However, it does not explicitly state when to choose this over other getters (e.g., host_get) or when not to use it. Usage is implied but not explicit.

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

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

Annotations already indicate the tool is not readOnly, not idempotent, and not destructive. The description adds that it modifies properties of an existing template, but does not disclose side effects (e.g., impact on linked objects) or authorization requirements. The extra detail over annotations is minimal.

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

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

The description is extremely concise: two short sentences front-loaded with the core purpose, followed by additional usage guidance. Every sentence adds value with no redundancy.

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

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

Given the tool's low complexity (3 parameters, simple update operation, output schema exists), the description covers the essential aspects: what it does, which fields can be changed, and partial update pattern. It could mention that the template must already exist, but this is a minor 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?

The input schema already provides detailed descriptions for all three parameters (100% coverage). The description adds value by clarifying partial update semantics ('Only specify the fields you want to change'), which is not evident from the schema alone.

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

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

The description clearly states the verb ('Update') and resource ('template in Zabbix'), and lists the specific modifiable properties (name, description). It distinguishes from sibling tools like template_create, template_delete, and template_get.

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 updating existing templates and notes to 'only specify fields you want to change', but it does not explicitly state when to use vs alternatives (e.g., template_create for new templates) or mention prerequisites like template existence.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond those annotations: trends are aggregated at hour-long intervals and contain min/max/average values, which explains the data shape and resolution an agent should expect.

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

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

Three sentences with the main action front-loaded and no filler. The two supporting sentences explain why trends matter and what they contain, so each sentence earns its place without 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?

For a read-only, idempotent retrieval tool with a fully documented input schema and an output schema, the description is complete. It explains the nature of trend data, the use case, and the key distinction from raw history, leaving no critical gap for an agent to call it correctly.

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

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

The input schema has 100% description coverage and each parameter is already explained clearly, so the baseline is 3. The description's mention of hour-long intervals and aggregation gives useful context but does not meaningfully add per-parameter semantics beyond what the schema provides.

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

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

The description states a specific verb and resource ('Get trend data from Zabbix') and immediately clarifies what makes trends distinct from raw history: aggregated, summarized, hour-long intervals with min/max/average values. This clearly distinguishes it from sibling tools like history_get even without naming them.

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

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

The description gives clear usage context by explaining that trends consume less storage while preserving statistical information 'for long-term analysis,' and contrasts them with raw history. It does not explicitly name alternative tools or state when not to use this tool, so it stops just short of full routing 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?

Annotations already declare non-readOnly, non-idempotent, and non-destructive. The description adds conceptual context about trigger purpose but lacks operational details like permissions or side effects.

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

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

Three sentences, front-loaded with action, no superfluous content. Excellent conciseness.

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

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

With full schema coverage and an output schema, the description provides adequate conceptual background. Minor gap: no mention of required item associations or when triggers become active.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds general context for triggers but does not enhance parameter-specific 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 states the action ('Create a new trigger in Zabbix') and the resource ('trigger'), distinguishing it from sibling tools like trigger_delete, trigger_get, and trigger_update.

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 explains what triggers are but does not explicitly state when to use this tool versus alternatives like host_create or item_create. Context is implied but not directive.

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