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

Goes well beyond the readOnly/openWorld annotations: it discloses per-kind page sizes, that oversized limits are clamped, that paging requires re-calling with identical arguments plus nextCursor, LinkedIn's hard row ceilings (1,000 / 2,500), and that rows consume a daily search allowance (1,000 / 2,500). It even warns that result text is third-party content and must be treated as data, not instructions.

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?

Long but dense — purpose, kind enumeration, filter rules, url alternative, pagination, quotas, fallback tool, and the injection warning each carry operational weight. It reads as a run-on block rather than clearly separated sections, and the alternative-tool routing is buried near the end rather than front-loaded.

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, multi-mode search with nested free-form filters and no output schema, the definition covers everything an agent needs to call it correctly: mode selection, filter validity, id sourcing, pagination protocol, hard ceilings, quota cost, and a safe fallback. Return row counts and per-kind sizing are described even without a formal output schema.

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 100%, so the baseline is 3, but the description adds real semantics the schema cannot express: filter names are kind-dependent and unknown ones are rejected with the allowed list, and place/industry/company/school filters take LinkedIn ids from lookup_search_ids. It also explains the limit-vs-page-size interaction and the cursor argument-stability requirement.

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 ('Search LinkedIn on your OWN account with any of LinkedIn's filters') and enumerates the kind values it dispatches on, so the agent knows the scope. It differentiates from search_people_classic but never explains how it relates to the dedicated siblings search_linkedin_people, search_linkedin_companies, search_linkedin_posts, search_linkedin_sales_navigator_people, etc., which overlap heavily with the `kind` values here.

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?

Gives explicit conditions: use `kind` + `filters`, or alternatively pass a `url` copied from LinkedIn/Sales Navigator/Recruiter, and notes seats are required for sales_navigator/recruiter kinds. It also routes simple keyword/place/degree people searches to search_people_classic. The gap is that the six per-kind search siblings are never mentioned as alternatives or as the simpler choice.

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