list_domains

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

The description provides zero behavioral information. With no annotations provided, the description carries the full burden of disclosing behavioral traits but fails completely. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it returns all domains or a filtered subset, what format the output takes, or any rate limits or constraints. For a tool in what appears to be a security/penetration testing context, this lack of transparency is particularly problematic.

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?

While technically concise with just two words, this is under-specification rather than effective conciseness. The description doesn't front-load important information or provide any structure. It's so minimal that it fails to communicate basic purpose and context. In this case, brevity comes at the cost of clarity and usefulness.

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 complexity implied by the sibling tools (Active Directory/network security enumeration), the lack of annotations, and no output schema, the description is completely inadequate. It doesn't explain what 'domains' means in this context, what the output format will be, or any behavioral characteristics. For a tool that likely returns structured domain information in a security context, this minimal description leaves the agent guessing about fundamental aspects of the tool's operation.

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 0 parameters, and the input schema has 100% description coverage (though with no parameters, this is trivial). The description doesn't need to explain any parameters, and it doesn't incorrectly suggest parameters that don't exist. For a zero-parameter tool, this is adequate, though the description could theoretically mention that no parameters are required.

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 'List domain(s)' is a tautology that essentially restates the tool name 'list_domains'. It doesn't specify what kind of domains (Active Directory domains, network domains, etc.) or provide any meaningful context about the resource being listed. While it does contain a verb ('List') and resource ('domain(s)'), it lacks specificity and doesn't distinguish this tool from its many siblings that also list various Active Directory/network entities.

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 provides absolutely no guidance about when to use this tool versus alternatives. With 100+ sibling tools that perform various listing/enumeration functions in what appears to be an Active Directory/network security context, the agent has no indication whether this is for listing all domains in a forest, trusted domains, or something else. There's no mention of prerequisites, context, or when this tool would be preferred over other listing tools.

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