A Model Context Protocol (MCP) server for LinkedIn integration
The server provides 9 tools with basic definitions and reasonable input schemas, but has significant gaps in parameter descriptions, lacks output schema documentation, and missing error handling guidance. Tool naming is generally acceptable (verb-noun format), but parameter descriptions are sparse and insufficient for LLM decision-making. No tool has comprehensive descriptions, most are 1-2 lines that don't explain when/why to use them or what the output contains. Parameter annotations exist but many lack details about constraints, formats, or dependencies.
Comment on a LinkedIn post
Create a new LinkedIn post with optional media
Delete a LinkedIn post
Get posts from your LinkedIn feed
Get details of a specific LinkedIn post
Get your LinkedIn profile information
Like a LinkedIn post
Minimal parameter descriptions. Parameters like 'text' in create_post, 'commentary' in share_post, and 'postUrn' across multiple tools lack detail about format, constraints, or usage context. LLMs cannot reliably infer whether postUrn requires a specific format or how it differs from postId.
No output schema documentation. Tools return JSON responses (per code: JSON.stringify(post, null, 2)), but definitions do not specify what fields are included in responses. This forces LLMs to guess at the structure and cannot verify downstream field dependencies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Share an existing LinkedIn post
Test the LinkedIn MCP Server connection
Ambiguous parameter naming and absence of clarification. Multiple tools use both 'postId' (delete_post, get_post) and 'postUrn' (share_post, create_comment, like_post) to reference posts, but descriptions do not explain the difference or when to use each. This invites parameter confusion.
Insufficient error handling guidance. Tool implementations catch errors (e.g., testLinkedInConnection returns error messages), but the definitions do not describe what errors are possible, when they occur, or how the agent should respond. This breaks error classification and recovery patterns.
Missing guidance for multi-step operations. create_post accepts optional mediaPath and mediaType, but no description explains the dependency: mediaType is only valid if mediaPath is provided. Agents may pass one without the other.
No destructive operation confirmation pattern. delete_post removes content irreversibly, but tool definition lacks any confirmation step or dry-run capability. Agents can accidentally destroy posts without safeguards.
Pagination not addressed in get_feed. Description offers default count=10 and max=100, but does not explain pagination strategy for iterating beyond the limit or whether there is a cursor/offset mechanism. Large feeds cannot be fully retrieved.