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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description adds the genuinely useful preview-then-confirm workflow, which the annotations cannot express. What is missing is which of the five actions is destructive or irreversible (close vs. acknowledge vs. change_severity), whether actions apply atomically, and what the preview contains.

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

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

Two short sentences with no filler, and the workflow constraint is positioned right after the purpose statement where it is most needed. The phrasing is slightly clipped ('first call returns a preview' leaves the second call implicit), but nothing is wasted.

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

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

This is a destructive, non-idempotent tool bundling five distinct operations with no output schema, and the description never explains how multiple actions combine, what the preview returns, or whether closing is reversible. For a tool with this much behavioral surface, two sentences covering purpose and the confirmation loop leave too much to inference.

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

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

Schema coverage is 100%, so every parameter including the actions enum, eventid, message, severity and confirm_token is already documented in the schema. The description reinforces which actions exist but adds no syntax, ordering, or interaction rules beyond what the schema states, so the baseline of 3 applies.

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

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

The description names concrete verbs and resource: 'Acknowledge, comment on, re-rate or close problems', which maps cleanly onto the actions enum and distinguishes it from read-only siblings like get_active_problems. The opening line is specific enough that an agent knows this is the mutation endpoint, though the tool name 'acknowledge_problem' understates the broader scope only the description reveals.

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?

'Two-step: first call returns a preview' tells the agent the calling sequence, and the schema points to get_active_problems as the source of event ids. However, there is no guidance on when to prefer this over zabbix_raw_api or other siblings, no statement about which action combinations are valid, and no mention of prerequisites or permissions.

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, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only that the payload contains widget type names, key field names, and layout rules; it does not clarify whether this is a static snapshot or live server config, nor how large the catalog is.

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

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

A single front-loaded sentence that names the content categories with no filler or redundancy. Every clause (widget types, field names, layout rules) carries 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?

With no parameters and no output schema, the description is the only source of shape information, and it lists content categories without describing the structure of the returned catalog. It is adequate for a trivial no-arg lookup but leaves the agent guessing what the response looks like.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is no parameter meaning to explain. The description correctly implies no arguments are needed by framing it as a fixed catalog lookup.

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

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

States a specific resource — supported dashboard widget types, their key field names, and layout rules — so an agent knows exactly what reference data this returns. It does not name or contrast with the sibling manage_dashboard, so an agent must infer that this is the read-only lookup companion to that mutation 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?

Usage is only implied: an agent can infer this is the reference to consult before constructing a dashboard via manage_dashboard, but the description never says when to call it or when not to. No alternatives or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile needs no restatement. The description adds ordering and returned fields, but omits the important behavioral defaults: limit 25, min_severity defaulting to 'average', and unacknowledged_only defaulting to true, meaning acknowledged problems are silently excluded from a result described as 'current unresolved problems'.

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

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

One front-loaded sentence with no wasted words; scope comes first and ordering second. It is terse to the point of under-specification rather than verbose, so the efficiency is real but bought at the cost of missing defaults.

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?

A six-parameter, zero-required tool with no output schema and several default-true/default-value filters needs the description to explain what the returned set actually contains. As written, an agent cannot know that suppressed and acknowledged problems are excluded by default, so it risks misreporting the problem set as 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?

With only 50% schema description coverage, three parameters (limit, include_suppressed, unacknowledged_only) carry no explanation anywhere, and the description does not compensate. It also gives no hint about the severity scale semantics or wildcard filtering supported by host/group, leaving the default-driven filtering behavior undocumented.

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

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

States a specific resource and scope: 'Current unresolved problems', plus the ordering ('newest first') and the fields returned (host, severity, age). An agent can tell it apart from get_triggers and get_problem_events at a high level, though no sibling is named explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives such as get_problem_events (which presumably covers problem history) or get_triggers. In a sibling set this dense, the agent must infer that this is the 'currently active only' view on its own.

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, so the safety profile is covered. The description adds one genuine behavioral fact beyond them: results are ordered newest first. It says nothing about the default 24-hour lookback window or the 30/200 row cap behavior, which matter for interpreting an empty or truncated result.

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

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

