Get host metrics

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 that the tool returns current metrics across several categories, which is useful. However, it does not disclose behavior such as whether the host must be actively monitored, whether metrics are real-time or cached, or what happens for an unknown host id. With annotations covering the safety profile, 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 sentences and front-loads the core action ('Get host metrics') before elaborating. Every sentence adds information about what the tool returns. It is appropriately sized for a simple one-parameter read tool, though the first sentence is somewhat redundant with the title.

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 read-only tool with one parameter and no output schema, the description covers the main purpose and return categories. However, it does not explain how to obtain the host id, whether the metrics are live or cached, or how this relates to the metrics collection/polling siblings. Given the large sibling set and the 0% schema coverage, a bit more context would help an agent select and invoke 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?

Schema description coverage is 0%, so the description must compensate. The description explains that the tool retrieves metrics for a specific host, which implies the 'id' parameter identifies that host. However, it does not clarify the id's type semantics (e.g., whether it is a Termix host id, a Proxmox node id, or an internal database id), nor does it explain the id's range or how to discover valid ids. The description adds some meaning but leaves ambiguity.

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 ('retrieves') and resource ('current metrics for a specific host') and enumerates the metric categories (CPU, memory, disk, network, processes, system information). It is clear about what the tool does, though it does not explicitly differentiate from sibling tools like termix_metrics_get_historical_metrics_host or termix_metrics_get_host_metrics_layout_host.

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 context: it is for current metrics of a specific host, which contrasts with historical metrics siblings. However, it does not explicitly state when to use this tool versus alternatives such as termix_metrics_get_historical_metrics_host or termix_metrics_get_all_host_statuses, nor does it mention any prerequisites like the host needing to be polled or monitored.

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