MCP-LinkedIn

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: close_session handles session management, get_company_profile and get_person_profile target different entity types, while get_job_details, get_recommended_jobs, and search_jobs cover different job-related operations. The descriptions clearly differentiate between retrieving specific entities versus searching/recommending.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern: close_session, get_company_profile, get_job_details, get_person_profile, get_recommended_jobs, and search_jobs. The pattern is uniform throughout with 'get_' or action verbs followed by descriptive nouns, making the set predictable and readable.
Tool Count4/5
Six tools is a reasonable count for a LinkedIn-focused server, covering core operations like profile retrieval, job search, and session management. It's slightly lean but well-scoped; minor additions like update operations or more entity types could enhance it without being necessary.
Completeness3/5
The toolset covers key read operations for profiles and jobs, but lacks update, create, or delete capabilities typical in social media contexts (e.g., posting updates, sending messages). While agents can retrieve data, they cannot interact or modify content, which limits workflow completeness for a full LinkedIn integration.
Average 3.6/5 across 6 of 6 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the basic action ('search') but lacks details on permissions, rate limits, pagination, or what happens if no jobs are found. For a search tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by separate 'Args' and 'Returns' sections. It's front-loaded and avoids unnecessary fluff, though the 'Returns' section could be more concise given the output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search operation), lack of annotations, and presence of an output schema, the description is minimally adequate. It covers the basic purpose and parameters but misses behavioral details and usage guidelines, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents the single parameter 'search_term' as a string, adding meaning beyond the input schema (which has 0% description coverage). However, it doesn't provide examples, constraints, or formatting details, so it only partially compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 jobs on LinkedIn using a search term.' It specifies the verb ('search'), resource ('jobs'), and platform ('LinkedIn'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_recommended_jobs' or 'get_job_details', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'get_recommended_jobs' or 'get_job_details', nor does it specify any prerequisites or exclusions. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool returns a list of recommended jobs but lacks details on authentication needs, rate limits, personalization criteria, or potential side effects. This is inadequate for a tool that likely requires user context and API constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose in the first sentence and return format in the second. However, the second sentence 'Returns: List[Dict[str, Any]]: List of recommended jobs' is somewhat redundant given the output schema, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values) and no parameters, the description is minimally complete. However, it lacks context on personalization mechanics and doesn't compensate for the absence of annotations, making it adequate but with clear gaps for a tool that likely depends on user-specific data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get your personalized recommended jobs from LinkedIn' specifies the verb (get), resource (recommended jobs), and source (LinkedIn). However, it doesn't differentiate from sibling tools like 'search_jobs' or 'get_job_details', which would require explicit comparison to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_jobs' or 'get_job_details'. It mentions 'personalized recommended jobs' but doesn't clarify the context (e.g., based on user profile, recent activity) or exclusions, leaving the agent without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that 'get_employees' is slower, which is useful behavioral context. However, it lacks details on rate limits, authentication requirements, error handling, or whether this is a read-only operation (implied by 'Get' but not explicit). The description doesn't contradict any annotations, but it's incomplete for a tool that likely involves web scraping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the purpose clearly. The 'Args' and 'Returns' sections are organized efficiently, with no wasted words. Every sentence adds value, such as the note on speed for 'get_employees', making it concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, 0% schema coverage, no annotations, but has an output schema), the description is reasonably complete. It explains the parameters and return type ('Structured data from the company's profile'), and the output schema handles return values. However, it could improve by addressing authentication, error cases, or sibling tool differentiation to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'company_name' is explained as 'LinkedIn company name' with examples, and 'get_employees' is clarified with its effect on speed. This goes beyond the bare schema, though it doesn't cover all potential nuances like format constraints or default behavior details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a specific company's LinkedIn profile.' It specifies the verb ('Get') and resource ('company's LinkedIn profile'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'get_person_profile' or 'get_job_details', though the resource type (company vs. person/job) is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_person_profile' for individual profiles or 'search_jobs' for job-related queries. There's no context about prerequisites, such as needing a LinkedIn session or authentication, which could be relevant given the sibling 'close_session'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's destructive nature ('close' and 'clean up') which is helpful, but lacks details about what exactly gets destroyed, whether this action is reversible, authentication requirements, or error conditions. The description doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core action first ('close the current browser session') followed by the secondary effect ('clean up resources'). Every word serves a purpose with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations but an output schema exists, the description provides adequate context about what the tool does. It covers the main action and cleanup effect, though more behavioral details would be helpful. The existence of an output schema means return values are documented elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this. No additional parameter information is needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('close') and target ('current browser session'), and mentions the additional effect of 'clean up resources'. It distinguishes from sibling tools which are all data retrieval operations. However, it doesn't specify what type of browser session or what resources are being cleaned up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'current browser session', suggesting this should be used when a session is active and needs termination. However, it provides no explicit guidance about when to use this tool versus alternatives (none exist among siblings) or prerequisites for successful execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states what the tool does (retrieves profile data) and mentions the return format, but doesn't disclose authentication needs, rate limits, privacy considerations, or what happens with invalid usernames. The description adds basic context but lacks important operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with a clear purpose statement followed by organized Args and Returns sections. Every sentence earns its place by providing essential information without redundancy. The formatting with clear sections makes it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return value documentation) and only one parameter, the description provides adequate context. It explains what the tool does and provides parameter examples, though it could benefit from more behavioral context about authentication or error handling for a profile lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides a clear example of the single parameter ('stickerdaniel', 'anistji') that helps understand the expected format, though it doesn't explain username validation rules or where to find usernames. This adds meaningful value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'specific person's LinkedIn profile', making the purpose explicit. It distinguishes from siblings like get_company_profile and get_job_details by specifying it's for a person's profile rather than company or job data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it's for retrieving a specific person's profile, but doesn't explicitly state when to use this versus alternatives like search_jobs or get_recommended_jobs. It's clear this is for looking up individual profiles rather than broader searches or job listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that job descriptions 'may be empty if content is protected', which is valuable behavioral context. However, it doesn't mention authentication requirements, rate limits, error conditions, or data freshness - leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with clear sections: purpose statement, Args with detailed parameter explanation, and Returns with comprehensive output description. Every sentence adds value with zero redundancy. The information is front-loaded and efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and an output schema exists, the description does excellent work explaining both input and output semantics. However, for a LinkedIn API tool with no annotations, it could better address authentication, rate limits, or common error scenarios to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate fully. It provides excellent parameter semantics: defines job_id as 'LinkedIn job ID' with concrete examples ('4252026496', '3856789012'), clarifying format and purpose beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get job details'), target resource ('for a specific job posting on LinkedIn'), and distinguishes it from siblings like get_recommended_jobs (list) and search_jobs (search). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for a specific job posting' and listing sibling tools, but doesn't explicitly state when to use this vs. alternatives like search_jobs. It provides clear scope but lacks explicit comparison or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![linkedin-mcp-server MCP server](https://glama.ai/mcp/servers/Logos-Parthenos-AI/linkedin-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Logos-Parthenos-AI/linkedin-mcp-server)

Score Badge

Copy to your README.md:

[![linkedin-mcp-server MCP server](https://glama.ai/mcp/servers/Logos-Parthenos-AI/linkedin-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Logos-Parthenos-AI/linkedin-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Logos-Parthenos-AI/linkedin-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server