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

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false. The description adds real value beyond that by clarifying 'Nothing is re-authenticated or sent' — an agent learns no OAuth flow is triggered and no outbound messages occur, which is not derivable from the structured fields. It still omits permission requirements and side effects on campaigns referencing an unlinked account.

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 tight sentences with no filler; the action is front-loaded and the clarifying constraint follows immediately. Every sentence earns its place.

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?

An output schema exists, so return values need no explanation and the workspaceId resolution rules are covered in the schema. However, for a mutation tool the description never says what happens to downstream artifacts when an account is unlinked, nor does it mention the 25-operation batch limit — meaningful omissions, though the annotations carry the safety profile adequately.

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?

Coverage is 50%: the schema fully documents workspaceId including the cs_/csu_ key rules, while the operations array carries no description. The description adds nothing about parameter semantics — it doesn't explain op values, the 25-operation cap, or what accountId must reference — though the nested enums and maxItems make operations largely self-describing, so the gap is real but not severe.

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 pair (link/unlink) plus the resource (already-connected LinkedIn/Google accounts in a workspace), which is concrete enough to act on. The word 'already-connected' implicitly separates it from campaignstack_connect_account, but no sibling is named, so the differentiation is left to inference.

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 phrase 'already-connected' implies the tool is only for re-associating existing accounts, suggesting connect_account handles new connections, but this is never stated and no condition or alternative is named. Usage is implied rather than guided, and nothing says when *not* to use it.

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