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

With no annotations, the description carries the burden and does disclose real behavioral traits: refresh incurs a latency cost because it hits the platforms first, and results render as an interactive panel whose contents should not be duplicated. It omits auth/permission requirements and any staleness/pagination behavior, so it isn't fully exhaustive.

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?

Front-loaded with the core purpose, followed by the refresh tradeoff, then the rendering instruction — a logical order. The panel-response directive is wordy ('do NOT repeat its contents as a list or table in your reply') but earns its place by preventing redundant output.

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 annotations, the description compensates by enumerating the return shape (totals plus per-platform breakdowns) and covering the refresh semantics and host-dependent rendering. Adequate for an agent to call and interpret it, though auth/permission context and metric freshness defaults are absent.

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 only 50% (the refresh boolean has no schema description), so the description must compensate — and it does, explaining that refresh: true pulls fresh platform metrics and is slower. The days parameter adds little beyond the schema's 7–90 range and default, but the uncovered parameter is well handled.

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?

Combines a specific verb (get/retrieve analytics) with a precise resource (the user's published posts) and names the returned payload: totals for views, likes, comments and shares plus per-platform breakdowns. This clearly distinguishes it from siblings like get_post or list_posts, which return post data rather than aggregated performance metrics.

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?

Explains the refresh: true tradeoff (pulls fresh metrics from platforms first, slower) and gives an explicit when-to-do-what instruction for reply formatting in app-capable hosts. It stops short of naming alternatives or exclusions, but the operative context for invoking it correctly is present.

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