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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), the description explicitly labels the operation a 'public side effect' and requires user approval, which adds consent and visibility context. It does not contradict the annotations.

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?

Two front-loaded sentences state function, scope, side effect, and approval requirement without redundancy. Every sentence adds information needed for safe invocation.

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?

Combined with the schema's detailed parameter descriptions and the annotations, the description covers target identity, approval, and public side effects. It does not describe return values or defaults for can_read/can_comment, but those are minor for invoking this tool successfully.

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 main description only elaborates post_as ('managed company page' and 'target identity'), while the schema already carries strong descriptions for post_as, account_id, and quoted_post_id. With 50% schema coverage, the tool definition gives enough parameter meaning overall, but the free-text description itself does little to compensate for the undocumented parameters.

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 uses a specific verb ('Publish') with a concrete resource ('a LinkedIn post') and clarifies the account scope: the user's own account or a managed company page via post_as. This clearly separates it from nearby social/list/comment tools even without naming a sibling.

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?

The description sets an explicit precondition: use only after the user has clearly approved the final content and target identity. It does not name an alternative tool, but the approval trigger and public side-effect warning are enough to guide appropriate invocation.

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