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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real context beyond that: it returns only the account owner's posts and discloses the base64-style ID format. It omits pagination behavior and result size, and the stray Instagram reference is potentially misleading.

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?

Purpose is front-loaded in the first sentence, but the body is a dense run of colon-delimited fragments, and the 'Post ID' block plus the irrelevant instagram_list_user_posts reference consume space without earning it for a LinkedIn resolver.

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 only a partial description of the return ('Returns the account owner's posts; ... reuse result.id'), the description should explain the result shape and how offset/pagination work. It covers the resolve workflow adequately but leaves the return contract and paging semantics underspecified.

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 50% (account_id documented, offset not). The description's 'Post ID' section actually describes the returned result.id, not a parameter, and never explains the offset parameter or pagination. It therefore fails to compensate for the uncovered parameter, adding no meaning beyond what the schema already provides for 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?

States a specific verb+resource ('Resolve ... into exact post IDs') and clarifies scope ('Returns the account owner's posts'), which separates it from linkedin_get_post. However, citing instagram_list_user_posts as an ID source in a LinkedIn-only tool muddies the resource boundary and slightly undercuts clarity.

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?

Gives clear context ('before comments/reactions/edit/delete') and names concrete alternatives for obtaining an ID (linkedin_search_posts, linkedin_list_user_posts) plus an explicit 'Never pass' exclusion. It does not explicitly contrast with linkedin_get_post or the other resolver siblings, so it stops short of full when/when-not routing.

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