LinkedIn Intelligence MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes important behavioral traits: the search priority system (Fresh Data API vs linkedin-api), cost implications ('requires Pro plan $45/mo'), and technical limitations ('may be blocked by LinkedIn bot detection'). It also specifies what the tool returns ('list of matching profiles with name, title, location, and profile URL').

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 with clear sections (Args, Note, Returns, Search priority) and front-loads the core purpose. It's appropriately sized for a tool with 4 parameters and complex behavioral context. Some sentences could be more concise, but overall it's efficient and organized.

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 (search with multiple filters, dual API backend, cost implications) and 0% schema description coverage, the description is remarkably complete. It covers purpose, parameters, limitations, return values, and implementation details. With an output schema present, it doesn't need to explain return format in detail, but still provides useful context about what fields are included.

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, the description fully compensates by providing detailed parameter semantics. It explains all 4 parameters: 'keywords' as 'General search keywords', 'limit' with default and max values, 'keyword_title' with examples, and 'keyword_company' as 'Filter by company name'. The description adds significant value beyond the bare schema.

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 the tool's purpose: 'Search for people on LinkedIn.' It specifies the resource (people) and verb (search), but doesn't explicitly differentiate from sibling tools like 'search_companies' or 'search_jobs' beyond the resource type. The description is specific but lacks explicit sibling comparison.

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 clear context about when to use this tool: for searching people on LinkedIn. It explicitly states limitations ('Location/region filters are not supported') which helps guide usage. However, it doesn't mention alternatives or when not to use it relative to sibling tools like 'get_profile' or 'batch_get_profiles'.

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