Skip to main content
Glama
Logos-Parthenos-AI

MCP-LinkedIn

by Logos-Parthenos-AI
OverviewSchemaRelated ServersScoreDiscussions
Hybrid

LinkedIn MCP Server

Through this LinkedIn MCP server, AI assistants like Claude can connect to your LinkedIn. Give access to profiles and companies, get your recommended jobs, or search for keywords. All from a Docker container on your machine.

Installation Methods

Docker Install DXT Extension uvx Development

https://github.com/user-attachments/assets/eb84419a-6eaf-47bd-ac52-37bc59c83680

Related MCP server: LinkedIn MCP Server

Usage Examples

What are my recommended jobs I can apply to?
Research the background of this candidate https://www.linkedin.com/in/stickerdaniel/
Get this company profile for partnership discussions https://www.linkedin.com/company/inframs/
Suggest improvements for my CV to target this job posting https://www.linkedin.com/jobs/view/4252026496

Features & Tool Status

TIP

  • Profile Scraping (get_person_profile): Get detailed information from a LinkedIn profile including work history, education, skills, and connections

  • Company Analysis (get_company_profile): Extract comprehensive company information from a LinkedIn company profile name

  • Job Details (get_job_details): Retrieve specific job posting details using LinkedIn job IDs

  • Job Search (search_jobs): Search for jobs with filters like keywords and location

  • Recommended Jobs (get_recommended_jobs): Get personalized job recommendations based on your profile

  • Session Management (close_session): Properly close browser session and clean up resources

NOTE

July 2025: All tools are currently functional and actively maintained. If you encounter any issues, please report them in theGitHub issues.

🐳 Docker Setup (Recommended - Universal)

Prerequisites: Make sure you have Docker installed and running.

Installation

Client Configuration:

{
  "mcpServers": {
    "linkedin": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "LINKEDIN_COOKIE",
        "stickerdaniel/linkedin-mcp-server:latest"
      ],
      "env": {
        "LINKEDIN_COOKIE": "li_at=YOUR_COOKIE_VALUE"
      }
    }
  }
}

Getting the LinkedIn Cookie

  1. Open LinkedIn and login

  2. Open Chrome DevTools (F12 or right-click → Inspect)

  3. Go to Application > Storage > Cookies > https://www.linkedin.com

  4. Find the cookie named li_at

  5. Copy the Value field (this is your LinkedIn session cookie)

  6. Use this value as your LINKEDIN_COOKIE in the configuration

Run the server with the --get-cookie flag:

docker run -it --rm \
  stickerdaniel/linkedin-mcp-server:latest \
  --get-cookie

Copy the cookie from the output and set it as LINKEDIN_COOKIE in your client configuration. If this fails with a captcha challenge, use the method above.

NOTE

The cookie will expire during the next 30 days. Just get the new cookie and update your client config. There are also many cookie manager extensions that you can use to quickly copy the cookie.

Docker Setup Help

Transport Modes:

  • Default (stdio): Standard communication for local MCP servers

  • Streamable HTTP: For a web-based MCP server

CLI Options:

  • --log-level {DEBUG,INFO,WARNING,ERROR} - Set logging level (default: WARNING)

  • --no-lazy-init - Login to LinkedIn immediately instead of waiting for the first tool call

  • --transport {stdio,streamable-http} - Set transport mode

  • --host HOST - HTTP server host (default: 127.0.0.1)

  • --port PORT - HTTP server port (default: 8000)

  • --path PATH - HTTP server path (default: /mcp)

  • --get-cookie - Attempt to login with email and password and extract the LinkedIn cookie

  • --cookie {cookie} - Pass a specific LinkedIn cookie for login

  • --user-agent {user_agent} - Specify custom user agent string to prevent anti-scraping detection

HTTP Mode Example (for web-based MCP clients):

