Indeed MCP Server
This MCP server lets you search and read public Indeed job postings as structured JSON through two read-only tools.
Search job listings by keyword and location, with optional sort by relevance/date, country domain, and
start-offset pagination. Results include title, company, location, URL, short description, posted date, details, benefits, and salary when the posting states one.Fetch full job details from a posting URL, returning title, company, location, employment type/work setting, salary when present, and the full description as plain text and HTML.
Runs remotely over streamable HTTP, so any MCP client (Claude, Cursor, Windsurf, VS Code) can use it with just a URL and a HasData API key — no Indeed developer account or partner approval.
Read-only access to public Indeed data only; it does not submit applications, access employer dashboards, or read private/candidate data.
Provides tools for searching Indeed job listings by keyword and location and retrieving full details of a job posting.
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., "@Indeed MCP ServerShow me the latest software engineer jobs in Seattle with company and salary."
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.
Indeed MCP Server
A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client two read-only Indeed tools. Search job listings by keyword and location, and read a single posting in full, all as structured JSON, with no Indeed developer account and no partner approval.
It reads public job postings that a signed-out visitor can see.
https://mcp.hasdata.com/api/mcp?apis=indeed
Contents
Related MCP server: JobDataLake MCP Server
What you need
An MCP client and a HasData API key from the dashboard, free to create with no card, and the trial covers about 200 calls at the 5-credit rate. This is a remote server, so the simplest path is a URL and an x-api-key header, with no container to run and no Indeed developer account anywhere in the flow. A client that only speaks stdio reaches it through a thin launcher, published as @hasdata/indeed-mcp on npm and hasdata-indeed-mcp on PyPI, shown below.
Quick start
The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.
Field | Value |
URL |
|
Transport | HTTP, streamable |
Auth header |
|
Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.
claude mcp add --transport http indeed "https://mcp.hasdata.com/api/mcp?apis=indeed" \
--header "x-api-key: HASDATA_API_KEY"Settings, then Connectors, then Add custom connector, then paste https://mcp.hasdata.com/api/mcp?apis=indeed and sign in.
For the config-file route, Claude Desktop loads only local (stdio) servers, so it reaches a remote server through a stdio launcher. The @hasdata/indeed-mcp package is that launcher, and it reads the key from the environment. Add this to claude_desktop_config.json:
{
"mcpServers": {
"indeed": {
"command": "npx",
"args": ["-y", "@hasdata/indeed-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}For Python instead of Node, swap the launcher for the PyPI package, which uvx runs without a manual install:
{
"mcpServers": {
"indeed": {
"command": "uvx",
"args": ["hasdata-indeed-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:
{
"mcpServers": {
"indeed": {
"url": "https://mcp.hasdata.com/api/mcp?apis=indeed",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf calls the field serverUrl, not url:
{
"mcpServers": {
"indeed": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=indeed",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}.vscode/mcp.json in the workspace:
{
"servers": {
"indeed": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=indeed",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Example prompts
Prompts, not code. Paste one in and the agent picks the tool itself. Each is annotated with the calls it takes, because every successful call costs 5 credits.
Search Indeed for "python developer" jobs in New York sorted by date, and give me the ten most recent with company and salary.
One call, 5 credits. A listing page carries company, salary and posted date already.
Take the top posting from that search and pull its full description and requirements.
One call, 5 credits. The listing carries a job URL, which the details tool takes directly.
Find "data analyst" jobs in Austin, then pull full details on the three that list a salary.
Four calls, 20 credits. One listing, then one details call for each of the three.
Compare the salaries posted for "registered nurse" in Chicago against Houston.
Two calls, 10 credits, one listing per city.
Salary is on a listing only when the posting states one, so a "jobs with salary" prompt filters on the field rather than assuming it. Paging costs a call each time, through the start offset.
Tools
Two tools, read-only. Samples below are trimmed from real calls, and the numbers move as Indeed updates. Read them as shapes. Each tool name links to its endpoint reference, which carries the full field list.
The samples are the payload, not the whole response. A tools/call result carries one text block, and that text is itself JSON holding url, status, text and json, with the scraped data under json. From a raw JSON-RPC response the path is result.content[0].text, parsed, then .json. A chat client unwraps that for you and code talking to the endpoint directly does not.
Get Indeed job listings
hasdata_indeed_listing_getJobListings
A page of search results by keyword and location.
Parameter | Type | Required | Notes |
| string | yes | The search term, as a candidate would type it |
| string | yes | City and state, or any location string Indeed accepts |
| string |
| |
| string | A country site such as | |
| number | Result offset for the next page, a number and not a URL. Read the offset from |
Returns searchInformation, a jobs array, peopleAlsoSearchFor, and pagination whose nextPage is the URL of the following page. Each job carries title, company, location, url, a short description, sponsored, the relative date and the absolute isoDate, a details array of labels like Full-time and Hybrid work, a benefits array, and a salary object when the posting states one.
A listing carries
detailsas an array of plain strings. The job-details tool below returnsdetailsas an object withjobTypeandworkSettingarrays. Same name, different shape, so read each per its own tool.
{
"title": "Hedge Fund Application Developer",
"company": "TBA",
"location": "Stamford, CT 06901",
"url": "https://www.indeed.com/pagead/clk?...",
"sponsored": true,
"date": "30+ days ago",
"isoDate": "2025-06-03T17:22:54.869Z",
"details": ["Full-time", "Hybrid work"],
"benefits": ["Health insurance", "401(k)", "401(k) matching"],
"salary": { "min": 80000, "max": 150000, "type": "YEARLY" }
}Get Indeed job details
hasdata_indeed_job_getJobDetails
One posting in full, by its job URL.
Parameter | Type | Required | Notes |
| string | yes | A posting URL, the |
Returns title, company, location, sponsored, a details object with jobType and workSetting arrays, a salary object when present, and the posting body in both description (plain text) and descriptionHtml (the same content with its list and paragraph markup kept). Use descriptionHtml when you want the structure and description when you want to feed clean text to a model.
{
"title": "Python Developer",
"company": "Think IT Technologies",
"location": "New York, NY 10114",
"sponsored": false,
"details": { "jobType": ["Contract"], "workSetting": ["In-person"] },
"salary": { "min": 60.5, "max": 65, "type": "HOURLY" },
"description": "Overview\nWe are seeking a Python Developer...",
"descriptionHtml": "<p><b>Overview</b></p><p>We are seeking a Python Developer...</p>"
}Errors and failure paths
Your client almost never sees an HTTP error code from a tool call. The MCP layer answers 200 and puts the failure inside the result, with isError set to true and the reason as text. The agent reads a message where you might expect a status line.
A wrong key surfaces as tool output, not as a failed connection. tools/list accepts any non-empty key and returns both tools, so the client completes its handshake and shows green. The first tool call then comes back with isError: true and the text HasData API error: 401 Unauthorized. Watch for that string, because nothing earlier in the flow reports the problem.
A missing key is the one real HTTP error. Authorization runs before any tool, and the connection itself fails with 401. CORS headers are present, and a browser client reads the status and not an opaque network failure.
An argument that breaks a tool's schema is rejected before it becomes a scrape. The server answers with isError: true and the text MCP error -32602: Input validation error, naming the offending field. Nothing is fetched and nothing is charged.
A search that matches nothing returns a successful result with an empty jobs array, not an error. A keyword and location combination with no openings still comes back with requestMetadata.status set to ok. Test for the array length before you iterate.
A posting that has been taken down returns 400 with requestMetadata.status set to error. Indeed expires listings quickly, so a URL from an old search can be gone.
Results that carry data also carry a requestMetadata.id worth quoting in support.
Pricing, free tier and limits
Each Indeed tool costs 5 credits per successful call. Response size does not change the price. A listing page with fifty jobs costs the same as one with two.
The free trial is 1,000 credits over 30 days with no card, which is 200 Indeed calls. After that an active account keeps getting 100 credits topped up each day whenever its balance drops below 100, so a low-volume agent runs on the free tier indefinitely.
Paid plans start at $49 a month for 200,000 credits, which is 40,000 calls. The unit price falls with volume, from $1.23 per 1,000 calls on the entry plan to $0.50 on Business, $0.42 on Growth and $0.37 on the largest high-volume plans.
Your plan also sets concurrency. The free trial allows 1 request at a time, Startup 15, Business 30, Growth 50, and the high-volume plans run from 200 to 1,500. Handle the overflow case defensively in anything unattended.
A request that comes back non-200 is not billed. A successful call that finds nothing is still a call.
Tool selection
The apis query parameter decides which tools your agent sees. Fewer tools means less context spent on tool definitions, and fewer chances for the model to reach for the wrong one.
?apis=indeed the two tools in this repo
?apis=indeed,glassdoor add Glassdoor jobs
?apis=indeed,google_serp add Google searchThe parameter takes provider names like indeed and individual API names like indeed_listing. Misspelled names are ignored. If every name is wrong the request fails with 400, and the body lists both what it did not recognise and every valid value. Drop the parameter and the same endpoint exposes all 57 HasData tools.
How it compares
Indeed retired its public Publisher and Job Search APIs, and programmatic access now runs through approved partnerships and ATS integrations rather than a self-serve key. For reading public listings and postings across arbitrary searches, there is no open official route.
Official Indeed access | This server | |
Access | Partner or ATS approval | One key and one URL |
Scope | Whatever the partnership grants | Any public search or posting |
Setup | Business review | None |
Output | Depends on the integration | Structured JSON, salary pre-parsed |
Writes | Application flows for approved partners | Read-only, public data only |
What this server does not do. No application submission, no employer dashboard, no candidate data, no private postings. It reads what a signed-out visitor can see.
FAQ
Is there an official Indeed MCP server?
Indeed does not publish one. This one is maintained by HasData and reads public pages, which is why it needs no Indeed developer account.
What is an Indeed MCP server?
A server that exposes Indeed job data as tools an AI client can call. The client sends a tool call over the Model Context Protocol, the server fetches the data and returns structured JSON, and the model works with the result. This one exposes two tools and runs remotely.
Do I need an Indeed API key or partner account?
No. The only credential is your HasData key. There is no Publisher account to apply for, because the tools read public Indeed pages.
How do I page through more than one screen of results?
Pass the start offset to the listing tool as a number, not a URL. The response returns pagination.nextPage, whose own start value is the offset for the next page, so read that number and pass it back rather than feeding the URL in.
Why is a salary sometimes missing?
Because the posting does not state one. The salary object is present only when Indeed shows a figure. Read it defensively.
Can I use this together with other HasData APIs?
Yes. The apis parameter takes a list, and ?apis=indeed,glassdoor gives your agent Indeed plus Glassdoor. Drop the parameter and you get everything.
Compliance and personal data
HasData accesses publicly available data only. A platform's terms may restrict automated access, and you are responsible for your own compliance. Where the data you collect includes personal information, make sure you have a lawful basis for it under GDPR, CCPA or the equivalent rules in your jurisdiction.
HasData links
Product page and request builder | |
Server documentation | |
All 57 tools in one server | |
Client walkthroughs | |
Everything else we scrape | |
Plans and credit costs | |
Keys and usage | |
Node launcher on npm | |
Python launcher on PyPI |
Development
This repository is configuration and documentation for a remote server. There is no build step and nothing to containerize.
The tests in test/ assert the tool contract, the part that can break without a commit here. They check that ?apis=indeed returns exactly two tools, that every tool still declares its required parameters, that no name changed, and that the key in use is actually accepted. That last check calls a tool for real and costs 5 credits, which is the price of a canary that can fail for the right reason.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testThe same suite runs in CI on every push and once a week on a schedule, because the upstream tool list can change without anyone touching this repository. A failure means the tool list moved, the key stopped working, or the endpoint was unreachable, and the assertion message says which.
Contributing
Corrections to the tool tables and the response samples are the most useful contribution, because those are the parts that drift. Include the call you made and the response you got. Pull requests from forks run the suite without a key, and the live checks skip instead of going red.
License
MIT. See LICENSE.
Available Tools
2 toolshasdata_indeed_job_getJobDetailsindeed_job: GET /AInspect
Get Indeed Job Details
Fetches a single Indeed job posting by its viewjob URL. Returns job title, company, location, salary/compensation, employment type, posted date, full description, requirements/benefits, and apply URL. Use for ATS/CRM enrichment, compensation benchmarking, resume-to-JD matching with LLMs, and structured archival of postings discovered via the Indeed Listing endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the job vacancy to retrieve details for. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries responsibility: it clearly frames the operation as a read-only 'fetches' and enumerates all returned data. It could have added notes on invalid URLs or availability limits, but for a simple GET-style tool the behavior is adequately disclosed.
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 compact and front-loaded, but the opening line 'Get Indeed Job Details' repeats what the next sentence and the title already cover. The rest is focused and useful.
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?
There is no output schema, but the description compensates by listing the main returned sections: title, company, location, salary, employment type, posted date, requirements, benefits, and apply URL. It does not address error/edge behavior, but with one parameter 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?
Schema coverage is 100%, so the parameter is already documented. The description adds signifficant extra meaning by saying the URL must be the 'viewjob URL' and implying the source is the Indeed endpoint result set, which goes beyond the generic parameter text.
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 states a specific verb and resource: it fetches a single Indeed job posting by its viewjob URL. It also differentiates from the sibling endpoint by noting that these are postings discovered via the Indeed Listing endpoint.
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 explicitly lists intended use cases such as ATS/CRM enrichment, compensation benchmarking, and resume-to-JD matching. It indirectly positions the tool as the detailed single-listing complement to the listing endpoint, though it does not crank out exact when-not-to-use rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_indeed_listing_getJobListingsindeed_listing: GET /AInspect
Get Indeed Job Listings
Searches Indeed job listings by keyword and location with sort (relevance/date), country domain targeting, and offset-based pagination (start). Returns an array of jobs with title, company, location, salary, posted date, job URL, and jobKey for the requested page. Use for job-market dashboards, role/geo hiring-trend analysis, sourcing pipelines, and generating URL lists to feed into the Indeed Job endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | The sorting option for the search results. | |
| start | No | The starting index of the results to retrieve (optional). | |
| domain | No | The domain of the Indeed site (optional). Provide one exact documented value (62 allowed), e.g. `ar.indeed.com`, `au.indeed.com`. | |
| keyword | Yes | The keyword used to search for job listings. | |
| location | Yes | The location to search for job listings. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states this is a search/read operation that returns an array of job objects with specific fields, and explains the offset-pagination behavior of start. It does not mention authorization, request limits, or error behavior, but the core visible behavior is well covered.
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 starts with a direct summary ('Searches Indeed job listings by keyword and location'), then lists the relevant search controls and return payload, then names end-use contexts. There is no filler or unnecessary repetition.
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?
Although there is no output schema, the description explicitly enumerates the returned fields and page be behavior. It also explains how the resulting URLs can be consumed by the details endpoint, giving the agent enough situational context to select it for the right work.
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 already covers 100% of parameters, so baseline is a 3. The description adds context such as relevance/date sorting, country-domain targeting, and offset-based pagination, which aligns with the schema but does not need to carry the same burden given the schema's completeness.
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 states a specific verb and resource ('Searches Indeed job listings') and details the output fields (title, company, location, salary, posted date, job URL, jobKey. It clearly distinguishes this listing tool from the sibling getJobDetails by describing list-level search and URL generation for the details endpoint.
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 names concrete use cases — job-market dashboards, hiring-trend analysis, sourcing pipelines — and says the output can generate URL lists to feed into the Indeed Job endpoint. It implies when to use the listing tool versus the details sibling, but does not explicitly state when not to use it or include a direct alternative-comparison sentence.
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.
2 tool updates
v1.0.0- First observed
hasdata_indeed_job_getJobDetails - First observed
hasdata_indeed_listing_getJobListings
TDQS
The two tools have clearly distinct roles: one searches/fetchs the listing index while the other fetches full details for a specific job. There is no meaningful overlap or ambiguity in selecting between them.
Both tool names follow the same hasdata_indeed_<resource>_get<Action> pattern, with consistent snake_case prefixing and camelCase action suffixes. The naming is predictable and coherent across the set.
Two tools is on the low end for an MCP server, though the pair covers the essential list-and-detail retrieval flow for Indeed job data. The server feels minimal but not unreasonable for its focused purpose.
The server provides the core job-search workflow: get listings, then fetch details for a chosen URL. Minor gaps exist, such as no direct fetch by jobKey and no batch/company-level tools, but agents can accomplish the primary intended use case without dead ends.
Maintenance
Related MCP Connectors
DISCONTINUED 2026-05-23. Indeed.com Cloudflare + DataDome anti-bot returns HTTP 403 on all scraping
Hibrit iş ilanı arama MCP sunucusu — anahtarsız resmî ATS board API'leri (Greenhouse, Lever,…
Live job postings from 30+ ATS feeds and job boards, one schema. Live results need a Bearer key.
Google Jobs listings with direct apply links via the Apify Google Jobs Scraper, hosted MCP.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables users to search LinkedIn's public job listings with advanced filters like location, salary, and experience level. It allows MCP-compatible clients to retrieve real-time job opportunities without requiring LinkedIn authentication or API keys.12MIT
- AlicenseAqualityBmaintenanceEnables searching over 1 million enriched job listings from 20,000+ companies directly from MCP-compatible AI tools. Provides tools for job search, company profiles, and AI-powered similar job recommendations with real-time data updates.4722MIT
- AlicenseNot gradedqualityBmaintenanceLive Indeed job-postings data for AI agents via the RolesAPI REST API: search listings by keyword and location, and fetch role details, salary, description, company, and benefits. Available as drop-in agent skills or a hosted remote MCP server.MIT No Attribution
- FlicenseNot gradedqualityBmaintenanceEnables searching real job listings from multiple job boards (Indeed, LinkedIn, Glassdoor, Google Jobs, etc.) through a single MCP tool, designed for use as a custom connector in Claude Cowork.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/HasData/indeed-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server