Ats Boards

@pipeworx/ats-boards

十五种申请人追踪系统上的公开招聘信息板 （Greenhouse、Lever、Ashby、SmartRecruiters、Recruitee、BambooHR、Workday、 Workable、Teamtailor、Personio、Jobvite、Breezy、Pinpoint、Rippling、iCIMS）—— 检测公司将其招聘页面发布在哪个 ATS 上，然后无需密钥即可读取任何公司的 未关闭职位。这与 greenhouse/ashby 套件不同：它们使用各自的 API 密钥读取调用者自己的私有招聘数据；本套件读取任何浏览器都能看到的同一 公开信息板，适用于任何公司。

属于 Pipeworx — 一个将 AI Agent 连接到 1872+ 个实时数据源的 MCP 网关。这是独立、非官方的集成，与上游提供方无关联、未获其认可，也非其发布。

经评估后弃用了 Dover：其公开信息板是一个由客户端渲染、受 Cloudflare Turnstile 质询保护的 SPA，而且底层职位 API （app.dover.com/api/v1/jobs）对尝试过的每种查询参数组合都返回 HTTP 401“未提供 身份验证凭据”——不存在可发现的免密端点。

工具

• ats_detect(domain | careers_url) — 通过抓取招聘页面以查找 ATS 链接；若未找到， 则针对各信息板 API 探测域名 slug，从而确定公司使用的 ATS 及其 信息板令牌。会保存发现结果，因此对同一域名的重复查询可即时完成。
• ats_jobs(ats, board_token, filters?) — 返回你已有 ats + board_token 的信息板上的 标准化招聘信息。对于所有 ATS（SmartRecruiters 除外，详见下文），会区分未知信息板 （found:false, reason:"board_not_found"）和确实存在但当前没有招聘信息的信息板 （found:true, jobs:[]）。SmartRecruiters 无法区分这两种情况——这种情况下会标记 ambiguous:true，而不是猜测。
• ats_company_jobs(domain, filters?) — 一次调用即可执行 ats_detect + ats_jobs。
• ats_new_postings(ats, board_token, since?) — 将当前招聘信息与该信息板上次 保存的快照进行比较。首次调用某个信息板时没有之前的快照，因此会将所有当前招聘信息 作为新增项返回（snapshot_bootstrap:true），而不是返回容易造成误解的空差异。

身份验证

无需密钥。以下每个端点都提供与浏览器在公司自有招聘页面上看到的相同公开信息板数据—— 无需在十五种受支持的 ATS 服务商处注册账户、获取令牌或进行注册。

唯一例外是 Workable：目前 Cloudflare 阻止了此平台边缘节点访问其公开小组件 （详见“数据来源”）——这不是身份验证限制，而是传输故障。当收到 ats:"workable" 请求时，ats_jobs/ats_company_jobs 会抛出明确错误，指出 HTTP 429 和 Cloudflare 的拦截，而不是返回空结果。

数据源

