system_health

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

No annotations are present, so the description fully carries the burden of behavioral context. 'Fast and read-only — safe to call any time' explicitly discloses the safety profile and operation cost. It also lists gateway reachability and process checks, which hint at possible network and process inspection behavior. It does not define the output shape or whether network calls are made, but for a zero-argument health snapshot, disclosure is above average.

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 'Snapshot' and the substance in a comma-separated list; the safety note lands last. Every word earns its place, no filler or redundant restatement of the name.

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 trivial in complexity (0 params, no output schema, no annotations), and the description covers what it does, its performance, and safety. The only minor gaps are lack of a stated output format and not explicitly saying it does not modify state beyond 'read-only', which is already implicit. Near-complete for this simplicity tier.

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 has zero parameters, so there is no schema burden. The description establishes that the tool can be invoked anytime with no required inputs and elaborates what the call returns conceptually. This is the appropriate baseline for a parameterless tool.

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 'Snapshot of Termux device health' and enumerates the exact resource categories (RAM, CPU load, disk space, OpenClaw version, gateway reachability, processes). This is a specific verb-resource reading that distinguishes it from siblings like agent_dispatch or file_read; nothing in the sibling list overlaps with health diagnostics.

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 'safe to call any time' gives clear contextual guidance without explicitly naming alternatives. Since it is a read-only zero-parameter diagnostics snapshot with no sibling tool serving a similar role, excluding alternatives is less critical; the guidance is clear enough.

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