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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses concrete operational constraints an agent could not otherwise know: 100 searches per day, a minimum 15-second gap, 10 results per page / ~1,000 total on classic people or company search versus 25 per page / ~2,500 on Sales Navigator or Recruiter, and that each page counts as one search against the quota.

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 account constraint and the four searchable categories, then filters, then plan/limit mechanics. It is dense but nearly every clause carries information; the rate-limit sentence is somewhat run-on and packed with several distinct facts in one line.

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 a complex open-world search tool with no output schema and undocumented schema parameters, the definition covers the essentials: what can be searched, how to construct filters, how plans change behavior, and the paging and quota model. An agent can invoke it correctly without further context.

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?

With 0% schema description coverage and 8 parameters including a nested filters object, the description carries the load well: it explains the filters object shape with a concrete example and points to list_search_parameters for valid IDs, describes url as a copied LinkedIn search link, ties api to plan-specific behavior, and maps category to the four entity types. account_id and cursor receive no explicit explanation, which keeps this from a 5.

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 names a specific action and its object: find people, companies, posts or jobs, with keywords, filters or a copied LinkedIn URL, and scopes it to LinkedIn accounts. It is clearly a search/lookup tool rather than a single-entity fetch such as get_profile or get_company, though it does not name those siblings explicitly.

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?

It states the intent (find the right person) and gives an explicit exclusion against list-building for unsolicited messaging, plus it routes the agent to list_search_parameters for filter IDs. It stops short of spelling out when to choose api=classic versus sales_navigator versus recruiter, which is left to the plan wording.

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