hosts_add

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

With no annotations, the description provides useful behavioral details: no restart required, managed section for independent listing/removal/clearing. However, it omits potential side effects like overwriting existing entries, permission requirements, or validation of input.

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 concise and well-structured: purpose, benefits, arguments with format, return description, and examples. Every sentence adds value without redundancy.

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's simplicity (two required parameters, no nested objects, output schema exists), the description covers the key aspects. It explains the operation, effects, and usage. Missing minor details like error handling or duplicate handling, but overall adequate.

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 schema has 0% description coverage, so the description compensates well. It explains 'ip' as a target IP with an example, and 'hostnames' as space or comma separated names with examples. This adds significant meaning beyond the bare schema.

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 states that the tool adds hostname(s) to /etc/hosts. It uses a specific verb ('Add') and resource ('/etc/hosts on the Kali container'), and the sibling tool names (hosts_clear, hosts_list, hosts_remove) differentiate this from related operations.

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 explains that no container restart is needed and that entries are tracked in a managed section for independent management. It implies use for adding hostnames, while siblings handle other actions. However, it lacks explicit when-not-to-use or alternative guidance.

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