A LinkedIn MCP server to find jobs, search people, research companies, manage your network, publish and engage with posts, and read or send messages.
Server has 5 tools with mostly complete schemas and descriptions. Tool naming follows verb_noun convention (search, get, list, status). Descriptions are present but vary in quality, some are detailed (linkedin.jobs.search at ~280 chars), others are truncated or minimal (linkedin.jobs.get description cuts off mid-sentence). All tools declare input schemas with proper JSON Schema types, constraints (minLength, maxLength, pattern, enum), and field descriptions. However, parameter descriptions are sparse in some tools (e.g., linkedin.jobs.get lacks description for 'job_id' parameter). Output schemas are not documented in the visible code. Error handling via ToolError is present but generic, no recovery guidance or categorization. Tool annotations (readOnlyHint) are declared but not visible in the schema definitions shown.
List installed capabilities and whether runtime policy enables each one.
Read one current visible LinkedIn job by numeric ID, including its primary h
Search current visible LinkedIn Jobs pages with optional keywords and typed location, Date posted, sorting, distance, workplace, experience, job type, company, industry, function, title, benefit, commitment, Easy Apply, verification, applicant-count, network, and Fair Chance filters. Hydrates LinkedIn's virtualized result cards and returns one deduplicated cursor page.
Return non-secret server configuration and readiness metadata.
Return non-secret browser-session state for the configured account.
linkedin.jobs.get description is truncated ('Read one current visible LinkedIn job by numeric ID, including its primary h...'), incomplete and does not explain what fields are returned or when to use it vs search.
linkedin.jobs.get input schema lacks 'job_id' parameter description, only context_id and request_id are documented. LLM cannot infer what job_id represents or its format.
Output schemas not documented in visible code. LLMs cannot plan downstream tool calls or extract required fields (e.g., does linkedin.jobs.search return job_id for use in linkedin.jobs.get?).
Error handling is generic (ToolError with code + message). No recovery guidance, categorization (retryable vs user-fixable), or actionable next steps for LLM.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Tool annotations (readOnlyHint) declared in features but not visible in schema definitions. Unclear if they are properly attached to tool definitions for LLM consumption.