docker run -it --rm \
  -e LINKEDIN_COOKIE="li_at=YOUR_COOKIE_VALUE" \
  -p 8080:8080 \
  stickerdaniel/linkedin-mcp-server:latest \
  --transport streamable-http --host 0.0.0.0 --port 8080 --path /mcp

Test with mcp inspector:

  1. Install and run mcp inspector bunx @modelcontextprotocol/inspector

  2. Click pre-filled token url to open the inspector in your browser

  3. Select Streamable HTTP as Transport Type

  4. Set URL to http://localhost:8080/mcp

  5. Connect

  6. Test tools

Docker issues:

  • Make sure Docker is installed

  • Check if Docker is running: docker ps

Login issues:

  • Ensure your LinkedIn cookie is set and correct

  • Make sure you have only one active LinkedIn session per cookie at a time. Trying to open multiple sessions with the same cookie will result in a cookie invalid error.

  • LinkedIn may require a login confirmation in the LinkedIn mobile app for --get-cookie

  • You might get a captcha challenge if you logged in a lot of times in a short period of time, then try again later or follow the local setup instructions to run the server manually in --no-headless mode where you can debug the login process (solve captcha manually)

📦 Claude Desktop (DXT Extension)

Prerequisites: Claude Desktop and Docker installed

One-click installation for Claude Desktop users:

  1. Download the DXT extension

  2. Double-click to install into Claude Desktop

  3. Set your LinkedIn cookie in the extension settings

Getting the LinkedIn Cookie

  1. Open LinkedIn and login

  2. Open Chrome DevTools (F12 or right-click → Inspect)

  3. Go to Application > Storage > Cookies > https://www.linkedin.com

  4. Find the cookie named li_at

  5. Copy the Value field (this is your LinkedIn session cookie)

  6. Use this value as your LINKEDIN_COOKIE in the configuration

Run the server with the --get-cookie flag:

docker run -it --rm \
  stickerdaniel/linkedin-mcp-server:latest \
  --get-cookie

Copy the cookie from the output and set it as LINKEDIN_COOKIE in your client configuration. If this fails with a captcha challenge, use the method above.

NOTE

The cookie will expire during the next 30 days. Just get the new cookie and update your client config. There are also many cookie manager extensions that you can use to quickly copy the cookie.

DXT Extension Setup Help

Docker issues:

  • Make sure Docker is installed

  • Check if Docker is running: docker ps

Login issues:

  • Ensure your LinkedIn cookie is set and correct

  • Make sure you have only one active LinkedIn session per cookie at a time. Trying to open multiple sessions with the same cookie will result in a cookie invalid error.

  • LinkedIn may require a login confirmation in the LinkedIn mobile app for --get-cookie

  • You might get a captcha challenge if you logged in a lot of times in a short period of time, then try again later or follow the local setup instructions to run the server manually in --no-headless mode where you can debug the login process (solve captcha manually)

🚀 uvx Setup (Quick Install - Universal)

Prerequisites: Make sure you have uv installed.

Installation

Run directly from GitHub without cloning:

# Run directly from GitHub (latest version)
uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server linkedin-mcp-server --help

# Run with your LinkedIn cookie
uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server linkedin-mcp-server --cookie "li_at=YOUR_COOKIE_VALUE"

Getting the LinkedIn Cookie

  1. Open LinkedIn and login

  2. Open Chrome DevTools (F12 or right-click → Inspect)

  3. Go to Application > Storage > Cookies > https://www.linkedin.com

  4. Find the cookie named li_at

  5. Copy the Value field (this is your LinkedIn session cookie)

  6. Use this value as your LINKEDIN_COOKIE in the configuration

Run the server with the --get-cookie flag:

uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server \
  linkedin-mcp-server --get-cookie

Copy the cookie from the output and set it as LINKEDIN_COOKIE in your client configuration. If this fails with a captcha challenge, use the method above.

NOTE

The cookie will expire during the next 30 days. Just get the new cookie and update your client config. There are also many cookie manager extensions that you can use to quickly copy the cookie.

