Check the current status of USB devices connected to the router. Use this read-only tool to verify whether USB storage or modems are detected and active.
USB device status (read-only)
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'read-only', which is a minimal safety signal. It does not mention whether the command requires special privileges, what happens if no USB device is present, whether it returns a list or a summary, or any error conditions. For a status tool, this is a significant gap.
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 a single, concise sentence that front-loads the key fact (USB status) and adds the read-only qualifier. There is no fluff or redundancy. It is appropriately sized for a zero-parameter tool.
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?
Given the tool has no parameters and no output schema, the description is minimal but adequate for a basic status check. However, the presence of sibling tools like usb_disk and usb_temp means the description should clarify what aspect of USB status it covers to avoid ambiguity. It does not, so the agent may need to inspect siblings or guess. The description is not incomplete enough to be unusable, but it lacks specificity.
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 the schema fully covers parameter documentation (100% coverage). The description adds nothing about parameters, but none are needed. According to the baseline, 0 params merits a 4; the description does not introduce any confusion or omission.
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 clearly identifies the resource (USB device) and action (status), and notes it is read-only. It is not a tautology, but it is generic—'status' could mean many things, and it does not distinguish from sibling tools like usb_disk or usb_temp, which may also report device state. A more specific term (e.g., 'enumerated devices', 'health') would raise clarity.
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?
No guidance is given on when to use this tool versus alternatives. The description only states it is read-only, which implies safe usage, but does not explain what kind of USB status it provides or when to prefer it over usb_disk or usb_temp. An agent is left to guess which tool to invoke based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.