linkedin-job-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | Address the server listens on; set to 0.0.0.0 to make it reachable from other machines, such as from a container | 127.0.0.1 |
| PORT | No | Port of the REST API and MCP over HTTP | 3000 |
| API_RATE_LIMIT_MAX | No | Requests per window and address for the REST API | 60 |
| LINKEDIN_USER_AGENT | No | User agent for job-page requests | |
| LINKEDIN_CACHE_TTL_MS | No | How long search results stay cached, in milliseconds | 3600000 |
| API_RATE_LIMIT_WINDOW_MS | No | Rate-limit window of the REST API, in milliseconds | 60000 |
| LINKEDIN_REQUEST_TIMEOUT_MS | No | Timeout of one request to LinkedIn, in milliseconds | 15000 |
| LINKEDIN_DETAIL_CACHE_TTL_MS | No | How long job details stay cached, in milliseconds | 21600000 |
| LINKEDIN_DETAIL_MIN_INTERVAL_MS | No | Minimum gap between two job-page requests, in milliseconds | 1500 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_linkedin_jobsA | Find open jobs on LinkedIn by keyword and location, newest first. Read-only: it reads LinkedIn's public job search without signing in, spaces its requests out and keeps each search for an hour, so repeating a search answers at once. Returns JSON with total_jobs and jobs, each with position, company, location, date, agoTime, salary (when LinkedIn shows one), jobUrl and companyLogo; on failure, such as LinkedIn limiting requests, success is false with an error. LinkedIn serves 10 jobs per request, so every 10 jobs asked for add about a second. Use get_linkedin_job_details on a jobUrl for the full description and applicant count, and check_ghost_job to see whether a posting is really open. |
| get_linkedin_job_detailsA | Get one LinkedIn job's full description, criteria (seniority, employment type, industries), posted time and the applicant count shown on the public job page |
| check_ghost_jobA | Grade a job posting with Ghost Job Radar: how likely it is to be a ghost job (not really open), your chance against the competition, and the facts behind the grade. Needs the radar running (linkedin-jobs-mcp radar) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool maps to a distinct step in a job-hunting workflow: search a list, fetch one posting's full details, and grade a posting for ghost-job likelihood. The descriptions explicitly cross-reference each other (use get_linkedin_job_details on a jobUrl, check_ghost_job for openness), leaving no realistic path for misselection.
All three names use the same snake_case verb_noun pattern: search_linkedin_jobs, get_linkedin_job_details, check_ghost_job. Object naming is consistent (linkedin_job / job) and the verbs accurately signal the action.
Three tools cover the entire stated scope with no redundancy, which is defensible for a narrow, single-domain server. It sits at the lean edge of the scale, so users needing richer filtering must rely on the search tool's parameters alone.
The search → inspect → validate loop is fully closed, with salary, applicant count, and ghost-job grading all reachable. Minor gaps remain: no company-based lookup, no way to enumerate more than what a keyword search returns, and check_ghost_job hard-depends on a separately running local radar process.