• https://boards-api.greenhouse.io/v1/boards/{board_token}/jobs?content=true — Greenhouse 的公开职位板 API。
• https://api.lever.co/v0/postings/{board_token}?mode=json（https://api.eu.lever.co/...，适用于 filters.region:"eu"）— Lever 的公开职位发布 API。
• https://api.ashbyhq.com/posting-api/job-board/{board_token}?includeCompensation=true — Ashby 的公开职位板 API（官方文档有说明；雇主公布薪酬范围时会包含这些信息）。
• https://api.smartrecruiters.com/v1/companies/{board_token}/postings — SmartRecruiters 的公开职位发布 API。
• https://{board_token}.recruitee.com/api/offers/ — Recruitee 的公开职位 API。
• https://{board_token}.bamboohr.com/careers/list — BambooHR 的公开招聘页面组件端点。
• https://{tenant}.wd{N}.myworkdayjobs.com/wday/cxs/{tenant}/{site}/jobs（POST）— Workday 的公开 CXS 职位搜索接口。board_token 将三个路径部分编码为 "{tenant}.wd{N}/{site}"，例如 "workday.wd5/Workday"（直接从公司自己的 myworkdayjobs.com 招聘页面 URL 中读取租户、wd 编号和站点）。
• https://apply.workable.com/api/v1/widget/accounts/{board_token} — Workable 的公开组件 API。目前无法从本平台的边缘节点访问；已通过 Pipeworx 生产 Cloudflare 账户上的临时 wrangler dev --remote Worker 实时确认：5 次以上尝试（两种端点形式——v1 组件和 v3 /api/v3/accounts/{account}/jobs，分别带和不带 Accept 标头，并针对多个真实账户名称，在间隔数分钟的情况下进行）均返回 HTTP 429，Content-Type: text/plain，响应正文为 error code: 1015——这是 Cloudflare 自己的机器人防护机制，而不是 Workable 应用的响应。这表明 apply.workable.com 的 Cloudflare WAF 专门对 Cloudflare Worker 到 Cloudflare 的流量进行速率限制。适配器已按 Workable 文档中说明的组件格式实现；此限制一旦解除即可使用。在此之前，每次实时调用都会明确抛出错误并指出 429，而不会返回空职位板。
• https://{board_token}.teamtailor.com/jobs.json — Teamtailor 无需密钥的 JSON Feed（jsonfeed.org v1.1）。
• https://{board_token}.jobs.personio.com/xml?language=en，若返回 404，则回退到 .jobs.personio.de — Personio 的公开 XML Feed。每家公司只会使用这两个顶级域名之一，且两者之间不会互相重定向。
• https://jobs.jobvite.com/{board_token} — Jobvite 服务端渲染的 HTML 职位板（没有 JSON API；供应商自己的 Feed 按客户提供，且默认关闭）。通过正则表达式解析 jv-job-list-* 表格标记。
• https://{board_token}.breezy.hr/json — Breezy 无需密钥的 JSON 数组。
• https://{board_token}.pinpointhq.com/postings.json — Pinpoint 无需密钥且有官方文档说明的职位发布 JSON。
• https://ats.rippling.com/{board_token}/jobs — Rippling 没有单独的 JSON API（所有猜测的 /api/... 路径均返回 404）；职位列表从页面的 <script id="__NEXT_DATA__"> 水合数据中解析。
• https://{board_token}.icims.com/jobs/search?ss=1&in_iframe=1 — iCIMS 有文档说明的 Talent-Cloud API 仅限合作伙伴使用，但公开的职位搜索页面本身是无需登录的纯服务端渲染 HTML；通过正则表达式解析。board_token 是完整的子域标签（例如 "careers-acme"）——iCIMS 客户不会共用一个固定前缀。

各 ATS 的静默零结果形态（均为实时测量，并非根据文档推断）

每种 ATS 对“找不到此招聘看板”的响应都不同，其中 3 种完全无法区分这种情况与“看板存在，但当前有 0 个职位”：

ATS	未知看板	看板存在，但有 0 个职位
Greenhouse	HTTP 404 JSON {"status":404,"error":"Job not found"}	HTTP 200 {"jobs":[]}
Lever	HTTP 404 JSON {"ok":false,"error":"Document not found"}	HTTP 200 []（实时确认：api.lever.co/v0/postings/lever）
Ashby	HTTP 404，纯文本 "Not Found"（不是 JSON）	HTTP 200 JSON {"jobs":[],"apiVersion":"1"}（实时确认：vercel、deel、mercury）
SmartRecruiters	与“0 个职位”形态相同，无法区分。 两者都返回 HTTP 200 {"totalFound":0,"content":[]}	与未知看板相同；此工具包标记为 ambiguous:true，而不进行猜测
Recruitee	HTTP 404 JSON {"error":"Not Found"}	未经独立实时确认（在此次构建的时间预算内未找到）；参照所有同类 ATS 在成功时均以 HTTP 200 返回空数组的惯例，预计为 HTTP 200 {"offers":[]}
BambooHR	HTTP 200（不是 404），Content-Type: text/html——BambooHR 自己的营销主页；不同无意义子域名返回的字节完全相同（这是通配符兜底，而非针对单个公司的 404）	HTTP 200 JSON {"meta":{"totalCount":0},"result":[]}（实时确认：helpscout、pantheon）
Workday	HTTP 404 JSON {"errorCode":"S21",...,"message":"not found: Job_Posting_Site_ID=..."}	未经独立确认（找到的所有真实租户都有职位）；limit 超过 20 时返回 HTTP 400，而非空页面；offset 超过 10,000 时返回 HTTP 200，内容与 offset:0 的页面相同，而非报错——达到任一上限时，此工具包都会报告 capped:true
Workable	被拦截（HTTP 429，Cloudflare），无法从此平台获取任何符合看板响应形态的答复	—
Teamtailor	HTTP 404，Content-Type: application/json，响应体为空（0 字节）	HTTP 200 JSON Feed {"items":[...]}（实时确认：career、arsenalfc）
Personio	.com 和 .de 均返回 HTTP 404 text/html	HTTP 200 XML <workzag-jobs>（实时确认：.de 上的 kertos、.com 上的 1nce）
Jobvite	HTTP 200，但静默重定向 4 次到不同主机（www.jobvite.com/support/...?invalid=1）——fetch 默认的 redirect:'follow' 会掩盖这一点，除非检查 res.redirected	HTTP 200，不重定向，服务器渲染的职位表格（实时确认：bagleybagelbites，65 行）
Breezy	HTTP 404，Content-Type: text/html，标题为 "Career portal not found"	HTTP 200 JSON 数组（实时确认：breezy、duolingo）
Pinpoint	HTTP 404，Content-Type: text/html（Pinpoint 自己的 404 页面）	未经独立确认（找到的所有真实看板都有职位）；参照相同惯例，预计为 HTTP 200 {"data":[]}
Rippling	HTTP 404，Next.js 自己的 404 页面，没有 __NEXT_DATA__ 职位查询	HTTP 200，存在 job-posts 查询，但 items:[]——未经独立确认（找到的所有真实看板都有职位）
iCIMS	HTTP 404，标题为 "gone: {subdomain}.icims.com : dc409"	未经独立确认（找到的所有真实门户都有职位）