A single front-loaded sentence with zero filler; the resource, content, and ordering are all delivered immediately.

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

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

For a 4-parameter tool with no output schema and weak schema coverage, the description should explain the time window, the truncation cap, and what an entry contains. It covers none of these, leaving the agent without enough context to interpret or scope a query correctly.

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

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

Schema description coverage is only 25% — just 'user' is documented. The description adds no meaning for hours (lookback window, max 2160), limit (row cap), or action (the eight-value enum including login/failed_login/execute/push), so an agent must infer all three from bare schema names and defaults.

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

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

States a specific verb+resource ('Zabbix audit log entries') and clarifies content with '(who changed what)', which tells the agent this is a change-history feed rather than monitoring data. It does not distinguish itself from any sibling, though no sibling appears to cover audit logs, so the risk of confusion is low.

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 when-to-use guidance, no mention of prerequisites (e.g., admin permissions typically required for Zabbix audit logs), and no named alternatives such as get_problem_events for event-level history. The parenthetical '(who changed what)' only loosely implies the use case.

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, so the safety profile is fully covered without description help. The description adds that results are aggregated (counts alongside configuration), which is a genuine behavioral detail beyond the annotations, but says nothing about behavior when a host is missing or when a wildcard matches multiple hosts.

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

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

One sentence with no filler and the scope ('for one host') placed at the end as the qualifier. It is telegraphic to the point of being a noun list rather than a statement of action, which costs a little clarity but wastes nothing.

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

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

With no output schema, the enumerated field list usefully tells the agent what comes back, which is the main thing an agent needs here. However, it omits how counts are scoped (time window for problem counts) and what happens with wildcard matches, leaving gaps for a detail-fetch 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 coverage is 100% and the single 'host' parameter already documents that it accepts a name, technical name, and wildcard. The description adds no format, casing, or ambiguity-resolution guidance, so 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 enumerates exactly what detail categories are returned (status, interfaces, groups, templates, tags, item/problem counts) and scopes it to 'one host', which implicitly separates it from list-style siblings like search_hosts. It lacks an explicit verb and never names a sibling to contrast with, so differentiation rests on inference.

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 when-to-use guidance: nothing says to call this after search_hosts to resolve a host name, nor when to prefer get_triggers, get_latest_values, or zabbix_hosts instead. The 'one host' phrasing hints at a single-host lookup after discovery, but the agent must infer that entirely.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without the description. The description adds nothing beyond that: it does not say whether values may be stale, whether one row is returned per item, or how the limit truncates results. For a read tool whose annotations are complete this is not a contradiction, but it leaves the behavioral burden entirely on structured fields.

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

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

A single well-scoped sentence with no wasted words, and the optional-filter nuance is packed in efficiently. It is a fragment rather than a full clause, which slightly weakens front-loading of the action, but nothing is redundant.

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 three-parameter, read-only tool with no output schema, the definition is adequate but thin: an agent still does not know the shape of returned values, how pattern matching behaves (substring versus exact key), or what happens with a wildcard host. The essentials are present, so it is viable but not self-sufficient.

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 67% schema coverage, baseline is a 3. The description's 'filtered by name/key' loosely restates the pattern parameter, which the schema already documents with examples ('cpu', 'vfs.fs'), and it says nothing about host wildcard support matching or about the limit parameter's default of 30 and 200 maximum.

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

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

