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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world, so the safety profile is settled. The description adds meaningful behavioral context beyond that: the data windows ('yesterday', 'last 7 days vs previous week', 'Meta campaigns (7 days)') and recurring 'this morning's brief', which tell the agent about data recency and aggregation scope. It does not discuss latency or response size for this aggregate call, which keeps it at 4.

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?

One dense sentence, front-loaded with what the tool is before the enumeration of contents. The long comma/slash list is information-rich rather than padded, but the parenthetical recommendation types ('losing_campaign, stock_out, low_sale_offer...') make it harder to scan than a short bulleted framing would.

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 and no parameters, the description carries the full burden of describing return values, and it does so thoroughly, covering every section and the recommendation categories. What is missing is any notion of the response shape (e.g. nested keys or sections) beyond the comma-separated enumeration, and whether the view is scoped to the authenticated partner.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the call is parameterless by describing a fixed snapshot rather than any filtering options.

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?

It clearly identifies the resource as a composite 'partner's personal AI manager view' and enumerates exactly what it contains (yesterday's orders/earnings, 7-day comparisons, promoted offers with sale rate and stock, Meta campaigns, suggested offers, prioritized recommendations, morning brief). This is specific enough to distinguish it as an aggregate dashboard read versus the granular siblings. It stops short of naming which siblings (get_stats, list_campaigns, search_offers) it replaces, so 5 is not warranted.

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?

Usage is implied by 'today's overview' and 'this morning's brief', signaling a morning-check-in / daily-dashboard call. However, there is no explicit when-to-use, when-not-to-use, or statement that this should be preferred over calling get_stats plus list_campaigns individually. The routing decision is left to inference from sibling names.

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