Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@linkedin-web-scrapper-mcp-server find software engineers in San Francisco"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides LinkedIn web scraping capabilities as tools for AI assistants. This server uses Playwright to automate LinkedIn people search and extract profile information, exposing these capabilities through the MCP protocol.
MCP Tool Integration: Exposes LinkedIn scraping as MCP tools for AI assistants
People Search: Search LinkedIn profiles using keywords, location, and network filters
Profile Extraction: Extract profile names, URLs, and headlines from search results
Session Management: Automatic LinkedIn login with cookie persistence
Adaptive Selectors: Handles LinkedIn UI changes with multiple CSS selector strategies
Network Filtering: Filter by connection degree (1st, 2nd, 3rd+ connections)
Location Support: Filter by location using LinkedIn's geoUrn codes or location strings
Related MCP server: LinkedIn MCP Server
Clone the repository:
git clone https://github.com/Phicks-debug/linkedin-web-scrapper.git
cd linkedin-web-scrapper-mcp-serverInstall dependencies:
npm installInstall Playwright browsers:
npx playwright installConfigure your LinkedIn credentials:
cp config.example.json config.jsonThen edit config.json with your LinkedIn credentials:
{
"linkedin": {
"email": "your-linkedin-email@email.com",
"password": "your-linkedin-password"
},
"browser": {
"headless": false,
"slowMo": 1000,
"cookiesPath": "./cookies.json"
}
}Build the server:
npm run buildThis server is designed to be used with MCP-compatible AI assistants. The server exposes LinkedIn scraping functionality through the MCP protocol.
# Start the server (connects via stdio)
node dist/index.js
# For development with auto-rebuild
npm run watchTest the server using the MCP Inspector:
npm run inspectorsearch-linkedin-peopleSearch for LinkedIn profiles using web scraping.
Input Schema:
{
"keywords": "software engineer", // Required: Keywords to search for
"location": "105646813", // Optional: Location filter (geoUrn or location string)
"network": "F" // Optional: Network degree filter
}Network Filter Options:
"F" - 1st degree connections only
"S" - 2nd degree connections
"O" - 3rd+ degree connections (out of network)
Location Examples:
"105646813" - Spain (using LinkedIn geoUrn)
"San Francisco" - Location string
Default: "104195383" if not specified
Response Format:
{
"success": true,
"count": 10,
"profiles": [
{
"name": "John Doe",
"profileUrl": "https://www.linkedin.com/in/johndoe",
"headline": "Senior Software Engineer at Tech Company"
}
],
"filters": {
"keywords": "software engineer",
"location": "105646813",
"network": "F"
}
}Add this server to your Claude Desktop MCP configuration:
{
"mcpServers": {
"linkedin": {
"command": "node",
"args": ["/path/to/linkedin-web-scrapper-mcp-server/dist/index.js"],
"cwd": "/path/to/linkedin-web-scrapper-mcp-server"
}
}
}The server follows the standard MCP protocol and can be used with any MCP-compatible client by connecting to the stdio transport.
MCP Protocol: Exposes LinkedIn scraping as standardized MCP tools
Browser Automation: Uses Playwright to control Chrome/Chromium browser
Session Persistence: Saves LinkedIn session cookies to avoid repeated logins
People Search: Navigates to LinkedIn people search with specified filters
Profile Extraction: Extracts profile data using adaptive CSS selectors
Structured Output: Returns JSON-formatted results via MCP protocol
Script | Description |
| Compile TypeScript and make executable |
| Watch mode for development |
| Launch MCP Inspector for testing |
| Build and run the server |
├── index.ts # Main MCP server implementation
├── config.json # LinkedIn credentials and browser settings
├── cookies.json # Saved session cookies (auto-generated)
├── package.json # MCP server configuration
└── dist/ # Compiled JavaScript outputLocal Credentials: Your LinkedIn credentials are stored locally in config.json
Session Cookies: Saved locally in cookies.json for session persistence
No Data Transmission: No data is sent anywhere except to LinkedIn for scraping
Browser Automation: Uses a visible browser window to avoid detection
Protocol: Model Context Protocol (MCP) 0.6.0
Runtime: Node.js with TypeScript
Browser Engine: Playwright with Chromium
Transport: Standard I/O (stdio) for MCP communication
Target: LinkedIn People Search API
The server handles common scenarios:
Automatic LinkedIn login when session expires
LinkedIn security challenges (requires manual intervention)
UI changes through adaptive selectors
Network timeouts and connection issues
LinkedIn Terms: Use responsibly and respect LinkedIn's terms of service
Rate Limiting: Avoid excessive requests to prevent detection
Manual Challenges: Security challenges require manual completion
UI Dependencies: May need updates if LinkedIn significantly changes their UI
MIT License - see LICENSE file for details.
Fork the repository
Create a feature branch
Make your changes
Test with MCP Inspector
Submit a pull request
For issues and feature requests, please use the GitHub issues page.
Scrape comprehensive data from a specific LinkedIn profile URL. Returns detailed profile information including experience, education, skills, licenses & certifications, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| profileUrl | Yes | The LinkedIn profile URL to scrape (e.g., 'https://www.linkedin.com/in/username/') |
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 describes what data is returned (experience, education, etc.) but does not disclose potential side effects, limitations (e.g., profile privacy, rate limits), or authentication requirements. For a scraping tool, such context is important but missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences clearly state the action and the output categories. No filler or unnecessary repetition. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no output schema, the description adequately explains the return values by listing key sections. However, it lacks any caveats about scraping LinkedIn (e.g., profile must be public, potential blocks) which would be valuable for completeness, but the tool is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter (profileUrl) 100%, including an example. The description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific action ('Scrape comprehensive data from a specific LinkedIn profile URL') and the resource. It distinguishes from the sibling tool 'search-linkedin-people' by emphasizing 'specific URL' versus search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: scrape when you have a specific LinkedIn profile URL. However, it does not explicitly state when not to use it or mention the alternative sibling tool (search-linkedin-people) for finding profiles. This is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for LinkedIn profiles using web scraping. Returns profile names, URLs, and headlines.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network degree filter: 'F' = 1st degree connections, 'S' = 2nd degree connections, 'O' = 3rd+ degree connections | |
| keywords | No | Keywords to search for in profiles (e.g., 'AI engineer', 'data scientist') | |
| location | No | Location filter - can be a location string (e.g., 'San Francisco') or LinkedIn geoUrn code (e.g., '105646813' for Spain). Default: '104195383' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'web scraping' and the return fields, but lacks important context such as whether authentication is required, rate limits, pagination, or potential failures. The absence of such details leaves the agent with significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately meaningful and front-loaded. Every word contributes to the understanding of the tool's function and output, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and no annotations, the description is too brief. It omits critical context such as the expected number of results, whether results are paginated, and any limitations of web scraping. The information provided is not enough for an agent to confidently rely on this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all three parameters with descriptions. The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 LinkedIn profiles using web scraping.' The verb 'search' and resource 'LinkedIn profiles' are specific, and the method 'web scraping' sets it apart from the sibling tool 'scrape-linkedin-profile', which implies a different action on a specific profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling 'scrape-linkedin-profile'. While the name implies searching versus scraping, there is no explicit mention of alternatives, prerequisites, or cases where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0scrape-linkedin-profilesearch-linkedin-peopleThe two tools have clearly distinct purposes: one discovers profiles via search, the other extracts detailed data from a specific profile URL. There is no overlap in functionality.
Both tools follow a consistent verb_noun pattern using 'search-linkedin-people' and 'scrape-linkedin-profile', maintaining the same structure and style.
With only two tools, the server is minimal but each serves a necessary step in the LinkedIn people-scraping workflow. The count feels slightly thin, yet it aligns with the focused purpose of the server.
The tools form a complete flow: search for profiles and then scrape any selected profile. Minor gaps exist (e.g., no company or job search), but for a people-focused scraper, the core lifecycle is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search LinkedIn & Sales Navigator. Get structured people, companies, posts, jobs data. 4.9/5 on G2.
Stealth scraping & search. Bypasses Cloudflare, DataDome & LinkedIn via Cyborg HITL approach.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Phicks-debug/linkedin-web-scrapper-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