将任何非 200 响应视为“0 个职位”，或将 SmartRecruiters 的 totalFound:0 视为已确认的空看板，正是此工具包旨在避免的静默零结果故障——有关上述每一行背后的边缘探测证据（状态码／长度／前 400 字节），请参阅 src/index.ts 中的头部注释。

持久化（KV，而非模块作用域）

网关将共享的 KV 命名空间注入为 _cacheKv（在 pack-manifest.json 中通过 injectCacheKv 注入），用于以下三项功能；每项数据都有时间戳，如果绑定缺失，都会平滑降级为实时获取：

1. 整个看板的职位列表缓存，TTL 约 3 小时——“每隔几小时轮询每个看板一次即可。”
2. ats_detect 写入的 domain -> {ats, board_token} 发现索引——“索引会随着使用不断扩展。”
3. ats_new_postings 用于差异比较的职位键快照。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "ats-boards": {
      "url": "https://gateway.pipeworx.io/ats-boards/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/ats-boards/mcp 上的 tools/list 会返回上表中的工具，以及 Pipeworx 共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall，以及网关范围内的其他工具。因此，你看到的工具数量会多于表格中的数量：目前，单个工具包端点除了列出该工具包自带的工具外，还会列出约 30 个共享工具。连接的 initialize 响应会说明其确切范围，是当天最权威的信息。

这是有意为之，并非意外的多路复用。元工具可以让范围受限的连接回答此工具包未覆盖的问题——通过 ask_pipeworx 跨整个目录进行路由——而无需添加第二个 MCP 服务。目前无法挂载不包含这些元工具的工具包端点；如果这些额外的架构定义消耗的上下文超过了路由带来的价值，请连接一次完整网关，而不是连接多个工具包端点。

或者，连接完整的 Pipeworx 网关，直接列出每个工具包的工具，而不只是当前工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都会访问同一个网关和相同的 1872+ 个数据源。唯一的区别是哪些工具包的工具会被直接列出；无论连接哪个端点，ask_pipeworx 都可以访问所有工具。

没有 MCP 客户端？通过 HTTP 调用

curl -X POST https://gateway.pipeworx.io/v1/tools/ats_detect \
  -H 'Content-Type: application/json' \
  -d '{"domain":"ramp.com"}'

首次调用无需账号。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/ats_detect。查找工具：使用 {"query":"..."} 调用 POST https://gateway.pipeworx.io/v1/tools/search_packs。

独立运行（无需网关账号）

此软件包也可以作为本地 stdio MCP 服务运行——无需 Pipeworx 账号，也无需往返网关：

{
  "mcpServers": {
    "ats-boards": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-ats-boards"]
    }
  }
}

或者直接运行，确认服务能够启动：

npx -y @pipeworx/mcp-ats-boards

它通过 stdin/stdout 使用 MCP，并为仅此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。相同的源代码、相同的工具，但没有 ask_pipeworx 路由。

使用 ask_pipeworx

你可以不直接调用工具，而是用通俗语言提问——这既适用于上述工具包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Ats Boards data" })

网关会自动选择合适的工具并填入参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT