一个托管的 Model Context Protocol (MCP) 服务器，为 Claude、Cursor、Windsurf 以及任何其他 MCP 客户端提供两个只读的 Indeed 工具。你可以按关键词和地点搜索职位列表，并完整读取单个职位详情，全部以结构化 JSON 返回，无需 Indeed 开发者账户，也无需合作伙伴审批。
它读取的是未登录访客也能看到的公开职位发布。
https://mcp.hasdata.com/api/mcp?apis=indeed
Related MCP server: Indeed Skills
需要一个 MCP 客户端和一个来自仪表盘的 HasData API 密钥，免费创建，无需银行卡，试用额度按 5 积分一次的费率大约可覆盖 200 次调用。这是一个远程服务器，所以最简单的接入方式就是一个 URL 加一个 x-api-key 请求头，无需运行容器，整个流程中也不需要 Indeed 开发者账户。只支持 stdio 的客户端可以通过一个轻量启动器连接，该启动器以 @hasdata/indeed-mcp 发布在 npm 上，以 hasdata-indeed-mcp 发布在 PyPI 上，如下所示。
服务器 URL 对所有客户端都相同。我们已在 Claude Code 和 Claude Desktop 中实际操作过。其他代码块遵循各客户端自己记录的远程服务器格式。
字段 | 值 |
URL |
|
传输方式 | HTTP, streamable |
认证请求头 |
|
支持 OAuth 的客户端可以将同一个 URL 添加为连接器并登录，而无需在配置文件中放入密钥。
claude mcp add --transport http indeed "https://mcp.hasdata.com/api/mcp?apis=indeed" \
--header "x-api-key: HASDATA_API_KEY"依次进入“设置”，然后选择“连接器”，再选择“添加自定义连接器”，粘贴 https://mcp.hasdata.com/api/mcp?apis=indeed 并登录。
对于配置文件方式，Claude Desktop 只加载本地（stdio）服务器，因此它通过 stdio 启动器连接远程服务器。@hasdata/indeed-mcp 包就是这个启动器，它会从环境中读取密钥。将其添加到 claude_desktop_config.json：
{
"mcpServers": {
"indeed": {
"command": "npx",
"args": ["-y", "@hasdata/indeed-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}如果使用 Python 而非 Node，可将启动器替换为 PyPI 包，uvx 无需手动安装即可运行该包：
{
"mcpServers": {
"indeed": {
"command": "uvx",
"args": ["hasdata-indeed-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json 用于所有项目，或 .cursor/mcp.json 用于单个项目：
{
"mcpServers": {
"indeed": {
"url": "https://mcp.hasdata.com/api/mcp?apis=indeed",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json。Windsurf 将该字段称为 serverUrl，而不是 url：
{
"mcpServers": {
"indeed": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=indeed",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}工作区中的 .vscode/mcp.json：
{
"servers": {
"indeed": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=indeed",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}这些是提示词，不是代码。粘贴其中一条，代理会自动选择工具。每条都标注了所需的调用次数，因为每次成功调用都会消耗 5 积分。
在 Indeed 上按日期排序搜索纽约的“python developer”职位，并给我最新的十条，包含公司和薪资。
一次调用，5 积分。列表页已经带有公司、薪资和发布日期。
从该搜索结果中取出第一条职位，拉取完整的描述和要求。
一次调用，5 积分。列表条目带有职位 URL，详情工具可直接使用。
查找奥斯汀的“data analyst”职位，然后拉取其中列出薪资的三个职位的完整详情。
四次调用，20 积分。一次列表调用，然后对三个职位分别调用一次详情。
对比芝加哥和休斯顿“registered nurse”职位发布的薪资。
两次调用，10 积分，每个城市一次列表调用。
只有当职位发布中明确写出薪资时，列表条目才会包含薪资，因此“带薪资的职位”这类提示词应基于该字段进行筛选，而不是假设它一定存在。分页每次都需要一次调用，通过 start 偏移量实现。
两个只读工具。下面的示例来自真实调用并做了精简，数字会随 Indeed 的更新而变化。请把它们理解为数据形态。每个工具名称都链接到其端点参考文档，其中包含完整的字段列表。
这些示例是响应中的 payload，而不是完整响应。tools/call 的结果包含一个文本块，而该文本本身是 JSON，包含 url、status、text 和 json 字段，抓取到的数据位于 json 下。从原始 JSON-RPC 响应中，路径是 result.content[0].text，解析后再访问 .json。聊天客户端会为你解包，而直接与端点通信的代码则不会。
hasdata_indeed_listing_getJobListings
按关键词和地点返回一页搜索结果。
参数 | 类型 | 必填 | 说明 |
| string | 是 | 搜索词，按求职者会输入的方式填写 |
| string | 是 | 城市和州，或 Indeed 接受的任何地点字符串 |
| string | 默认为 | |
| string | 国家站点，例如 | |
| number | 下一页的结果偏移量，是一个数字而不是 URL。从上一个响应中的 |
返回 searchInformation、一个 jobs 数组、peopleAlsoSearchFor，以及 pagination，其中 nextPage 是下一页的 URL。每个职位条目包含 title、company、location、url、简短的 description、sponsored、相对 date 和绝对 isoDate、一个由 Full-time 和 Hybrid work 等标签组成的 details 数组、一个 benefits 数组，以及当职位发布中写明薪资时的 salary 对象。
列表条目中的
details是纯字符串数组。下面的职位详情工具返回的details是一个对象，包含jobType和workSetting数组。名称相同，但结构不同，因此请按照各自的工具说明来读取。
{
"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" }
}hasdata_indeed_job_getJobDetails
通过职位 URL 获取一条完整的职位发布。
参数 | 类型 | 必填 | 说明 |
| string | 是 | 职位 URL，即列表结果中的 |
返回 title、company、location、sponsored、一个包含 jobType 和 workSetting 数组的 details 对象、存在时的 salary 对象，以及职位正文，分别以 description（纯文本）和 descriptionHtml（相同内容，保留列表和段落标记）两种形式给出。当你需要结构时使用 descriptionHtml，当你希望向模型输入干净文本时使用 description。
{
"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>"
}你的客户端几乎不会从工具调用中看到 HTTP 错误码。MCP 层会返回 200，并将失败信息放在结果内部，isError 设为 true，原因以文本形式给出。代理读到的是消息，而不是你可能预期的状态行。
密钥错误会以工具输出的形式出现，而不是连接失败。 tools/list 接受任何非空密钥，并返回两个工具，因此客户端会完成握手并显示绿色。第一次工具调用随后会返回 isError: true，以及文本 HasData API error: 401 Unauthorized。请留意该字符串，因为流程中更早的阶段不会报告此问题。
缺少密钥是唯一真正的 HTTP 错误。 授权在任何工具之前执行，连接本身会以 401 失败。CORS 头存在，浏览器客户端可以读取状态，而不是遇到不透明的网络故障。
破坏工具 schema 的参数会在成为抓取请求之前被拒绝。 服务器会以 isError: true 和文本 MCP error -32602: Input validation error 响应，并指出有问题的字段。不会抓取任何内容，也不会产生任何费用。
没有匹配结果的搜索会返回成功结果，jobs 数组为空，而不是错误。没有职位空缺的关键词和地点组合仍会返回 requestMetadata.status 为 ok 的结果。在迭代之前先检查数组长度。
已下架的职位发布会返回 400，且 requestMetadata.status 为 error。Indeed 的岗位列表过期很快，因此旧搜索中的 URL 可能已经失效。
携带数据的结果还包含 requestMetadata.id，在联系支持时值得引用。
每个 Indeed 工具的费用为每次成功调用 5 积分。响应大小不会改变价格。包含五十个职位的一页列表与只有两个职位的一页费用相同。
免费试用为30 天内 1,000 积分，无需银行卡，即 200 次 Indeed 调用。之后，活跃账户只要余额低于 100，每天都会补足 100 积分，因此低用量代理可以无限期运行在免费层级上。
付费套餐起价为每月 $49，包含 200,000 积分，即 40,000 次调用。单价随用量增加而下降，从入门套餐的每 1,000 次调用 $1.23，到 Business 的**$0.50**、Growth 的**$0.42**，以及最大型高用量套餐的**$0.37**。
你的套餐还决定了并发数。免费试用允许同时 1 个请求，Startup 为 15，Business 为 30，Growth 为 50，高用量套餐为 200 到 1,500。在任何无人值守的流程中，请防御性地处理超出并发限制的情况。
返回非 200 的请求不会计费。成功但无结果的调用仍然算一次调用。
apis 查询参数决定你的代理可以看到哪些工具。工具越少，用于工具定义的上下文就越少，模型选错工具的机会也就越少。
?apis=indeed the two tools in this repo
?apis=indeed,glassdoor add Glassdoor jobs
?apis=indeed,google_serp add Google search该参数接受 indeed 这样的提供商名称，以及 indeed_listing 这样的单个 API 名称。拼写错误的名称会被忽略。如果所有名称都错误，请求会以 400 失败，响应体会列出它无法识别的名称以及所有有效值。去掉该参数后，同一端点会暴露全部 57 个 HasData 工具。
Indeed 已停用其公开的 Publisher 和 Job Search API，程序化访问现在通过获批的合作伙伴关系和 ATS 集成进行，而不是通过自助式密钥。对于跨任意搜索读取公开的职位列表和职位发布，没有开放的官方途径。
Indeed 官方访问 | 本服务器 | |
访问 | 合作伙伴或 ATS 批准 | 一个密钥和一个 URL |
范围 | 合作关系授予的任何范围 | 任意公开搜索或职位发布 |
配置 | 业务审查 | 无需 |
输出 | 取决于集成方式 | 结构化 JSON，薪资已预解析 |
写入 | 获批合作伙伴的申请流程 | 只读，仅限公开数据 |
本服务器不做什么。 不提交申请，不提供雇主仪表盘，不提供候选人数据，也不提供非公开职位。它读取的是未登录访客可以看到的内容。
Indeed 没有发布官方的。本服务器由 HasData 维护，读取的是公开页面，因此不需要 Indeed 开发者账户。
一种将 Indeed 职位数据以工具形式暴露出来、供 AI 客户端调用的服务器。客户端通过 Model Context Protocol 发送工具调用，服务器获取数据并返回结构化 JSON，模型再处理结果。本服务器提供两个工具，并远程运行。
不需要。唯一的凭证是你的 HasData 密钥。没有需要申请的 Publisher 账户，因为这些工具读取的是 Indeed 公开页面。
将 start 偏移量作为数字（而不是 URL）传给列表工具。响应会返回 pagination.nextPage，它自带的 start 值就是下一页的偏移量，因此请读取该数字并传回，而不是把 URL 传进去。
因为职位发布没有写明薪资。只有当 Indeed 显示了具体数字时，salary 对象才会存在。请以防御性方式读取它。
可以。apis 参数接受一个列表，?apis=indeed,glassdoor 会让你的智能体获得 Indeed 和 Glassdoor 的数据。去掉该参数 即可获得全部。
HasData 仅访问公开可用的数据。平台的条款可能限制自动化访问，你需要自行负责合规。当你收集的数据包含个人信息时，请确保你根据 GDPR、CCPA 或你所在司法管辖区的等效规则，拥有合法的处理依据。
产品页面与请求构建器 | |
服务器文档 | |
一个服务器中的全部 57 个工具 | |
客户端操作指南 | |
我们抓取的其他所有内容 | |
套餐与积分费用 | |
密钥与用量 | |
npm 上的 Node 启动器 | |
PyPI 上的 Python 启动器 |
该仓库是一个远程服务器的配置与文档。没有构建步骤，也没有需要容器化的内容。
test/ 中的测试断言的是工具契约，也就是即使没有向这里提交任何内容也可能被破坏的那一部分。它们会检查 ?apis=indeed 是否恰好返回两个工具、每个工具是否仍声明其必需参数、名称是否没有任何变化，以及正在使用的密钥是否确实被接受。最后一项检查会真实调用一个工具，消耗 5 个积分——这就是金丝雀的代价，它若失败，必是出于正确的原因。
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm test同一套测试会在每次推送时于 CI 中运行，并每周定时运行一次，因为即使没有人改动此仓库，上游工具列表也可能发生变化。一次失败意味着工具列表发生了变动、密钥停止工作或端点不可达，断言消息会指明具体是哪种情况。
对工具表格和响应示例的更正是最有用的贡献，因为这些部分最容易发生漂移。请附上你发出的调用以及收到的响应。来自 fork 的拉取请求会在没有密钥的情况下运行测试套件，实时检查会被跳过，而不会变红。
MIT。参见 LICENSE。
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states what is returned but does not mention side effects, error handling, rate limits, or any read-only guarantees. The 'Fetches' wording implies a safe GET, but transparency is limited.
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 two sentences: first states the core function, second lists return fields and use cases. It is concise, well-structured, and every sentence adds value.
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?
Given the simple tool (one parameter, no output schema), the description fully covers what the tool does, what it returns, and when to use it. The relationship to the listing sibling is clarified, and no critical information is missing.
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 single parameter 'url' is clearly described in the schema as 'The URL of the job vacancy to retrieve details for.' The tool description reinforces this with 'viewjob URL,' leaving no ambiguity about what input is expected.
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?
Clearly states it fetches a single Indeed job posting by viewjob URL, lists the returned fields, and distinguishes itself from the listing sibling by focusing on a single posting. The verb 'Fetches' and resource 'Indeed job posting' are specific and unambiguous.
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?
Provides explicit use cases (ATS/CRM enrichment, compensation benchmarking, resume-to-JD matching, structured archival) and references the Indeed Listing endpoint as the discovery source, implying this tool is for postings already found. Does not explicitly contrast with Glassdoor job details, but the context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only search operation (GET) but does not explicitly state side effects, rate limits, or authentication requirements. The behavior is mostly transparent but lacks explicit safety language.
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 well-structured and readable but contains slight redundancy, repeating the search criteria and return format in consecutive sentences. It remains concise and to the point.
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?
Since there is no output schema, the description adequately explains the return format (array of jobs with listed fields). It also covers pagination and domain selection, giving sufficient context for correct invocation.
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?
All five parameters have descriptions, covering required and optional fields. The description adds context by explaining sort options, domain examples, and offset-based pagination, which goes beyond the schema definitions.
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 clearly states that the tool retrieves Indeed job listings by keyword and location, with sorting and pagination options. It also distinguishes from the sibling tool by mentioning generating URL lists for the Indeed Job endpoint, implying a listing vs. detail perspective.
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 provides explicit use cases such as job-market dashboards, hiring-trend analysis, and sourcing pipelines. It doesn't explicitly contrast with the sibling tool, but the intended scenarios are clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0hasdata_indeed_job_getJobDetailshasdata_indeed_listing_getJobListingsScored across 2 tools
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.
Search job postings across Indeed, LinkedIn, and more from one request - titles, companies
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,…
Job search for Switzerland. Searches current listings on funkyjobs.ch by keyword, place with radius, workload, category and publishing date, and fetches a single listing with employer, location, workload and salary where stated. Read-only, no account needed. Docs: https://www.funkyjobs.ch/mcp-connector
