Skip to main content
Glama
Logos-Parthenos-AI

MCP-LinkedIn

by Logos-Parthenos-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
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

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions resource cleanup but does not specify irreversibility, side effects (e.g., cookies cleared), or error conditions.

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 one short sentence that conveys the essential purpose without extraneous words. It is appropriately front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with zero parameters and an output schema, the description adequately explains the action and cleanup. No further context is necessary.

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?

There are no parameters, so schema coverage is 100%. The description does not need to add parameter detail; the baseline of 4 is appropriate.

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 action ('Close') and the resource ('current browser session') with additional context ('clean up resources'). It is distinct from sibling tools which are all retrieval operations.

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?

No explicit guidance on when to use versus alternatives. The use case is implied (ending a session), but no 'when not to use' or prerequisite information is given.

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

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description mentions that setting get_employees to true is 'slower', disclosing a behavioral trait. No annotations exist, so the description carries full burden. It does not cover error handling, rate limits, or data freshness, but the core behavior is clear.

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 well-structured with a brief summary followed by Args/Returns docstring. It uses only necessary text, though the docstring format adds slight verbosity.

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's simplicity (2 params, output schema present), the description covers the key aspects: purpose, parameter meanings, return type, and a performance hint. Missing guidance on error cases or prerequisites, but adequate for the complexity.

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 no descriptions (0% coverage), but the description adds meaningful semantics: company_name is clarified as a LinkedIn company name with examples, and get_employees is explained as controlling employee scraping with a performance note.

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 'Get a specific company's LinkedIn profile' with examples like 'docker', 'anthropic', 'microsoft'. It distinguishes from sibling tools like get_person_profile and search_jobs by specifying company focus.

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 does not provide explicit when-to-use or when-not-to-use guidance relative to siblings, though the purpose is clear. It includes parameter details but lacks contextual triggers or alternative tool references.

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
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the job description may be empty if content is protected, which is a valuable behavioral trait. However, it does not mention authentication requirements, rate limits, or potential side effects. Since no annotations are provided, the description carries the full burden; it covers the most important behavioral nuance well.

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 concise, with a clear heading and structured Args/Returns sections. Every sentence adds value: the purpose, parameter explanation, examples, and return structure. There is no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one parameter and an output schema (context signals indicate has_output_schema=true). The description explains the return structure (title, company, location, etc.) and notes the edge case of empty job description. For a simple retrieval tool, this covers all necessary context, leaving no obvious gaps.

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 no description for job_id (0% coverage). The description compensates by providing examples ('e.g., '4252026496', '3856789012''), which adds meaning and clarifies the format beyond the schema's bare type declaration. This helps the agent understand what a valid job ID looks like.

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 action ('Get job details') and the resource ('a specific job posting on LinkedIn'). It distinguishes itself from sibling tools like search_jobs and get_company_profile by focusing on a single posting via a job ID. The verb-resource pair is specific 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is used when you have a specific job ID, but it does not explicitly state when to use it versus alternatives like search_jobs or get_company_profile. There is no guidance on prerequisites or when not to use it, leaving the agent to infer usage context.

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

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Basic read operation described, but lacks disclosure of rate limits, authentication requirements, or error handling. Without annotations, description carries the burden but provides minimal behavioral context.

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?

Extremely concise with front-loaded purpose, clear Args/Returns sections, and no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with an output schema, the description fully explains the parameter and return type, making it complete.

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?

Description adds example and clarifies the parameter format (LinkedIn username), which adds meaning beyond the schema's simple 'string' type.

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?

Clearly states it retrieves a specific person's LinkedIn profile. Differentiates from siblings which deal with companies, jobs, sessions, or searches.

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?

No guidance on when to use this tool versus alternatives. No mention of context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_jobsB

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

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as idempotency, rate limits, authorization requirements, or whether it modifies data. The only behavioral hint is that it is a search (likely read-only), but this is implied rather than explicit.

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 extremely concise: a single sentence followed by a structured Args and Returns section. Every part is necessary and there is no redundant information. It efficiently conveys what the tool does and how to use it.

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 simplicity (one parameter, no nested objects) and the presence of an output schema, the description is adequate but lacks details such as pagination, result limits, or query operators. It covers the basics but leaves some behavioral context unspecified.

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 single parameter 'search_term' is described as 'Search term to use for the job search', which adds basic meaning beyond the schema's property name. However, with 0% schema description coverage, the description only restates the obvious without adding constraints, formatting, or examples.

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 tool's purpose: 'Search for jobs on LinkedIn using a search term.' This provides a specific verb (search) and resource (jobs), and distinguishes it from siblings like 'get_job_details' and 'get_recommended_jobs' which have different functions.

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 offers no guidance on when to use this tool versus alternatives like 'get_recommended_jobs' or 'get_job_details'. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent without contextual decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updates
    • First observedclose_session
    • First observedget_company_profile
    • First observedget_job_details
    • First observedget_person_profile
    • First observedget_recommended_jobs
    • First observedsearch_jobs
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 6 tools

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches