get_ip_route

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

With no annotations, the description carries the full behavioral burden. Naming the read-oriented `ip route show` and `ip -6 route show` commands and the SSH transport is useful, but authentication requirements, timeout/failure behavior, and the implications of accepting a new host key are not disclosed.

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 single sentence is front-loaded with the operation and resource, then efficiently adds the commands, route contents, platform, and transport. The parenthetical is dense but contains substantive information and 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?

The output schema reduces the need to describe return values, and the description is sufficient to understand the tool's overall job. However, for a seven-parameter SSH tool with no annotations and undocumented schema fields, the missing authentication, connection, and host-key guidance leaves meaningful invocation gaps.

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 0%, and the description only indirectly clarifies `host` and the SSH-related parameters by specifying a remote Linux host accessed via SSH. It does not explain `user`, authentication selection between `key_path` and `password`, `timeout` units or scope, or `accept_new_hostkey`, leaving most of the seven parameters without semantic guidance.

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 uses a specific verb and resource: it collects IPv4 and IPv6 routing tables, including default gateways and per-interface routes, from a remote Linux host. The exact commands and scope make the purpose clear, although it does not explicitly differentiate itself from sibling collectors.

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 references to routing tables, a remote Linux host, and SSH provide clear context for when this tool is applicable. It offers no explicit when-not-to-use guidance or alternatives, which keeps it below the highest score.

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