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

Annotations carry no safety hints, but the description discloses critical behavior: the job runs in the background, only one extraction per company runs at a time, re-running updates existing leads without duplicating them, and extraction is capped at LinkedIn's 1000-result ceiling. This materially shapes how an agent should invoke and monitor the tool.

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 tight, front-loaded sentences with no wasted words. Every sentence adds operational value: what it extracts, cap/filter behavior, downstream read/act tools, background execution, and company ID lookup.

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 an async tool with no output schema, the description explains where employees land and how to retrieve/act on them, which is helpful. However, it does not say what the call itself returns or how to check job completion/status, leaving the agent uncertain whether to poll and what a successful invocation looks like.

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 only 25%, so the description must compensate. It adds useful cross-reference for companyId (use campaignstack_list_companies) and gives the LinkedIn ceiling context for maxResults, but it says nothing about workspaceId and does not clarify the default behavior when maxResults is omitted. It partially compensates but leaves gaps.

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: extract a company's employees from its LinkedIn People page, with an explicit cap and optional job-title filter. It also names distinct downstream tools (list_company_employees, add_leads_to_list), so an agent can tell extraction apart from reading or adding leads.

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?

Provides a clear workflow: find company IDs with campaignstack_list_companies, extract here, then read with campaignstack_list_company_employees and act with campaignstack_add_leads_to_list. It also states an important exclusion ('They are NOT added to any lead list'). It does not explicitly contrast with campaignstack_create_company_employee_watch for ongoing monitoring, so it stops short of a 5.

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