Loading ToolBench
A Model Context Protocol server for interacting with LinkedIn's API, enabling search for people and jobs, profile retrieval, messaging, and network statistics.
This LinkedIn MCP server has modest tool definitions with present but minimal descriptions and schemas. Most tools follow a verb_noun naming pattern (search-people, get-profile, send-message), which is correct. However, descriptions are generic (averaging ~60 chars, well below the 194-char production baseline) and lack actionable guidance for LLM tool selection. Input schemas are present but sparse: most parameters lack enums or range constraints. Critical gaps: (1) no parameter descriptions in most schemas (violates 'every parameter needs a description'), (2) no output schema documentation (LLMs cannot plan chaining), (3) error handling is non-existent (raw exceptions thrown, no recovery guidance), (4) the send-message tool has no confirmation step despite being destructive. The tool definitions are functional but far from production-grade.
Retrieve the current user connections
Retrieve the current user's LinkedIn profile information
Retrieve network statistics for the current user
Retrieve detailed LinkedIn profile information
Search for LinkedIn job postings based on various criteria
Search for LinkedIn profiles based on various criteria
Parameter descriptions missing from most input schemas. Parameters like 'keywords', 'location', 'currentCompany' in search-people have descriptions in the schema definition, but lack contextual guidance for LLM disambiguation. The schema shows type info but no enums or constraints for valid values.
No output schema documentation. Tool descriptions state what they return (e.g. 'profile', 'jobs') but do not specify the structure, field names, or types of returned data. LLMs cannot plan downstream tool calls or extract required IDs without knowing the output schema.
send-message is a destructive operation (WRITE risk) with no confirmation step, dry-run option, or recovery guidance. An LLM can send unintended messages to arbitrary recipients with no safety mechanism. Description does not warn of irreversibility.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Send a message to a LinkedIn connection
Error handling returns raw exception objects without actionable recovery guidance. When a profile lookup fails, the agent receives an error with no suggestion to use search-people first, or retry with alternative identifiers.
Tool descriptions are too short (averaging 35-40 chars) to disambiguate between similar tools. Example: 'Retrieve detailed LinkedIn profile information' (get-profile) vs 'Retrieve the current user's LinkedIn profile information' (get-my-profile) both describe retrieval, the distinction is subtle and context-dependent. A longer description explaining WHEN to use each would help LLM selection.
Mutually exclusive parameters not documented. In get-profile, both 'publicId' and 'urnId' are optional, the schema does not clarify that one must be supplied, or how the tool behaves if both are provided.
No pagination support visible in search tools (search-people, search-jobs). Schemas accept 'keywords' and 'location' but no limit, offset, or cursor parameters. Large result sets could exhaust context or cause incomplete agent reasoning.
Response transformation in createResourceResponse encodes results as base64 JSON in a URI. This is non-standard; typical MCP tools return structured objects with typed fields. The base64 encoding obscures the response schema and makes it harder for LLMs to parse.