uvx Setup Help

Client Configuration:

{
  "mcpServers": {
    "linkedin": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/stickerdaniel/linkedin-mcp-server",
        "linkedin-mcp-server"
      ],
      "env": {
        "LINKEDIN_COOKIE": "li_at=YOUR_COOKIE_VALUE"
      }
    }
  }
}

Transport Modes:

  • Default (stdio): Standard communication for local MCP servers

  • Streamable HTTP: For web-based MCP server

CLI Options:

  • --log-level {DEBUG,INFO,WARNING,ERROR} - Set logging level (default: WARNING)

  • --no-lazy-init - Login to LinkedIn immediately instead of waiting for the first tool call

  • --transport {stdio,streamable-http} - Set transport mode

  • --host HOST - HTTP server host (default: 127.0.0.1)

  • --port PORT - HTTP server port (default: 8000)

  • --path PATH - HTTP server path (default: /mcp)

  • --get-cookie - Attempt to login with email and password and extract the LinkedIn cookie

  • --cookie {cookie} - Pass a specific LinkedIn cookie for login

  • --user-agent {user_agent} - Specify custom user agent string to prevent anti-scraping detection

Basic Usage Examples:

# Run with cookie from environment variable
LINKEDIN_COOKIE="YOUR_COOKIE_VALUE" uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server linkedin-mcp-server

# Run with cookie via flag
uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server linkedin-mcp-server --cookie "YOUR_COOKIE_VALUE"

# Run with debug logging
uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server linkedin-mcp-server --log-level DEBUG

# Extract cookie with credentials
uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server linkedin-mcp-server --get-cookie

HTTP Mode Example (for web-based MCP clients):

uvx --from git+https://github.com/stickerdaniel/linkedin-mcp-server linkedin-mcp-server \
  --transport streamable-http --host 127.0.0.1 --port 8080 --path /mcp

Test with mcp inspector:

  1. Install and run mcp inspector bunx @modelcontextprotocol/inspector

  2. Click pre-filled token url to open the inspector in your browser

  3. Select Streamable HTTP as Transport Type

  4. Set URL to http://localhost:8080/mcp

  5. Connect

  6. Test tools

Installation issues:

  • Ensure you have uv installed: curl -LsSf https://astral.sh/uv/install.sh | sh

  • Check uv version: uv --version (should be 0.4.0 or higher)

Cookie issues:

  • Ensure your LinkedIn cookie is set and correct

  • Cookie can be passed via --cookie flag or LINKEDIN_COOKIE environment variable

  • Make sure you have only one active LinkedIn session per cookie at a time

Login issues:

  • LinkedIn may require a login confirmation in the LinkedIn mobile app for --get-cookie

  • You might get a captcha challenge if you logged in a lot of times in a short period

🐍 Local Setup (Develop & Contribute)

Prerequisites: Chrome browser and Git installed

ChromeDriver Setup:

  1. Check Chrome version: Chrome → menu (⋮) → Help → About Google Chrome

  2. Download matching ChromeDriver: Chrome for Testing

  3. Make it accessible:

    • Place ChromeDriver in PATH (/usr/local/bin on macOS/Linux)

    • Or set: export CHROMEDRIVER_PATH=/path/to/chromedriver

    • if no CHROMEDRIVER_PATH is set, the server will try to find it automatically by checking common locations

Installation

# 1. Clone repository
git clone https://github.com/stickerdaniel/linkedin-mcp-server
cd linkedin-mcp-server

# 2. Install UV package manager
curl -LsSf https://astral.sh/uv/install.sh | sh
uv python # install python if you don't have it

# 3. Install dependencies and dev dependencies
uv sync
uv sync --group dev

# 4. Install pre-commit hooks
uv run pre-commit install

# 5. Start the server once manually
# You will be prompted to enter your LinkedIn credentials, and they will be securely stored in your OS keychain
# Once logged in, your cookie will be stored in your OS keychain and used for subsequent runs until it expires
uv run -m linkedin_mcp_server --no-headless --no-lazy-init

