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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds substantive behavioral constraints beyond them, namely the inclusive 95-calendar-day cap, the 100-item pagination ceiling implied elsewhere, and the rule to recompute ratios from summed base metrics rather than averaging. This is useful operational context an agent would otherwise get wrong. It does not describe output shape, but an output schema exists.

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 purpose is front-loaded in a single strong sentence, but roughly half the text is dedicated to keyword-ranking-trend and campaign-scheduling limits that are irrelevant to this tool and inflate the definition. Sentences like 'This reporting limit does not apply to campaign scheduling dates' spend tokens without helping the caller. The useful window-splitting rule could be stated in one sentence instead of several.

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 a full input schema, an output schema, and read-only annotations, the definition covers the remaining gap, namely the hard 95-day window limit and the ratio-recomputation rule, which are the mistakes an agent would realistically make. Nothing essential about calling the tool is missing. It loses a point for padding with rules belonging to adjacent tools rather than fully owning its own scope.

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 description coverage is 100%, so all nine parameters including storeId format, date formats, dimension enum, and limit/offset are already fully documented in the schema. The description adds only indirect meaning by naming the supported granularities (SKU, ASIN, parent ASIN, store level), which maps loosely to the dimension enum. Baseline 3 applies when the schema does the heavy lifting.

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 opening sentence gives a specific verb and resource: store-level profit summaries or paginated profit data by SKU, ASIN, or parent ASIN, scoped to one store and a date range. It is clearly a read/reporting tool distinct from diagnose_profit_anomaly or query_sales, though it never names those siblings to reinforce the distinction. The remainder of the description drifts into date-window policy rather than reinforcing what the tool returns.

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?

There is real usage guidance for splitting long ranges into non-overlapping windows and an explicit prohibition against averaging ratios like ACOS/ROAS across windows. However, several guidelines (keyword ranking trends at 90/31 days, campaign scheduling dates, advertising write plans) belong to other sibling tools and do not help an agent decide when to use query_profit. The guidance is contextual but unfocused for this specific tool.

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