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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's job is to add context — and it does: LinkedIn totals include posts not made through PostPen, the figures are observations not causes, and small numbers move a lot by chance. Those caveats materially affect how an agent should interpret and report results. It does not discuss auth, quotas, or latency.

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 description is long but front-loads the core metric list before moving to the per-post detail and the caveats, so the important material arrives first. The explanation of 'vs_usual' (1.3 = 30% above usual) is dense but earns its place for a non-obvious custom metric. A couple of clauses could be tightened, but there is little 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?

There is no output schema, so the description must carry the return contract — and it does, enumerating the account metrics, the percentage change and impressions-per-day derivations, the extra follower fields for personal profiles, and the exact shape of 'recent_posts' including engagement_rate, comment_share, attributes, and the vs_usual normalization. An agent can describe results accurately without guessing.

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?

With a single parameter and 100% schema description coverage, the schema already documents 'days', its 7-90 bounds, the 30-day default, and the equal-length preceding comparison window. The description restates the same windowing logic ('the last N days next to the equally long period before') without adding syntax or format detail beyond the schema. Baseline 3 applies.

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 states a concrete verb and resource with unusual specificity: account-level growth metrics (impressions, reach, reactions, comments, reposts) for the last N days versus the preceding equal period, plus per-post 'recent_posts' data. It is unmistakably distinct from a single-post stats tool in substance, though it never names a sibling (e.g. get_post_stats) to make the boundary explicit.

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 real usage direction: 'Use it to plan content: compare the change in results with the change in how much was posted, then look at which recent posts beat their account's usual.' That is a clear analytic workflow rather than a bare statement of function. It stops short of naming when not to use it or which alternative to pick.

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