Skip to main content
Glama
outpost2026

linkedin-mcp-custom

by outpost2026
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

🤖 linkedin-mcp-analyzer

LinkedIn saved jobs → EROI scoring → structured reports → git-committed market intelligence

Automated pipeline that scrapes your LinkedIn saved jobs, scores them against your profile using a 6-dimension EROI model, and writes actionable reports. Anti-bot aware — uses human-like patterns to avoid detection.

Python 3.12+ MCP Tests License: MIT

🔍 What problem does this solve?

LinkedIn's job recommendations are noisy. Of 71 saved jobs analyzed, only 6% were relevant (SLEDOVAT/follow). The rest are noise — AI hype roles, fake-engineer titles, distant locations, non-strategic employers.

This tool replaces manual scrolling with a cache-aware, anti-bot pipeline:

📌 Your LinkedIn saved jobs (71 tracked)
   ↓
🔄 Skip-existing filter          ← 95% reduction (only new jobs scraped)
   ↓
🕷️ Sequential scraper (30s, no parallelism)  ← anti-bot — human rhythm
   ↓
📊 EROI scoring engine           ← 6 dimensions, YAML-configured weights
   ↓
📝 KB write-back                 ← metadata_stacku.json + agregovany_report.md
   ↓
📈 Synthetic market analysis     ← Frequency matrix + SNR + gap detection
   ↓
📦 Auto-committed to KB          ← git commit with full history

Related MCP server: LinkedIn-Posts-Hunter-MCP-Server

✨ Features

Feature

What it does

Cache-aware scraping

Skips jobs already in KB (--skip-existing) — 95% time reduction

Anti-bot pattern

Sequential scraping (no parallelism), random delay 3-7s, fingerprint mix

Adaptive delay

Speeds up on success (0.95×), slows on errors (1.5×) — self-tuning

Session heartbeat

Refreshes LinkedIn auth every N jobs — prevents mid-run session expiry

3-layer YAML config

Source (max_pages) / Runtime (delay, timeout) / Analysis (N profiles)

Configurable EROI

--profile industrial switches thresholds + weights from YAML

Fingerprint mix

Random viewport, user-agent, locale, timezone per browser launch

6-dimension EROI scoring

Domain (35%), Tech (25%), Role (20%), Growth (10%), Formal (5%), Location (5%)

Fake-engineer detection

Identifies roles with "Engineer" in title but service/sales content

Synthetic report

Frequency matrix + SNR + gap detection + cluster analysis

Raw text cache

Stores raw job text in KB for re-scoring with different profiles

Git commit

Every pipeline run auto-commits to your knowledge base

🚀 Quick Start

Prerequisites

  • Python 3.12+

  • uv (faster pip alternative — pip install uv)

Install

git clone https://github.com/outpost2026/linkedin-mcp-custom.git
cd linkedin-mcp-custom
uv sync

Authenticate (one-time)

.\linkedin-mcp.bat --login
# Opens a browser window — log into LinkedIn, then press Enter

Verify session

.\linkedin-mcp.bat --status
# ✅ Session valid  |  page.url = https://www.linkedin.com/feed/

Run the pipeline

# Full pipeline (scrapes only new jobs, skips existing KB entries)
.venv\Scripts\python scripts\run_pipeline.py --skip-existing

# Fast mode (reduced delays, no fingerprint — for quick tests)
.venv\Scripts\python scripts\run_pipeline.py --skip-existing --fast

# Partial run (first 15 jobs — for testing)
.venv\Scripts\python scripts\run_pipeline.py --limit 15

# Custom config + analysis profile
.venv\Scripts\python scripts\run_pipeline.py --config ~/.linkedin-mcp-custom/config.yaml --profile industrial

# Via MCP client
.\linkedin-mcp.bat
# Then in your MCP client: call analyze_saved_jobs

Output: agregovany_report.md + metadata_stacku.json + synteticky_report.md in your KB directory.

YAML Configuration

The pipeline uses a 3-layer YAML config (~/.linkedin-mcp-custom/config.yaml):

user: "default"
source:
  max_pages: 10                      # how many tracker pages to scan
runtime:
  headless: true
  delay_range: [3.0, 7.0]           # anti-bot delay between jobs
  page_timeout_ms: 30000
  session_heartbeat: 30              # refresh auth every N jobs
  fingerprint_mix: true              # random viewport/UA/locale
analysis:
  default:                           # baseline EROI profile
    thresholds: { sledovat: 65, medium: 50, hranicni: 40 }
    weights: { domain: 0.35, tech: 0.25, role: 0.20, growth: 0.10, formal: 0.05, location: 0.05 }
  industrial:                        # custom profile — switch via --profile industrial
    thresholds: { sledovat: 70, medium: 55, hranicni: 45 }
    weights: { domain: 0.50, tech: 0.20, role: 0.15, growth: 0.05, formal: 0.05, location: 0.05 }

