list_client_domains

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

With no annotations provided, the description carries full responsibility for disclosing behavior, but it only states what the returned data represents. It does not mention that the operation is read-only, whether the client must exist, pagination, ordering, or error behaviors. The description adds no transparency beyond the input schema.

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 very short and free of fluff, but it is an incomplete sentence fragment rather than a structured statement. It conveys a single piece of information but lacks the polish of a fuller, well-structured description. It is concise but not necessarily well-formed.

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 absence of an output schema and annotations, the description must explain what the tool returns and how it behaves, but it only states that the result is a client's domains. There is no information on return format, pagination, or error scenarios. For a simple tool this is a minimal but incomplete definition; an agent might correctly call it but cannot anticipate the response shape or failure modes.

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 input schema fully describes the only parameter (clientid) with a baseline description, and schema coverage is 100%. The tool description adds no additional meaning to the parameter, so the baseline of 3 is appropriate. The agent can infer that clientid identifies the client whose domains are listed, but no format or edge-case details are given.

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 identifies a specific resource (domains) and scope (one client), indicating the tool's purpose from context. However, it is a noun phrase, not a verb-driven statement, so the operation (list) must be inferred from the tool name rather than the description. It does not explicitly differentiate itself from sibling tools, though the domain focus makes it distinct.

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 provided about when to use this tool versus alternatives such as list_client_services or get_client. There are no stated conditions, prerequisites, or exclusions. An agent must rely entirely on the tool name and schema to infer suitability.

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