LinkedIn Jobs Feed MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token from console.apify.com/account/integrations. The server lists its tool without a token, but a call needs one. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_linkedin_jobsA | Search LinkedIn jobs by keywords and location and return one row per job with the employer's own website domain attached. Reads only LinkedIn's public guest job search and job posting pages, with no login. Each job row carries title, company, company page, location, posting date, job link, and by default the description, seniority level, employment type, job function, industries, and applicant count. The employer domain comes from a public company name autocomplete, then a web search, and is returned only when it clearly matches (domain_status resolved). Filters: posted within 24h, week, or month; workplace type; experience level; job type; excluded companies. only_new with a state_key returns only jobs earlier runs did not return. One free search row per search and location gives the counts. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per job row returned and once per run start; search rows are free. |
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 1 tool
With only one tool there is no possibility of misselection; its purpose (keyword+location LinkedIn job search with employer domain enrichment) is stated unambiguously. An agent cannot confuse it with anything else in the set.
The single name `search_linkedin_jobs` follows a clean snake_case verb_noun pattern with a clear platform qualifier. There is no competing convention to clash with.
One tool is thin for a server, even though the tool itself is extremely feature-dense (filters, dedup state, enrichment). The scope is narrow enough that a single entry point is defensible, but it sits at the borderline of 'too few tools'.
Search covers a lot of ground, but the surface is a single operation: there is no fetch-by-job-id for detail refresh, no company/employer lookup tool, and no way to page or resume beyond the coarse only_new state. Agents can work around this, but the lifecycle is not fully covered.