Search LinkedIn Companies

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by specifying that it uses the standard LinkedIn REST API (no SNAP required) and by listing the return fields (company name, industry, size, HQ, website, specialties, description). This goes beyond the schema and annotations, though it does not discuss rate limits or error behavior.

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?

The description is well-structured and front-loaded: opening purpose, API note, parameter list, return fields, and examples. Each section is compact and serves a purpose. The examples are particularly valuable for grounding the tool's intent. No superfluous content or redundancy with the schema beyond what is useful for quick scanning.

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?

Given the tool's complexity (9 parameters, 0 required, no output schema), the description covers all necessary aspects: a clear summary, full parameter semantics, return fields, and usage examples. It even includes a technical note about the API. This is sufficiently complete for an agent to select and invoke the tool without missing critical information.

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?

The schema has 100% description coverage, so the baseline is 3. The description adds value by consolidating parameters into a logical list (e.g., min/max_employees as 'size range') and by providing natural language to parameter mappings in the examples. This helps an agent translate vague user requests into concrete arguments, exceeding what the schema alone provides.

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 clearly states a specific verb and resource: 'Search for companies on LinkedIn by name, industry, size, or geography.' This distinguishes it from tools like gong_search_calls and linkedin_search_leads, but it does not explicitly differentiate from zoominfo_search_company, which also performs company searches. Overall purpose is unambiguous.

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 description provides concrete examples ('SaaS companies in San Francisco' -> keywords='SaaS', geography='San Francisco') that imply how to use the tool, but it lacks explicit guidance on when to choose this tool over alternatives like zoominfo_search_company. There is no mention of exclusions or trade-offs, so usage context is only implied rather than directly stated.

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