📊 Example output (from 71 real jobs)

PIPELINE REPORT
============================================================
Conclusion: ok
Duration: 142.31s total
Job IDs found: 71 (70 already in KB, 1 new)
Jobs scored: 1
Errors: 0

Verdicts: {'SLEDOVAT': 2, 'MEDIUM': 8, 'HRANICNI': 3, 'NESLEDOVAT': 2}

Full report: synteticky_report_analyza.md

🧠 EROI Scoring Model

6 dimensions

Dimension

Weight

What it measures

Domain

35%

Industrial automation (core) vs adjacent vs noise

Tech

25%

Skill overlap — content-aware match ratio × coverage

Role

20%

Engineering role vs "fake engineer" (service/sales)

Growth

10%

Strategic employer (Siemens, ABB, Thermo Fisher…)

Formal

5%

Degree requirements with flexibility detection

Location

5%

Remote/hybrid/CZ vs distant/office-only

Thresholds

Score

Verdict

≥65%

🟢 SLEDOVAT (follow — apply now)

50–64%

🟡 MEDIUM (consider — mitigate gaps)

40–49%

🟡 HRANIČNÍ (borderline — only if time permits)

<40%

🔴 NESLEDOVAT (skip — no time allocation)

Special patterns detected

  • Fake engineer: title says "Engineer" but content is service/sales → penalizes role

  • Electronics manufacturing SMT/PCBA: caps domain score (adjacent, not core)

  • Degree flexibility: "equivalent practical experience" found → adds ~5% to formal

  • Positioning match: strong role match compensates for weak domain

  • No-match penalty: tech score drops sharply when key skills missing

🛠️ MCP Tools

Tool

Description

analyze_saved_jobs

Full pipeline: scrape → EROI score → KB write → git commit

get_saved_jobs

List all saved job IDs from LinkedIn tracker

get_job_details <id>

Full posting text for a single job ID

analyze_job <id>

EROI score a single job (avoids timeout)

check_session

Verify LinkedIn auth status with diagnostics

Timeout strategy: analyze_saved_jobs uses time-budgeted batch processing (default 45s). For full analysis, use the CLI pipeline or call analyze_job per job.

📁 Output structure

B2B-Knowledge-Base/
└── 02_ANALYZY/
    └── 00_linkedin/
        ├── agregovany_report.md          # Human-readable EROI entries
        ├── metadata_stacku.json          # Machine-readable (schema v1.1)
        └── synteticky_report_analyza.md  # Market intelligence report

🧪 Development

# Tests
.venv\Scripts\python -m pytest tests/ -v

# Lint
.venv\Scripts\python -m ruff check src/

# Type check
.venv\Scripts\python -m mypy src/

Debugging known issues

See the pitevni_kniha (autopsy book) for 28 documented bugs, root causes, fixes, and engineering rules.

Known issue

Status

MCP transport timeout for batch ops

✅ Fixed (time-budget + per-job tool)

Cookie lifecycle — silent expiry

✅ Fixed (session cache + checkpoint detection)

KB dedup fallback (industry=None)

✅ Fixed

Summary table non-idempotent

✅ Fixed

Pagination missing pages

✅ Fixed

CSS selector fragility

✅ Fixed

Refactor branch regression (34% → 100%)

✅ Fixed (new baseline branch)

Anti-bot vs. speed tradeoff

✅ Configurable (--fast, --profile)

Redundant scraping of known jobs

✅ Fixed (--skip-existing)

🤝 Contributing

PRs welcome! This project especially needs:

  • CI/CD pipeline — GitHub Actions for weekly scraping

  • Docker deployment — containerize the MCP server

  • More scorers — add dimensions (salary, benefits, team size)

  • UI — simple dashboard for browsing scored jobs

  • Translations — localize EROI labels for your market

Please read CONTRIBUTING.md first (coming soon).

📄 License

MIT — see LICENSE.

📈 Next iterations

Iterační backlog odvozený z 29 bug post-mortem záznamů a obscura-inspired pattern transferu. Každý návrh s hodnocením přínos/riziko.

#

Návrh

Přínos

Riziko

Doporučení

1

Optimalizovat page-turn na trackeru — zkrátit wait_for_timeout(17000) nebo najít specifický selector pro detekci načtení

↓40% času (ušetří ~60-80s)

Nízké — rychlejší navigace, stále sekvenční

✅ Teď — nejvyšší poměr přínos/riziko

2

Parallel per-job scraping — asyncio.gather s N kontexty

3-5× rychlejší (↓20-30s místo ~110s)

Vysoké — emergentní bot fingerprint (Z025) už jednou spadl z 98% na 34%

❌ Počkat na lepší anti-bot strategii

