Get Zabbix monitoring items by host or search query. Use key_metrics_only to isolate CPU, memory, and disk metrics.
查询监控项。需先通过host_get获取hostid。支持语义搜索，key_metrics_only智能筛选最佳指标
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回数量（默认20） | |
| output | No | 返回字段列表 | |
| search | No | 搜索关键词或条件字典（支持语义搜索如memory/cpu） | |
| hostids | No | 主机ID | |
| itemids | No | 监控项ID | |
| key_metrics_only | No | 仅返回关键性能指标（CPU/内存/磁盘），每类最多1个 |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a query operation, requires a hostid from host_get, supports semantic search, and that key_metrics_only intelligently filters to key metrics. It does not discuss auth or rate limits, but the presence of an output schema reduces the need to describe return 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?
Three short clauses, each earning its place: the purpose, the prerequisite, and the distinctive capabilities. It is front-loaded, scannable, and free of 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 full schema descriptions, an output schema, and the relative simplicity of a read tool, the description supplies the essential workflow context: the host_get dependency and the semantic-search/key-metrics capabilities. A minor gap is not explicitly noting that itemids can be used as an alternative selector, but the overall definition is sufficient for an agent to invoke the tool correctly in common cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by connecting hostids to host_get and characterizing key_metrics_only as smart filtering of the best metrics, even though some of this is echoed in the parameter 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 states a specific verb-resource pair — '查询监控项' (query monitoring items) — which clearly distinguishes this tool from siblings like host_get, trigger_get, and event_get. The mention of obtaining hostid via host_get also anchors its role in the broader workflow.
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 instructs the agent to first call host_get to obtain hostid, giving a clear precondition for the common host-based use case. It does not explicitly mention alternatives such as querying directly by itemids, but the intended context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.