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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so 'Read-only' is largely redundant. The genuinely additive part is that domain ownership changes and validation happen outside this tool in the Aidelly app, clarifying the boundary of what this call can affect, but there is no info on required permissions or return shape.

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 sentences, zero waste, with the payload contents front-loaded before the scope-boundary note. Nothing repeated or padded.

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?

For a zero-required-parameter read tool with no output schema, the description adequately covers what is returned and what the tool cannot do. It falls short only on naming the sibling update tool and clarifying how brand_id scopes the result.

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 67%: workspace_id and query are documented in the schema, but brand_id has no description anywhere. The phrase 'the agency's ... configuration' hints at brand/agency scoping but adds no format or selection guidance for brand_id, so baseline 3 is appropriate.

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 and resource ('Read the agency's white-label branding configuration') and enumerates the notable payload fields (custom-domain verification status, DNS instructions). The read-only framing implicitly distinguishes it from the sibling aidelly_update_white_label_config, though that sibling is never named.

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 statement that 'Custom domains are changed and verified in the Aidelly app' implicitly tells the agent this tool is not the mutation path, which is useful routing guidance. However, it never explicitly names aidelly_update_white_label_config as the alternative or states prerequisites such as which identifiers are needed.

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