Local Setup Help

CLI Options:

  • --no-headless - Show browser window (debugging)

  • --log-level {DEBUG,INFO,WARNING,ERROR} - Set logging level (default: WARNING)

  • --no-lazy-init - Login to LinkedIn immediately instead of waiting for the first tool call

  • --get-cookie - Login with email and password and extract the LinkedIn cookie

  • --clear-keychain - Clear all stored LinkedIn credentials and cookies from system keychain

  • --cookie {cookie} - Pass a specific LinkedIn cookie for login

  • --user-agent {user_agent} - Specify custom user agent string to prevent anti-scraping detection

  • --transport {stdio,streamable-http} - Set transport mode

  • --host HOST - HTTP server host (default: 127.0.0.1)

  • --port PORT - HTTP server port (default: 8000)

  • --path PATH - HTTP server path (default: /mcp)

  • --help - Show help

HTTP Mode Example (for web-based MCP clients):

uv run -m linkedin_mcp_server --transport streamable-http --host 127.0.0.1 --port 8000 --path /mcp

Claude Desktop:

{
  "mcpServers": {
    "linkedin": {
      "command": "uv",
      "args": ["--directory", "/path/to/linkedin-mcp-server", "run", "-m", "linkedin_mcp_server"]
    }
  }
}

Login/Scraping issues:

  • Use --no-headless to see browser actions (captcha challenge, LinkedIn mobile app 2fa, ...)

  • Add --no-lazy-init to attempt to login to LinkedIn immediately instead of waiting for the first tool call

  • Add --log-level DEBUG to see more detailed logging

  • Make sure you have only one active LinkedIn session per cookie at a time. Trying to open multiple sessions with the same cookie will result in a cookie invalid error. E.g. if you have a logged in browser session with a docker container, you can't use the same cookie to login with the local setup while the docker container is running / session is not closed.

ChromeDriver issues:

  • Ensure Chrome and ChromeDriver versions match

  • Check ChromeDriver is in PATH or set CHROMEDRIVER_PATH in your env

Python issues:

  • Check Python version: uv python --version (should be 3.12+)

  • Reinstall dependencies: uv sync --reinstall

Feel free to open an issue or PR!

Acknowledgements

Built with LinkedIn Scraper by @joeyism and FastMCP.

⚠️ Use in accordance with LinkedIn's Terms of Service. Web scraping may violate LinkedIn's terms. This tool is for personal use only.

Star History

License

This project is licensed under the Apache 2.0 license.

Available Tools

6 tools
close_sessionA

Close the current browser session and clean up resources.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
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.

get_company_profileA

Get a specific company's LinkedIn profile.

Args: company_name (str): LinkedIn company name (e.g., "docker", "anthropic", "microsoft") get_employees (bool): Whether to scrape the company's employees (slower)

Returns: Dict[str, Any]: Structured data from the company's profile

ParametersJSON Schema
NameRequiredDescriptionDefault
company_nameYes
get_employeesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
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.

get_job_detailsA

Get job details for a specific job posting on LinkedIn

Args: job_id (str): LinkedIn job ID (e.g., "4252026496", "3856789012")

Returns: Dict[str, Any]: Structured job data including title, company, location, posting date, application count, and job description (may be empty if content is protected)

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
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.

get_person_profileA

Get a specific person's LinkedIn profile.

Args: linkedin_username (str): LinkedIn username (e.g., "stickerdaniel", "anistji")

Returns: Dict[str, Any]: Structured data from the person's profile

ParametersJSON Schema
NameRequiredDescriptionDefault
linkedin_usernameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
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.

search_jobsC

Search for jobs on LinkedIn using a search term.

Args: search_term (str): Search term to use for the job search.

Returns: List[Dict[str, Any]]: List of job search results

ParametersJSON Schema
NameRequiredDescriptionDefault
search_termYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.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.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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