monitor_system_resources

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

With no annotations, the description carries the full behavioral burden; it does disclose the categories of data gathered and that status is 'real-time,' which tells the agent this is a read-style inspection. It does not say whether the call is side-effect free, whether it is expensive or rate-limited, or how fresh the measurements are, so meaningful gaps remain for a no-annotation 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?

Two short sentences, front-loaded with the action and scope. The second sentence partly restates the first ('provide real-time status' vs. 'collects comprehensive system resource information'), a small redundancy but no wasted structure.

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 exists, so return values needn't be explained, and the inputs are empty. What is missing is the selection context an agent needs among a dozen observability siblings: which scope this covers and when it should be preferred over monitor_server_health or collect_performance_metrics.

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 and the schema is fully described, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter claims are made.

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: 'Monitor system-wide resources and provide real-time status,' and the second sentence enumerates the collected signals (CPU, memory, disk, network, process). It is clear what the tool does, but it never distinguishes itself from close siblings such as monitor_server_health or collect_performance_metrics.

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 the several overlapping siblings in the list (monitor_server_health, collect_performance_metrics, check_stack_status). The agent must infer scope from the word 'system-wide' alone, with no exclusions or prerequisites offered.

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