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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds behavior the annotations cannot: the response shape changes materially when `area` is supplied (area findings, Plans, work, outputs, headline numbers) versus the whole-store view. It does not mention permissions, auth or payload size, which are the remaining gaps.

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?

Three short sentences, front-loaded with the tool's purpose, then the parameter-dependent mode, then the usage cue. The long enumeration in sentence one is dense but every item is informative content rather than filler.

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?

With no output schema, the description must carry the burden of telling the agent what comes back, and the enumerated contents largely do that for both the whole-store and area-scoped modes. Zero required parameters and a simple two-field schema mean little else is needed; a note on response size or ordering would complete it.

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 100%, so both parameters are already documented, including the enum values and the 'omit when only one is connected' note for `store`. The description still adds meaning beyond the schema by explaining what `area` actually changes in the returned content, which the enum list alone does not convey.

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 ('Read a store's overview') and then enumerates the contents it returns: business context, standing memory, Google connection, pending work, Plans, recommendations and recent results. That is far more than a restatement of the name. It stops short of naming a sibling it is distinct from (e.g. get_store_insights or get_store_performance), so the boundary against those is left implicit.

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?

'Use for a brief or before planning work' gives a concrete decision context for reaching for this tool first. The 'With `area` ...' clause also explains the scoped mode. There are no explicit exclusions or 'use X instead when...' routing, which keeps it below a 5.

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