Monitor Npu

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it says almost nothing: no mention of required permissions, what happens on hardware lacking an NPU, polling cost, or whether host/profile resolution affects the result. It is a read-style monitor call, but the description never even asserts that.

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?

A single short sentence with zero filler, front-loading the action and target. It is efficient, though brevity here shades into under-specification rather than deliberate conciseness.

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 need not be explained, and the operation itself is a simple read. Still, with no annotations and four session-resolution parameters, the description leaves auth/session behavior and NPU-availability assumptions entirely unstated.

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 100%, with host, port, scheme, and profile all documented in the schema itself, so the baseline is 3. The description adds no additional meaning (e.g., that parameters are optional and fall back to the default session) beyond what the schema already states.

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 (查看/view) and resource (NPU 使用率/NPU usage rate), which an agent can easily distinguish from monitor_cpu, monitor_memory, and monitor_gpu. However, it offers no explicit differentiation from its sibling monitor tools, relying on the name alone to do that work.

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 guidance on when to use this tool versus monitor_cpu/monitor_gpu, no mention that it is only meaningful on hosts with an NPU, and no note about authentication or session prerequisites. The agent must infer all usage context from the tool name.

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