health_check

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

With no annotations, the description carries the full burden. It does disclose that deep=true involves actual API calls to verify vision capability, which is a meaningful behavioral detail. However, it does not state whether the tool is read-only, what the return structure is, or whether network access is required. The transparency is moderate.

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 concise, with a single front-loaded sentence stating the tool's purpose, followed by a clear Args section for the parameter. No unnecessary prose.

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 description covers the core purpose and the one parameter well. Given the low complexity (one boolean), it is mostly adequate. However, it does not describe the expected output format or return values, and with no output schema or annotations available, the agent may remain uncertain about how to interpret the results.

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 schema only lists a boolean 'deep' with no description, and schema description coverage is 0%. The description compensates fully by explaining that deep controls whether to perform a deeper check involving actual API calls to verify visual abilities. This unambiguously clarifies the parameter's purpose.

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 explicitly states it checks the availability of a specific list of components (oMLX, VLM, MinerU, PaddleOCR, etc.), which satisfies 'specific verb+resource'. This clearly distinguishes health_check from sibling tools that focus on GUI observation, vision inspection, parsing, transcription, and actions.

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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention pre-flight validation scenarios or exclude cases where a deep check is unnecessary. The only hint is the 'deep' parameter explanation, which implies deeper verification but does not offer usage context.

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