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

Beyond the annotations, the description adds meaningful behavioral information: it does not save to Studio, executes synchronously, is forbidden for task support, returns internal application state, and includes explicit output-handling rules. These details go beyond readOnlyHint/idempotentHint and give the agent a clear picture of side effects and expected response behavior.

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 moderately long but information-dense, with purpose and side-effect statements front-loaded before response-handling guidance. Some redundancy exists with the title and annotations, such as 'read-only' and 'does not save to Studio,' but overall each sentence adds operational value. It could be tightened slightly without losing meaning.

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 description does well for side effects, execution model, and output presentation, and an output schema exists to cover return structure. However, with 7 undocumented parameters and no guidance on when to invoke this tool versus refreshing or retrieving a profile via a canonical sibling, the description is not fully complete for correct invocation.

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 7 parameters with 0% description coverage, so the description carries the full burden of explaining them. It mentions none of the parameters: brandName, brandUrl, seatId, seatName, advertiserId, forceRefresh, or requestedSections. The description merely says 'return a brand profile,' which does not help an agent understand what each parameter controls or how to populate them.

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 opens with a specific verb and resource: 'Research and return a LeanrIQ brand profile.' It also explicitly notes it is a 'Deprecated alias for get_brand_profile,' which directly differentiates it from the sibling tool name and clarifies its relationship. The read-only nature is stated clearly, leaving no ambiguity about what the tool does.

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 clear context: this is a read-only, synchronous, deprecated alias, and it gives response-handling guidance such as using assistantSummary first and avoiding raw JSON display. However, it does not explicitly spell out when to prefer this tool versus get_brand_profile or other research tools, though the 'deprecated alias' statement strongly implies get_brand_profile is the canonical choice.

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