hook_status

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by explaining what the returned trigger counts mean and how to interpret a zero-count case, which is genuine behavioral context. It does not cover whether a session must be open, though.

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: the first states what the tool returns, and the second pre-emptively explains how to interpret the counts. It is tightly front-loaded with no 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?

With no parameters and no output schema, the description covers the essential: what is listed and how to read the counts. The one gap is that it does not state any prerequisite, such as an active game session or an attached process, which the sibling set (open_game, inject_process) suggests is relevant.

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, so the parameter-semantics baseline is 4. There is nothing parameter-related for the description to clarify, and it correctly does not pad with parameter talk.

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 gives a concrete verb and resource: '列出当前所有 Hook 及其触发次数' (list all current Hooks and their trigger counts). This clearly distinguishes the tool from the action-oriented siblings hook_method, hook_address, and unhook. It does not explicitly name a sibling, but the resource is specific enough to make the distinction obvious.

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 gives a concrete diagnostic scenario: use the trigger counts to judge whether a Hook was installed correctly, and a zero count on a per-frame method indicates a wrong target. This is clear usage context, though it does not mention what to do instead or which alternative tool to use when the diagnosis fails (for example, find_hook_target or drain_events).

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