3

CI/CD weekly scrape — rozchodit GitHub Actions workflow

Plně automatický monitoring

Střední — cookie export (Z021) vyžaduje ruční refresh každých pár týdnů

⏳ Po stabilizaci skórovacího profilu

4

Synthetic report 2.0 — trend analýza, skill gap evoluce, časové řady

Vyšší vypovídací hodnota než statický snapshot

Nízké — jen nová analytická vrstva

⏳ Vyžaduje 2-3 historické snapshoty

5

Multi-portál (Jobs.cz, Profesia) — nový scraper per obscura worker pattern

Širší pokrytí trhu

Střední — předčasná abstrakce (obscura transfer sekce 8.3)

❌ Počkat na 100+ jobů v KB

6

Auth guard deduplication — parametr skip_auth_check v extract_page() pro pipeline režim

Eliminace redundantní navigace na feed

Nízké — čistě refaktor bez změny chování

✅ Teď — navazuje na fix Z029

7

Sbírat job IDs z API interceptu místo DOM/script scanningu (Z018, Z013)

Rychlejší + spolehlivější extrakce

Střední — API formát se může změnit

⏳ Až LinkedIn změní aktuální strukturu

Priority

Kdy

Co

Teď (1-2 běhy)

#1 page-turn optimalizace + #6 auth dedup

Brzy (3-5 běhů)

#3 CI/CD + #4 report 2.0

Až bude dost dat (100+)

#5 multi-portál

Až LinkedIn zlomí aktuální extrakci

#7 API intercept

🧭 Why this exists

Built by a systems integration engineer who got tired of LinkedIn's noise-to-signal problem. The name "EROI" comes from energy-return-on-investment — a concept borrowed from off-grid solar (which the author also builds). The same principle applies to job hunting: don't spend energy where the return is negative.

"LinkedIn recommends everything. This tool tells you what matters."

🔗 Links

Available Tools

5 tools
analyze_saved_jobsAnalyze Saved JobsA
Read-only

Full pipeline: scrape saved jobs -> EROI score -> KB write-back.

  1. Scrapes all saved jobs from LinkedIn

  2. For each job, extracts full details

  3. Runs EROI analysis (domain/tech/role/growth/formal/location)

  4. Detects skill gaps against your portfolio

  5. Writes structured report + metadata to B2B-Knowledge-Base

  6. Git commits the changes

ParametersJSON Schema
NameRequiredDescriptionDefault
write_to_kbNoIf True, appends results to B2B-Knowledge-Base repo.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior1/5

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

The description states write operations (scraping, writing to KB, Git commit), but annotations declare readOnlyHint=true, which directly contradicts the description. This is a serious inconsistency.

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 summary line followed by a clear bullet list. Every sentence adds value and is front-loaded for quick understanding.

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?

The description fully explains the tool's actions and pipeline steps. Although annotations are contradictory, the description itself is complete for understanding behavior. The presence of an output schema covers return values.

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 single parameter write_to_kb is described in the schema with clear semantics (if True, appends to KB). The description adds context that the pipeline runs regardless, making the parameter's effect well-understood.

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 full pipeline: scraping saved jobs, running EROI analysis, detecting skill gaps, and writing results to KB with Git commit. It distinguishes itself from sibling tools like get_saved_jobs by offering a comprehensive analysis.

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 when to use this tool (for full analysis and write-back), but it does not explicitly mention when not to use it or suggest alternatives like get_saved_jobs for simple listing tasks.

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

close_session_toolClose SessionB
Read-only

Close the browser session and cleanup resources.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior1/5

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

The description claims a destructive action ('close', 'cleanup'), but annotations declare readOnlyHint=true, which is a contradiction. No additional behavioral traits are disclosed beyond the conflicting information.

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, clear sentence with no superfluous words. It is front-loaded and efficiently conveys the action.

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

Completeness2/5

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

Given the annotation contradiction, the description is incomplete and misleading. For a tool with no parameters and an output schema, more clarity on the contradiction and side effects would be needed.

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 tool has zero parameters, so the schema coverage is 100% by default. The description adds no parameter information, but none is needed. Baseline score of 4 applies.

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 (close) and the resource (browser session), and distinguishes this tool from siblings by its unique purpose of session termination.

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 is provided on when to use this tool versus alternatives (e.g., health_check, analyze_saved_jobs). The description only states what it does without context for selection.

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

get_job_detailsGet Job DetailsA
Read-only

Get full details for a specific LinkedIn job posting.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYesLinkedIn numeric job ID (e.g. '4252026496'). Get these from get_saved_jobs output.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description is consistent with these annotations but adds no additional behavioral context beyond what is already provided by the structured data.

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, front-loaded sentence with no extraneous words. Every word is necessary and directly conveys the tool's purpose.

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?

