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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real context beyond them: a platform restriction ('LinkedIn accounts only') and a quota/cost signal ('Counts as browsing'), which an agent needs in order to budget calls. It stops short of describing result shape or pagination, which is acceptable given the tool's simplicity.

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?

Four short sentences with no filler, and the platform restriction is front-loaded. The phrasing is slightly telegraphic ('Use an id as as_organization', 'Counts as browsing'), which costs a little clarity but not space.

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?

For a one-parameter read-only list tool with full annotation coverage and no output schema, the description supplies platform scope, quota implications, and the downstream use of the returned ids. The main remaining gap is that it never explains the account_id input or hints at what fields each page entry contains.

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 schema has a single account_id at 0% description coverage, so the description must carry that weight. It implies the parameter by saying 'this account' and 'LinkedIn accounts only', but never states that account_id is the account whose pages are listed or what format it takes. The reference to 'an id' concerns output values, not the input parameter.

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 names the resource precisely ('The LinkedIn company pages this account administers'), which is a specific scoped list rather than a tautology. It implicitly contrasts with get_company (a single page) by framing this as the set the account administers, though it never states that distinction explicitly.

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 forward guidance on what to do with the results ('Use an id as as_organization in create_post to publish as the page'), which is genuinely useful routing. However, it says nothing about when to choose this tool over get_company or any other page-related sibling, so the when-to-use decision is only implied by the phrase 'this account administers'.

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