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

Annotations already cover the safety profile (readOnly, non-destructive, not open-world), and the description adds substantial context on top: it is DB-backed and instant and does not query LinkedIn, rows are capped by limit with total as the full count, statsScope indicates whether stats are per-account or blended, and the 25% acceptance threshold is explicitly framed as an internal heuristic that pauses nothing. This is exactly the kind of behavior an agent needs and cannot infer from 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?

Front-loaded with the core action, then routing, then output/limit semantics, then the policy caveat — a logical order with no wasted sentences. It runs five sentences and is denser than strictly necessary, but each one carries information an agent would otherwise lack.

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, the description carries the burden of explaining returns and does so: one row per connection, capped row count with a separate total, and a stats block (pending, rolling weekly sent, 14-day acceptance rate) whose scope is reported via statsScope. It also flags the cross-account scoping caveat, so an agent has what it needs to call and interpret the tool correctly.

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 description coverage is 100%, so every parameter is already documented (limit default/max, status enum, sessionId/sessionLabel scoping, campaignId). The description restates the limit/total relationship and the per-account vs install-wide stats distinction, but the schema's own sessionLabel description already carries that meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource ('List the invites this system tracks, one row per campaign connection') along with the optional status/campaign filtering and the accompanying account-health stats. It also explicitly names the siblings it is not (li_pending_invites for LinkedIn's own list, li_poll_acceptances for recording acceptances), so an agent can distinguish it without opening any schema.

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?

Explicit routing: use li_pending_invites for LinkedIn's own pending list including hand-sent invites, and li_poll_acceptances to record new acceptances first. It also states the operational policy context (the 25% threshold is 'OUR operating policy, not a LinkedIn-published rule') and how to report it, which is genuine usage guidance rather than filler.

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