The description names a specific resource (a host's items) and the exact data returned (latest collected values), which is more precise than the bare tool name. It does not distinguish itself from siblings such as query_metrics_history or get_host_details, so an agent must infer the boundary itself.

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 statement of when to use this tool versus query_metrics_history (historical data) or get_host_details (inventory-style data). The phrase 'optionally filtered' implies the filter is optional but gives no cue about when to use limit versus pattern, and no prerequisites or exclusions are 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior not in the annotations — result ordering (newest first) and inclusion of resolved events — but says nothing about result volume, pagination, or truncation at the limit.

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

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

A single front-loaded sentence with no filler; scope and ordering come first. Nothing is wasted, though the terseness is also the source of the missing detail elsewhere.

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?

Four parameters, 25% schema coverage, no output schema, and a non-obvious severity default leave too much unstated. An agent could call this tool correctly in a mechanical sense but would not understand that sub-warning events are excluded by default or how results are bounded.

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

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

Schema description coverage is only 25% (only host is documented), so the description carries most of the burden and does almost none of it. It never mentions hours, limit, or the min_severity filter — and the default of min_severity="warning" silently drops lower-severity events, a gotcha an agent would not anticipate from "problem events in a time window."

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?

Names the resource precisely (problem events), scopes it to a time window, and states the ordering (newest first). The parenthetical "including resolved ones" implicitly distinguishes it from get_active_problems, but it never names that sibling, so the differentiation is left to inference rather than stated.

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 when-to-use or when-not-to-use guidance. An agent must infer from "including resolved ones" that this is the historical counterpart to get_active_problems, and nothing indicates whether it or get_triggers is the right source for current incident state.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered and the description need not restate it. The description's real contribution is enumerating the returned content categories, which matters because there is no output schema — but it gives no sense of shape, depth, or cost of the call.

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

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

A single compact fragment with no filler, and the highest-value items (version, HA nodes, host/problem counts) are listed up front. It is a noun phrase rather than a sentence, which is slightly weaker structurally but wastes no space.

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 zero parameters and no output schema, the description is the only source of return-value information, and it does list the content categories — the essential minimum. It stops short of describing structure or granularity, so an agent knows what topics come back but not in what form.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly implies a no-argument, whole-server query.

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

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

The description names the specific resource content this tool surfaces: Zabbix version, HA nodes, proxies, host counts, and open problem counts. That is precise enough to distinguish a server-level overview from siblings such as get_host_details or get_active_problems, even though no sibling is named explicitly and the fragment lacks a leading verb.

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 when-to-use guidance at all: nothing tells the agent to prefer this over get_active_problems for problem counts, or over zabbix_monitoring for general health checks. Usage is only inferable from the fact that the payload looks like an overview, which is left entirely to the reader.

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 readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds one behavioral trait beyond that — the dual list-vs-report mode keyed on the 'sla' argument — but says nothing about report content, aggregation semantics, or period granularity.

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

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

A single compact sentence with zero waste, front-loading the report purpose and then the enumeration fallback. The semicolon cleanly separates the two operating modes.

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?

There is no output schema, so the description would ideally hint at the shape of an SLA/SLI report, but it does not. For a three-optional-parameter read tool with full schema coverage that is a modest gap rather than a blocking one.

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

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

Schema description coverage is 100%, so all three parameters are already documented with defaults, min/max on 'periods', and the omit-to-list rule. The description reinforces the 'sla' behavior but adds no new detail on 'periods' or 'service' beyond the schema baseline.

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

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

The description names a specific resource ('SLA/SLI per service') and its scope ('recent periods'), and notes a second mode ('without sla lists available SLAs'). An agent can tell it retrieves SLA reporting data, though it never says what an SLA/SLI report actually contains or how it differs from the sibling 'zabbix_services' tool.

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

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

It gives one concrete usage rule: omit 'sla' to enumerate available SLAs, which is a genuine when-to-use cue. It offers no guidance on when to choose this over siblings such as get_latest_values or zabbix_services, and no prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that triggers are monitored and enabled and that severity and state are exposed, which is somewhat useful scoping context, but it does not clarify filtering behavior, defaults, or result shape.

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, which is good, but it is telegraphic to the point of under-specification. The single fragment does not earn its place as a complete tool definition because it omits critical operational context.

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 four-parameter query tool with no output schema and only half of the parameters described in the schema, the description is too thin. An agent needs to know which triggers are returned, how defaults shape results, and how this differs from sibling problem-listing tools, none of which is adequately 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 description coverage is only 50%, and the description barely compensates. The phrase 'severity and state' loosely maps to min_severity and only_problems, but host and limit receive no explanation in the description, and the important default behavior (min_severity defaulting to warning, only_problems defaulting to true) is not surfaced.

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

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

The description names the resource (triggers) and some scoping attributes (monitored, enabled, severity, state), but it is a noun-phrase fragment rather than a clear verb+resource statement. It gives no differentiation from siblings such as get_active_problems or get_problem_events, so an agent cannot confidently choose it over 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?

There is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative. The fragment implies the tool retrieves triggers, but nothing tells the agent whether this is for configuration review, problem triage, or severity filtering versus the sibling problem-oriented 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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description contributes only that results include host counts, which is a small return-shape hint. It says nothing about pagination, default limits, ordering, or completeness of the result set.

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?

There is no padding or wasted wording, but the text is a fragment rather than a properly sized description, so its brevity comes from under-specification rather than efficiency. It is front-loaded but nearly empty.

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

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

With no output schema, the description should at least explain what a host group record includes, how many are returned by default, and how filtering behaves. Given the tool exposes pagination and search parameters, the one-line fragment leaves the agent with unresolved questions before calling 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 50%: 'search' is documented as a wildcard name filter, but 'limit' has no description beyond its default of 50 and max of 200. The description does not mention either parameter, so it fails to compensate for the undocumented limit or clarify filtering 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 is a bare noun phrase, "Host groups with host counts." It restates the resource encoded in the name (list_host_groups) and adds only that host counts are included. There is no verb and no differentiation from siblings such as search_hosts or get_host_details, so an agent learns little beyond the tool name.

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 when-to-use guidance, no when-not-to-use, and no mention of alternatives like search_hosts or get_host_details. An agent must infer from the name alone that this is a listing/browsing tool rather than a search or detail lookup.

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

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

The description adds genuinely useful behavior beyond the annotations: changes are validated and require a two-step confirmation, which explains the confirm_token parameter and warns the agent that a mutation is not immediate. That said, it never states which operations are destructive or irreversible (the annotations flag destructiveHint=true), nor whether the preview step is mandatory for every mutating operation. With annotations already declaring the safety profile, this partial disclosure earns a middle score.

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

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

Two short sentences, front-loaded with the resource and verb, with no filler. It is efficient, though the brevity borders on under-specification given the tool's nine operations.

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 ten-parameter, nine-operation, destructive mutation tool with no output schema, the description leaves major gaps: which operations require the confirm token, what delete does to widgets and sharing, and how errors from validation surface. The two-step confirmation note is the only behavioral anchor provided.

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 90%, so per-parameter meaning is already well documented in the schema itself, including which operation each field applies to. The description adds no parameter-level detail beyond the two-step confirmation hint, so baseline 3 applies.

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

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

The description names a verb (create/edit) and a resource (Zabbix dashboards), so the general purpose is legible. However, the tool actually exposes nine operations including list, get, set_sharing, replace_pages and delete, and the description covers only creation and editing. An agent reading only the description would not expect read or delete capability from this 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?

There is no guidance on when to choose this tool over siblings such as dashboard_widget_catalog or zabbix_visualization, nor on which operation fits which situation. The operation enum in the schema implies the choices, but the description itself offers no selection criteria 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, readOnlyHint=false and idempotentHint=false, so the risk profile is covered structurally. The description contributes one genuinely new behavioral fact — that create and delete are two-step operations — but it never explains that the first call is a preview returning a token, that the second call performs the change, or what happens to hosts already in maintenance, leaving the workflow half-disclosed.

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

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

Two short sentences, front-loaded with the operation enumeration, with no filler. It is efficient but borders on cryptic: 'two-step' is compressed to the point that an agent must consult the schema to learn what the steps are.

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

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

For an 11-parameter, destructive, non-idempotent mutation tool with no output schema and only 73% schema coverage, the description is far too thin. It omits the preview/confirm mechanics, the effect of delete (whether windows are permanently gone), and the semantics of scheduling offsets — exactly the context an agent needs before invoking a destructive write.

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

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

With schema coverage at 73% across 11 parameters, the schema does most of the documentation work, including per-operation hints on name, hosts, groups, maintenanceids, active_only and confirm_token. The description adds nothing parameter-specific — notably it never connects 'two-step' to confirm_token, and it is silent on duration_minutes, start_in_minutes and data_collection, which carry no per-field 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 names the resource (maintenance windows) and enumerates the three actions (list, schedule/create, remove/delete), which lets an agent distinguish it from every sibling tool since none of them touch maintenance windows. It loses a point for terminology drift: the description says 'schedule' and 'remove' while the operation enum uses 'create' and 'delete', forcing a small mapping step.

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 enumerated operations rather than stated as conditions — the agent must infer that 'list' is for inspection and 'create'/'delete' are for mutation. There is no guidance on prerequisites (host/group existence), on when a maintenance window is preferable to acknowledging problems, or on any exclusion relative to sibling tools such as zabbix_hosts or acknowledge_problem.

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 read-only and idempotency, and the description adds genuinely new behavior: a cap of 5 matching items, downsampling to min/avg/max buckets, and a switch to trend data for windows over 48h. It does not say what happens when more than 5 items match (error vs truncation).

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

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

A single tight sentence with the key behavioral fact (bucket downsampling) front-loaded and no filler. The parenthetical 'or trends for windows >48h' is slightly compressed but 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?

With no output schema, the description should clarify the return shape (per-item series of buckets?) and the >5-match behavior. It covers the aggregation model but leaves the result structure and overflow handling for the agent to guess.

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 75%, so host, item and minutes are already documented. The description's 'up to 5 matching items' and 'min/avg/max buckets' gestures at the item and max_points parameters but adds no format or semantics for max_points, which is the undocumented one.

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

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

States the resource (metric history) and the transformation applied (downsampled min/avg/max buckets), and notes the trends mode for windows >48h. It is reasonably distinguishable from get_latest_values by the 'history' framing, but it never explicitly names that sibling or states the contrast.

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

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

Usage is only implied by the word 'History' and the >48h trends note; there is no explicit 'use this instead of get_latest_values when you need a time window' guidance and no stated 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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds no further behavioral context such as result limits, pagination, or how broad matching behaves, leaving only the basic purpose statement 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?

A single front-loaded sentence with no wasted wording. It states the operation and search keys efficiently, though the sparseness is addressed in other dimensions.

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

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

For a simple three-parameter search tool with annotations and no output schema, the description is minimally adequate. It still omits practical context such as result limiting, group scoping, and when this search should be preferred over host-detail tools.

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

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

Schema coverage is 67%, with query and group documented but limit only constrained by default/min/max. The description usefully expands query semantics to include technical name, but does not explain group filtering or the result limit.

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

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

States a specific verb and resource: "Find hosts" with lookup keys name, technical name, IP, and DNS. It is clear enough to separate from detail tools, but it does not name or distinguish itself from siblings such as get_host_details or zabbix_hosts.

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 when-to-use guidance, no exclusions, and no alternatives. An agent can infer this is for searching hosts, but must guess when to choose it over get_host_details or zabbix_hosts.

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, so the safety profile is covered. The description adds real value beyond that: it discloses the two-step write protocol (preview, then repeat with confirm_token) and that reads return compact defaults. It does not say what data destruction looks like or what permissions are required, which keeps it from a 5.

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, front-loaded with the domain and its method inventory, then the behavioral rules. The dense semicolon-separated method list is information-carrying rather than filler. Minor cost: the enumeration is heavy to parse and could have been collapsed, but no sentence is truly wasted.

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

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

For a generic JSON-RPC dispatcher with three highly schematized parameters and no output schema, the definition covers the essentials: what resources, which verbs, the two-phase write requirement, and where to get method-level documentation. The return-value shape is only hinted at ('compact defaults'), which is the main remaining gap, but the describe_method pointer mitigates it.

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

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

Schema coverage is 100%, so method, params, and confirm_token are all documented in the schema; the baseline of 3 applies. The description does reinforce the confirm_token workflow and that params can carry ids for deletes only indirectly. Notably it defers parameter detail to zabbix_describe_method rather than explaining method-specific shapes 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 names the domain ('Zabbix alerting API') and explicitly enumerates the resources it governs: action, mediatype, script, connector, each with its supported verbs. That lets an agent separate it from siblings like zabbix_hosts or zabbix_config without opening the schema. It stops short of a 5 because the tool itself is a generic method dispatcher, so the actual operation is only known once the agent picks a method string.

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 one concrete routing instruction: use zabbix_describe_method for docs and parameters, which is genuinely useful. However, there is no guidance on when to choose this tool over zabbix_raw_api (which presumably can call the same methods) or over the domain-scoped siblings, and no statement of prerequisites or exclusions. Usage is implied by the resource list 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 flag destructiveHint=true, readOnlyHint=false and non-idempotent, so the safety profile is known. The description adds behavior the annotations cannot convey: reads return compact defaults, and writes are two-step with a preview followed by a repeat call carrying confirm_token — important procedural context for a destructive dispatcher.

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 two-step write explanation is front-loaded and earns its place, but the long semicolon-separated method inventory consumes most of the text and overlaps heavily with what zabbix_search_methods and zabbix_describe_method exist to provide. It reads as a data dump rather than prioritised guidance.

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 generic dispatcher with no output schema, the description covers what an agent most needs (available methods and the confirm_token write protocol). It is still thin on what 'compact defaults' means in practice and how to obtain full read output, which matters for an open-ended config API.

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 method, params and confirm_token are already documented in the schema, and the baseline of 3 applies. The description contributes the fact that confirm_token originates from the preview call and that params accepts an array of ids for deletes, but that detail is largely duplicated by the schema text.

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

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

The description names the resource domain (Zabbix configuration API) and enumerates the concrete method families it dispatches (itemprototype, triggerprototype, discoveryrule, httptest, usermacro, valuemap, regexp, correlation, configuration). An agent can tell this is a generic config-domain dispatcher, but the description never contrasts it with the sibling zabbix_raw_api, so the boundary between the two is left for the agent to infer.

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

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

It gives one explicit routing instruction (use zabbix_describe_method for docs and parameters) and explains the two-step write flow, which is real usage guidance. However, it never says when to choose this tool over zabbix_raw_api or the curated domain siblings like zabbix_hosts, and gives no prerequisites or exclusions.

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

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

Beyond the read-only and non-destructive annotations, the description discloses the single-method scope and four types of information the lookup provides. This usefully frames it as metadata inspection, although lookup-failure behavior and whether permission status is user-specific remain unspecified.

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

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

The description is compact and front-loaded with both the returned information and the single-method scope. It contains no filler or redundant explanation.

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

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

For a simple one-parameter, read-only lookup with no output schema, listing the expected information provides enough context for basic selection and invocation. Explicit sibling routing and a little more detail about permission status would make it more complete.

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

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

Schema description coverage is 100%, and the method parameter already includes the useful example 'host.create'. The description reinforces that only one method is described but adds no parameter syntax or validation details 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 identifies the resource as one API method and specifies the information supplied: a docs link, read/write class, permission status, and usage tips. It does not explicitly distinguish this inspection tool from zabbix_search_methods or zabbix_raw_api.

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

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

The phrase 'for one API method' implies use when a specific method is already known and its documentation or permissions are needed. There is no explicit guidance to use zabbix_search_methods for method discovery or zabbix_raw_api for executing API calls.

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, so the safety profile is partly known; the description still adds material context they do not carry, namely that writes are two-step (preview first, then repeat with confirm_token) and that reads return compact rather than full records. This is exactly the kind of non-obvious behavioral detail an agent would otherwise get wrong on the first call. It falls short of 5 because it says nothing about required permissions, cascade behavior on deletes, or rate limits across the many methods.

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 method enumeration is dense and dominates the text, while the two highest-value sentences (compact reads, two-step writes, describe_method pointer) are buried at the end rather than front-loaded. Nothing is strictly filler, since each list maps to real callable methods, but an agent scanning the first sentence learns less than it should about the write-confirmation requirement.

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 three-parameter dispatcher with no output schema, an agent needs the method surface, the write protocol, and a path to per-method documentation; the description supplies all three. The remaining gap is return shape: 'reads return compact defaults' is asserted but never characterized, and with no output schema there is nothing else to fall back on.

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% (method, params, and confirm_token are all documented inline), so the schema already does the heavy lifting and a 3 is the baseline. The description reinforces confirm_token's role by tying it to the preview-then-confirm write flow, but it adds no new syntax, format, or example detail for the free-form 'params' object beyond the schema's own 'JSON-RPC params' note.

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 resource frame ('Zabbix hosts API') and then enumerates the concrete method families the tool can dispatch (host, hostgroup, hostinterface, template, templategroup, proxy, proxygroup, maintenance) with their allowed verbs. An agent can immediately tell this is a generic method-dispatch gateway covering host-adjacent objects, not a single-purpose operation. It loses a point because it never distinguishes itself from generic siblings such as zabbix_raw_api or zabbix_config, which plausibly do the same job.

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

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

Usage is only implied by the enumerated methods: you would use it when you need a host/template/proxy/maintenance API call. There is no statement of when NOT to use it, and no routing to obviously overlapping siblings like search_hosts, get_host_details, list_host_groups, or manage_maintenance_window. The one explicit pointer, 'Use zabbix_describe_method for docs and parameters,' is a genuine routing rule but it addresses a prerequisite, not tool selection.

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

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

Annotations already flag destructive=true and non-idempotent; the description adds useful beyond-schema behavior: reads return compact defaults and writes require a two-step preview/confirm_token flow. It still does not explain permission requirements or the concrete impact of destructive methods such as delete/clear.

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 method enumeration is dense but earns its space by conveying the tool's broad scope, and the important write workflow is stated compactly. The description is front-loaded with the API identity and method list, though the long semicolon list is harder to scan.

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

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

For a generic API dispatcher with no output schema, the description covers supported method families, compact read defaults, the two-step write protocol, and a docs alternative. It is not fully complete because it omits sibling-tool routing and does not mention host-oriented methods even though host.get appears in the schema example.

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 method, params, and confirm_token are already documented in structured fields. The description reinforces the confirm_token write flow but adds no new syntax or constraints 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 names the resource as the Zabbix monitoring API and enumerates the method families it supports, so an agent knows this is a generic method dispatcher rather than a single-operation tool. It does not distinguish the tool from siblings such as zabbix_raw_api or the many specialized Zabbix 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?

It supplies procedural guidance for writes (preview then repeat with confirm_token) and directs agents to zabbix_describe_method for documentation. However, it never states when to choose this generic dispatcher over specialized siblings like get_active_problems or zabbix_hosts, nor 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?

The description adds real behavioral context beyond the annotations: a blocklist exists, and write calls follow a confirm-token/preview flow. However, listing "read-only" as one of the safety rules sits awkwardly against readOnlyHint=false and destructiveHint=true, leaving the agent unsure whether writes are actually permitted here; the contents of the blocklist and what the preview step returns are not stated.

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

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

Two short sentences, zero filler, with the framing ("escape hatch") front-loaded before the safety caveat. Nothing could be removed without losing 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 three-parameter escape hatch with full schema coverage and no output schema, the definition covers the essential shape: what it does, that guardrails apply, and that writes need confirmation. The missing piece is which tool produces the preview token and how failures/blocked methods are surfaced.

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 method, params, and confirm_token are already documented in the schema, including that params may be an array for delete methods and that the token comes from a preview call. The description adds no format, syntax, or method-specific detail beyond that, so the baseline of 3 applies.

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

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

"Escape hatch: call any 7.4 API method" names the specific action (arbitrary JSON-RPC method invocation) and the API version, and the word "escape hatch" signals it is the fallback rather than a primary surface. It distinguishes itself from curated siblings like zabbix_hosts or get_host_details, though it never names zabbix_search_methods or zabbix_describe_method as the pair to route through first.

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?

"Escape hatch" implies usage — reach for this when no dedicated tool covers the method — and the parenthetical hints at the guardrails applied. But there is no explicit "prefer X over this" statement despite zabbix_search_methods and zabbix_describe_method existing as obvious discovery siblings, and no guidance on when a method is disallowed.

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, non-destructive and closed-world, so the safety profile needs no restating. The description does add useful value by disclosing what the result contains: the tool that runs each method and whether the method is allowed, which is behavioral information the annotations cannot convey.

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

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

Two short sentences, front-loaded with the action and resource, and the second sentence carries the return-value hint. 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 simple two-parameter read-only search, the definition covers purpose and enough about the response shape to be callable without an output schema. It stops short of stating the workflow relationship to zabbix_describe_method, which is the only real 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 coverage is 50%: the query parameter is documented in the schema with an example, while limit carries only type/default/bounds. The description's "by name" narrows what query matches against (method names) but adds nothing about limit or how multi-word queries behave, leaving it at the baseline.

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?

"Find Zabbix 7.4 API methods by name" pairs a specific verb with a specific resource and scope, so the agent knows this is a discovery/lookup tool rather than an API executor. It does not explicitly contrast itself with siblings like zabbix_describe_method or zabbix_raw_api, which weakens the 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 explicit when-to-use or when-not-to-use guidance and never names alternatives. An agent must infer on its own that this is the right precursor step before zabbix_describe_method or zabbix_raw_api.

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 destructiveHint=true and readOnlyHint=false, while the description adds important workflow context: reads return compact defaults, and writes are two-step with a preview followed by a confirm_token. It does not detail the consequences of specific destructive writes, but the two-step confirmation behavior is valuable beyond the annotations.

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

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

The description is three compact sentences, front-loads the domain and method list, then covers return behavior and write confirmation, and ends with a useful documentation pointer. No wording is wasted.

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

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

For a generic method-dispatch tool with three parameters and no output schema, the description provides the key method names, read/write behavior, and a pointer to zabbix_describe_method for per-method parameters. It could say more about return values or error handling, but it is largely complete 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%, so the schema already documents the three parameters. The description adds meaningful method-level detail by listing the exact service and SLA method names, which helps with the method parameter, and it clarifies confirm_token's role in the two-step write process.

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 identifies the resource as the 'Zabbix services API' and enumerates the service and SLA methods it covers. This makes the tool's domain clear, though it does not explicitly distinguish itself from the generic zabbix_raw_api sibling.

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

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

The description implies usage for service and SLA methods and directs agents to zabbix_describe_method for documentation and parameters. However, it does not state when to use this tool instead of zabbix_raw_api or other domain tools, nor does it give explicit 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false), the description discloses the two-step write flow requiring a confirm_token and that reads return compact defaults. That is real operational context an agent would otherwise have to discover by failing a call; it stops short of saying what a delete removes or whether writes are reversible.

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

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

The description is front-loaded with the API scope, then the resource/operation matrix, then the read/write behavior, then the pointer to documentation — no wasted sentences. The enumerated method list is dense but earns its space by defining valid method values.

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 generic dispatch tool with no output schema, the description covers the write handshake and points to zabbix_describe_method for per-method parameters, which is the critical missing piece. However, the schema example for `method` ('host.get') does not match any of the visualization resources listed, which leaves the valid method namespace slightly unclear.

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 method, params, and confirm_token are already documented in the schema, and the description only reinforces the preview/confirm semantics. It adds no guidance on the shape of params per method beyond deferring to zabbix_describe_method, so the baseline of 3 applies.

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

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

The description names concrete resources (dashboard, templatedashboard, map, iconmap, image, report) and the four operations (create, delete, get, update) applied to each, so the tool's scope is unambiguous. It is distinguishable from sibling domain tools like zabbix_monitoring or zabbix_hosts by its explicit resource list, though it does not state why one would choose it over zabbix_raw_api.

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

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

It gives implied usage context: reads are compact, writes need a preview-then-confirm cycle, and documentation lives in zabbix_describe_method. It never states when to use this tool versus zabbix_raw_api or manage_dashboard, which overlaps on dashboards, so the agent must infer the routing.

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