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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds one real behavioral fact beyond that: the results include posts published outside PilotControl, which tells the agent the data is not limited to tool-managed activity. It does not explain how 'recent' is bounded, whether results are paginated, or whether the call can be slow or rate limited for a live network fetch.

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?

A single dense sentence with no filler; the identifier pair is front-loaded ahead of the returned fields. The parenthetical placement is slightly awkward but nothing is redundant. Slightly more structure would help an agent scan the returned metrics.

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 characterize the return value, and it does reasonably well by listing followers, totals, and recent posts with metrics. What is missing for a read-only analytics tool is the boundary of 'recent', the shape of the metric payload, and any differentiation from get_account_insights, leaving the agent to discover scope by calling 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 description coverage is only 33% — brand_id is well documented in the schema itself, but account_id and platform carry no descriptions. The description partially compensates by stating both come from list_accounts, establishing they form a compound key from an external source. It does not clarify the platform format (the ^[a-z]{1,20}$ pattern, e.g. 'instagram') or what happens if the platform does not match the account_id.

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?

Names the resource precisely (the channel of a connected account identified by account_id + platform) and enumerates the payload: followers, totals, and recent network publications with their metrics. That is far more than a restatement of the title. It stops short of a 5 because the verb is implicit and it never names get_account_insights or get_post_stats, which are the closest siblings an agent must choose between.

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?

It gives one genuinely useful operational pointer — take account_id and platform from list_accounts — which tells the agent how to obtain required inputs. However, there is no statement of when this tool should be preferred over get_account_insights, get_post_stats, or get_brand_overview, all of which sit adjacent in the catalog. Usage is implied by the noun phrase rather than stated.

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