The tool is simple (one parameter, output schema exists) and the description adequately states its purpose. However, it could be more complete by explicitly linking to get_saved_jobs or mention the output schema, though annotations and schema largely compensate.

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?

Schema coverage is 100% with one parameter (job_id) described as 'LinkedIn numeric job ID... Get these from get_saved_jobs output.' The tool description adds no additional parameter information beyond what the schema already provides, 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.

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 'full details for a specific LinkedIn job posting.' It specifies the scope (specific job) and distinguishes from sibling tools like get_saved_jobs (which retrieves a list) and analyze_saved_jobs (which analyzes).

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 explicitly state when to use this tool versus alternatives. It is implied from the name and schema that it should be used after get_saved_jobs to get details of a specific job, but no guidance is provided.

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

get_saved_jobsGet Saved JobsA
Read-only

Get saved jobs from LinkedIn's /jobs-tracker/ page.

Returns saved jobs raw text and a list of numeric job IDs. Pass any job_id to get_job_details for full posting text.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds context about the data source (LinkedIn page) and return format (raw text and numeric IDs), enhancing transparency without contradiction.

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 with two sentences that front-load the purpose, and every word adds value without 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?

Given no parameters and presence of output schema, the description adequately covers what the tool does and suggests next steps. It is complete for the tool's 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?

Schema coverage is 100% due to zero parameters, so baseline is 3. The description adds value by describing the output, which compensates for not needing parameter details.

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 gets saved jobs from LinkedIn's /jobs-tracker/ page, specifying the output includes raw text and numeric job IDs. It differentiates from sibling get_job_details by indicating a follow-up use.

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 provides clear context on when to use this tool (to get saved jobs) and hints at using get_job_details with a job_id, but does not explicitly state when not to use it or alternatives beyond mentioning the sibling.

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

health_checkHealth CheckA
Read-only

Check server health and version.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

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

The readOnlyHint annotation already indicates this is a read operation. The description adds minimal extra behavioral context beyond 'check health and version', but does not contradict the annotation. It would benefit from stating side effects or the nature of the check.

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 concise sentence that is front-loaded with the core action. No unnecessary words or repetition.

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 simplicity of the tool (no parameters, clear annotations, and an output schema present), the description is adequate. It could be slightly more informative about what the check entails, but the presence of an output schema reduces the need for detailing return values.

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?

There are no parameters in the input schema, so the description has no burden to explain them. The baseline score of 3 applies because schema coverage is 100% and no additional semantics are needed.

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 checks server health and version, which is a specific verb and resource. It is distinct from sibling tools that deal with jobs and sessions, leaving no ambiguity about its purpose.

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 is provided on when to use this tool versus alternatives, or any prerequisites or conditions. The description simply states what it does, 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.0
    • First observedanalyze_saved_jobs
    • First observedclose_session_tool
    • First observedget_job_details
    • First observedget_saved_jobs
    • First observedhealth_check
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: analyze_saved_jobs is a complex pipeline, get_saved_jobs lists jobs, get_job_details retrieves details, close_session_tool handles cleanup, and health_check is a utility. No overlap or ambiguity.

Naming Consistency2/5

Naming is inconsistent: analyze_saved_jobs and close_session_tool use different conventions (the latter with a '_tool' suffix), while get_job_details and get_saved_jobs follow a standard verb_noun pattern, and health_check is a noun_noun. No consistent verb prefix or suffix style.

Tool Count4/5

With 5 tools, the server is appropriately scoped for a LinkedIn jobs helper. It covers the main operations without overloading, though the health_check and close_session tools are minor utilities that add slight overhead.

Completeness3/5

The tool surface covers listing saved jobs, getting details, and an analysis pipeline, but lacks operations for removing or updating saved jobs, which are common in a jobs management context. The analysis tool is comprehensive but the rest is somewhat sparse.

Maintenance

ActivityMaintained
ResponsivenessSyncing

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

  • MCP Job Search

    adamd9
    F
    license
    Not graded
    quality
    D
    maintenance
    Helps users find suitable LinkedIn job opportunities by automatically scraping listings, analyzing compatibility with user profiles using AI, and sending custom match reports via email.
    1
    -

  • LinkedIn-Posts-Hunter-MCP

    kevin-weitgenant
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides tools for automating LinkedIn job post search and management. Job opportunities often appear in LinkedIn posts first, before they're posted on traditional job boards. By monitoring LinkedIn posts, you can discover opportunities earlier and get a competitive advantage in your job search.
    16
    7
    ISC

  • LinkedIn Job Scraper MCP

    Anjani27
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI assistants to search, filter, and extract job listings from LinkedIn using an automated headless browser with semantic AI filtering and deduplication.
    25
    MIT

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/outpost2026/linkedin-mcp-analyzer'

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