router_get_time

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

With no annotations, the description carries the full burden; 'retrieves' implies a read-only operation and the Network Guard mention reveals a safety gate exists. However it never explains what Network Guard is, why the call would be blocked, or what changes when force=True — meaningful gaps for a tool with zero annotation coverage.

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 tight sentences with the resource list front-loaded and a compact Args block; nothing is padded. Slightly weakened by the unexplained jargon 'Network Guard' doing the work of the only behavioral disclosure.

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 described, and the read scope is clear. What remains thin is the safety-bypass semantics: for a tool with no annotations, an agent needs to know the risk of setting force=True and this is only named, not explained.

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 coverage is 0% and the schema only says boolean default false, so the description must compensate. It does add real meaning — force bypasses a Network Guard safety check — but leaves 'Network Guard' undefined and gives no indication of consequences or when bypassing is warranted.

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 (retrieves) and a concrete set of resources (system clock, time zone, DST, NTP server status), which is clearly distinguishable from siblings like router_set_dns or router_get_status. It does not, however, differentiate itself from router_sync_time, the sibling most likely to be confused with it.

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 statement of when to call this versus router_sync_time, and no prerequisites or exclusions. The only usage-adjacent text is the note that force bypasses Network Guard, which explains a parameter but not when the tool itself is appropriate.

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