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

Adds real behavioral context beyond the annotations: a hard rate limit (10 questions per brand per day, shared with the app), the closed-world data source ('saved account data only'), and confirmation of non-mutation. The 'never changes anything' clause partially restates destructiveHint=false, but the quota and data-source scoping are genuinely additive.

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?

Four dense sentences, each earning its place (purpose, data grounding, no-side-effects, quota), with the purpose front-loaded. No filler or repetition.

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 2-param advice tool with no output schema and rich annotations, the description covers what it answers from, what it returns (steps you can apply), what it won't do, and the rate limit. Coverage is strong; only the routing vs. sibling data tools is left implicit.

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 50% – brand_id is documented in the schema with its fallback behavior, while question has only length constraints. The description adds meaning for question by specifying 'plain English,' signaling free-form natural language rather than a structured query, but does nothing for brand_id beyond what the schema already says.

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 (ask) and resource (the consultant) about a specific scope (this brand), which cleanly distinguishes it from the get_*/list_* siblings that retrieve structured data. An agent can tell this is a natural-language advice tool rather than a data fetcher without opening the schema.

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 establishes clear context: use it for plain-English advice grounded in saved account data, and it 'advises only and never changes anything.' It doesn't explicitly name an alternative (e.g., use get_performance for raw metrics), so the when-not routing is implied rather than stated.

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