linkedin-job-mcp

search_linkedin_jobs

Search public LinkedIn job postings by keyword, location, and filters to find openings; returns structured results with company, date, salary when available, and job URLs.

Instructions

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.

Input Schema

Name	Required	Description	Default
`city`	No	City to search in; when given, it is searched instead of location, e.g. 'Munich'
`page`	No	Which page of results, from '0'. A page is limit jobs long: page '1' with limit '10' returns jobs 11 to 20	0
`geoId`	No	LinkedIn's numeric location id, e.g. '103644278' for the United States. Use it when a place name finds the wrong location
`limit`	No	How many jobs to return, as a number in a string, e.g. '25'	10
`sortBy`	No	'recent' for newest first or 'relevant' for LinkedIn's best matches first	recent
`country`	No	Country to search in when location is left out, e.g. 'Germany'
`jobType`	No	Only this type of employment. Leave out for all types
`keyword`	No	Job title, skill or company, e.g. 'data engineer'. Leave out to list all jobs in the location
`location`	No	City, region or country, e.g. 'Berlin, Germany'. Leave out to search worldwide
`remoteFilter`	No	Only this workplace type. Leave out for all
`dateSincePosted`	No	Only jobs posted within this period ('24hr' and 'today' mean the past 24 hours). Leave out for any date
`under_10_applicants`	No	Only jobs that fewer than 10 people have applied to so far

Schema Changelog

Changes observed during successful MCP inspections.

Changed24 schema fields changedv1.3.3Nov 9, 2026

removedInput schema / properties / city / default
```
Removed value: -""
```

changedInput schema / properties / city / description

Previous value: -"Optional city to refine location (e.g., 'Berlin')"New value: +"City to search in; when given, it is searched instead of location, e.g. 'Munich'"

removedInput schema / properties / country / default
```
Removed value: -""
```

changedInput schema / properties / country / description

Previous value: -"Optional country to refine location (e.g., 'Germany')"New value: +"Country to search in when location is left out, e.g. 'Germany'"

removedInput schema / properties / dateSincePosted / default
```
Removed value: -""
```

changedInput schema / properties / dateSincePosted / description

Previous value: -"Date range for job posting"New value: +"Only jobs posted within this period ('24hr' and 'today' mean the past 24 hours). Leave out for any date"

changedInput schema / properties / dateSincePosted / enum

Previous value: -[
-  "past month",
-  "past week",
-  "past 24 hours",
-  "24hr",
-  "today"
-]New value: +[
+  "past 24 hours",
+  "past week",
+  "past month",
+  "24hr",
+  "today"
+]

removedInput schema / properties / experienceLevel

Removed value: -{
-  "default": "",
-  "description": "Experience level required",
-  "enum": [
-    "internship",
-    "entry level",
-    "associate",
-    "senior",
-    "director",
-    "executive"
-  ],
-  "type": "string"
-}

removedInput schema / properties / geoId / default
```
Removed value: -""
```

changedInput schema / properties / geoId / description

Previous value: -"Optional LinkedIn geoId to bypass location guessing (e.g., '103644278')"New value: +"LinkedIn's numeric location id, e.g. '103644278' for the United States. Use it when a place name finds the wrong location"

removedInput schema / properties / has_verification

Removed value: -{
-  "default": false,
-  "description": "Filter for verified jobs only",
-  "type": "boolean"
-}

removedInput schema / properties / jobType / default
```
Removed value: -""
```

changedInput schema / properties / jobType / description

Previous value: -"Type of employment"New value: +"Only this type of employment. Leave out for all types"

removedInput schema / properties / keyword / default
```
Removed value: -""
```

changedInput schema / properties / keyword / description

Previous value: -"Job search keyword (e.g., 'software engineer')"New value: +"Job title, skill or company, e.g. 'data engineer'. Leave out to list all jobs in the location"

changedInput schema / properties / limit / description

Previous value: -"Maximum number of jobs to return"New value: +"How many jobs to return, as a number in a string, e.g. '25'"

removedInput schema / properties / location / default
```
Removed value: -""
```

changedInput schema / properties / location / description

Previous value: -"Location to search for jobs (e.g., 'Berlin, Germany')"New value: +"City, region or country, e.g. 'Berlin, Germany'. Leave out to search worldwide"

changedInput schema / properties / page / description

Previous value: -"Page number (0-based)"New value: +"Which page of results, from '0'. A page is limit jobs long: page '1' with limit '10' returns jobs 11 to 20"

removedInput schema / properties / remoteFilter / default
```
Removed value: -""
```

changedInput schema / properties / remoteFilter / description

Previous value: -"Remote work preference"New value: +"Only this workplace type. Leave out for all"

removedInput schema / properties / salary

Removed value: -{
-  "default": "",
-  "description": "Minimum salary",
-  "enum": [
-    "40000",
-    "60000",
-    "80000",
-    "100000",
-    "120000"
-  ],
-  "type": "string"
-}

changedInput schema / properties / sortBy / description

Previous value: -"Sort results by"New value: +"'recent' for newest first or 'relevant' for LinkedIn's best matches first"

changedInput schema / properties / under_10_applicants / description

Previous value: -"Filter for jobs with under 10 applicants"New value: +"Only jobs that fewer than 10 people have applied to so far"

First observedv1.3.0Nov 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: read-only, no sign-in required, request spacing, one-hour per-search caching, the 10-jobs-per-request latency cost, and the failure mode (success false plus error when LinkedIn rate-limits). It even documents the response fields despite no output schema existing.

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?

Structure is front-loaded: purpose first, then behavioral traits, then sibling routing. The long second sentence uses semicolons and colons densely but every clause carries distinct operational information, and nothing is repeated from the schema or title.

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 12-parameter, zero-required, mutation-free tool with no annotations and no output schema, the description supplies the return shape, failure behavior, latency model, caching semantics, and next-step tools. An agent has everything needed to call it correctly and to interpret a result.

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%, so the baseline is 3 and the schema already documents city, geoId, page/limit, and the enum filters. The description still adds genuinely useful meaning beyond the schema by explaining that LinkedIn serves results in batches of 10 and that each batch costs roughly a second, which informs how to set limit and page.

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 opening line names a specific verb and resource ("Find open jobs on LinkedIn") and pins the default ordering ("newest first"). It is immediately distinguishable from the two siblings, which are named later with their distinct roles.

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?

It routes the agent explicitly: use get_linkedin_job_details on a returned jobUrl for descriptions/applicant counts, and check_ghost_job to verify a posting is real. That is clear alternate-tool guidance. It stops short of stating when not to use this tool at all (e.g., non-job searches), so it is short of a full 5.

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

Deploy Server

search_linkedin_jobs

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools