This server automates job searching on Boss Zhipin (Boss直聘), a Chinese recruitment platform, by managing browser sessions and scraping job postings.
Login Management
open_boss_login: Opens the Boss Zhipin login page in a persistent browser profile (headless or visible) so you can scan the QR code and establish a reusable session.
get_boss_login_status: Checks whether the persistent browser profile is currently logged in, so you know if re-authentication is needed.
Job Search
search_boss_jobs: Searches for job postings by keyword, with options to:
Filter by city (e.g., 全国, 北京, 上海, 深圳, 杭州) or a specific city code
Limit results to jobs posted within a specified number of recent days (default: 30)
Crawl multiple pages of results (default: 3 pages)
Supply extra keywords as additional matching signals
Optionally exclude job cards that don't display a visible publish date
Run the browser in headless or visible mode for debugging
Resilience: The server is tuned to reduce request frequency and avoid anti-bot measures, and can connect to an existing Chrome instance via DevTools if needed.
Click on "Deploy 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., "@boss-mcp-job-hunting search for AI solutions jobs in Shanghai posted in the last 7 days"
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.
job hunting 的意思是“求职 / 找工作”。这个 MCP 用于在 Boss 直聘上按目标岗位关键词搜索职位，并过滤最近一段时间发布的岗位。
当前版本使用 FastMCP + Playwright。它不会硬编码 Boss 的内部接口，而是使用一个本地持久化浏览器资料目录复用登录态：
优先调用 import_boss_cookies(cookie_header="...") 导入正常浏览器里的 Cookie。
如果 Boss 对 Playwright profile 触发风控，可以用 search_boss_jobs_chrome_debug() 连接真实 Chrome 会话读取页面。
start_boss_qr_login() / complete_boss_qr_login() 是备用方案；Boss 可能会让 App 显示“扫码失败”。
login_boss_interactive() 仍可作为备用，但 Boss 可能会把浏览器登录页跳到 about:blank。
再调用 search_boss_jobs(keyword="AI解决方案岗", days=30) 搜索最近 30 天匹配岗位。
cd boss-mcp-job-hunting
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
playwright install chromiumRelated MCP server: BossZhipin MCP Server
作为 stdio MCP server：
boss-mcp-job-hunting或者：
python -m boss_mcp_job_hunting.server{
"mcpServers": {
"boss-mcp-job-hunting": {
"command": "boss-mcp-job-hunting",
"args": []
}
}
}import_boss_cookies把已经登录 Boss 直聘的浏览器 Cookie 导入到 MCP 的持久化资料目录。这是当前最稳的登录方式。
{
"cookie_header": "复制浏览器请求头里的 Cookie 内容",
"verify": true
}也可以在 MCP 启动环境里设置 BOSS_COOKIE，搜索时会自动应用。
start_boss_qr_login生成 Boss 直聘登录二维码图片，不打开浏览器登录页。这个接口可能被 Boss App 判定为“扫码失败”，因此只作为备用方案。
{}返回里的 qr_image_path 是本地二维码图片路径。用 Boss 直聘 App 扫码后，继续调用 complete_boss_qr_login。
complete_boss_qr_login等待 App 扫码确认，并把拿到的登录 Cookie 导入 MCP 的持久化资料目录。
{
"timeout_seconds": 180,
"verify": true
}扫码登录后，登录态会保存在：
./.boss-browser-profileopen_boss_login只打开 Boss 直聘登录页，不等待登录完成。更推荐使用 login_boss_interactive。
{
"headless": false
}login_boss_interactive打开可见浏览器窗口，等待扫码登录和安全验证完成。默认会先给你 90 秒扫码时间，这段时间不会访问岗位搜索页，避免 Boss 在你扫码前就把页面跳到 about:blank。如果登录页变成 about:blank，工具会返回 blank_redirect，不会自动重开窗口；这时建议用 import_boss_cookies。
{
"timeout_seconds": 300,
"qr_wait_seconds": 90,
"check_interval_seconds": 5
}get_boss_login_status检查本地浏览器资料目录里是否看起来已经登录。
search_boss_jobs搜索岗位并过滤最近 N 天发布的结果。
示例：
{
"keyword": "AI解决方案岗",
"city": "全国",
"days": 30,
"pages": 3,
"extra_keywords": ["大模型", "售前", "解决方案", "AI Solution"],
"require_publish_date": true,
"headless": true
}常用城市：全国、北京、上海、广州、深圳、杭州、成都、南京、武汉、西安、苏州、天津、重庆。
如果某些岗位卡片没有显示发布时间，可以把 require_publish_date 设为 false，这样会保留没有发布时间但关键词匹配的岗位。
search_boss_jobs_chrome_debug连接你真实的 Chrome 会话读取 Boss 页面。适合普通 MCP 浏览器 profile 被 Boss 风控拦截，但你自己的 Chrome 可以正常登录浏览时使用。
先关闭 Chrome，然后启动一个带调试端口的独立 Chrome：
open -na 'Google Chrome' --args --remote-debugging-port=9222 --user-data-dir=/tmp/boss-mcp-chrome-debug在这个 Chrome 里正常登录 Boss 直聘，手动打开目标搜索页并等结果渲染出来，然后调用：
{
"keyword": "AI解决方案岗",
"city": "全国",
"days": 30,
"pages": 3,
"extra_keywords": ["大模型", "售前", "解决方案", "AI Solution"],
"require_publish_date": true,
"debug_url": "http://127.0.0.1:9222",
"allow_navigation": false
}这个工具只连接本机 Chrome DevTools，不会把 Cookie 写入 Git。默认 allow_navigation=false，只读取你已经打开的 Boss 标签页，不新开页面、不跳转 URL，避免 Boss 把页面变成 about:blank。
Boss 直聘页面和风控策略可能变化。如果搜索结果为空，通常先尝试：
调用 import_boss_cookies 导入正常浏览器的 Cookie。
如果 Cookie 失效，重新在正常浏览器里登录 Boss 直聘并复制新的 Cookie。
如果 Playwright profile 仍触发风控，用 search_boss_jobs_chrome_debug 连接真实 Chrome。
如果想尝试二维码备用方案，调用 start_boss_qr_login() 和 complete_boss_qr_login()。
把 search_boss_jobs 的 headless 改为 false 观察浏览器页面。
减少 pages，避免过于频繁访问。
Check whether the persistent Boss browser profile appears logged in.
| Name | Required | Description | Default |
|---|---|---|---|
| headless | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose side effects or reliability. It only says 'appears logged in' without clarifying if it's a read-only check or if it involves network calls.
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 a single, concise sentence. While clear, it could include more context without becoming verbose.
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?
The tool has one optional parameter and an output schema (not detailed), but the description lacks explanation of return values and behavior, making it minimally adequate.
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 0%, and the description does not mention the 'headless' parameter at all, providing no added meaning beyond the schema declaration.
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 the verb 'check' and the resource 'Boss browser profile login status', distinguishing it from sibling tools 'open_boss_login' and 'search_boss_jobs'.
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?
No guidance on when to use this tool vs alternatives. It does not mention prerequisites or suggest using it before actions requiring login.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open Boss Zhipin login page with the persistent browser profile.
Keep the opened browser window until you finish scanning the QR code. The profile is stored locally and reused by search tools.
| Name | Required | Description | Default |
|---|---|---|---|
| headless | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description mentions the persistent profile and window-keeping requirement, but does not disclose what happens if already logged in or other side effects.
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?
Two concise sentences convey the essential information without redundancy, though the parameter detail is missing.
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?
The tool is simple with one parameter and an output schema exists, but the lack of parameter description makes it less complete than it could be.
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 'headless' is not explained in the description despite 0% schema coverage, leaving the agent to infer its meaning from the name alone.
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 the tool opens the Boss Zhipin login page using a persistent browser profile, distinguishing it from siblings like search_boss_jobs and get_boss_login_status.
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?
It advises keeping the window open for QR code scanning and notes that the profile is reused by search tools, providing helpful context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Boss Zhipin jobs by keyword and keep postings from recent days.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name. Common values include 全国、北京、上海、深圳、杭州. | 全国 |
| days | No | Keep jobs whose visible publish date is within this many days. | |
| pages | No | Number of search result pages to inspect. | |
| keyword | Yes | Target role, for example "AI解决方案岗". | |
| headless | No | Run browser headless. Set false when login or verification is needed. | |
| city_code | No | Optional Boss city code. If provided, it overrides city. | |
| extra_keywords | No | Extra terms that should be considered matching signals. | |
| require_publish_date | No | Drop cards without a visible publish date when true. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only mentions filtering by recency but omits important behaviors like browser automation, login requirements, or pagination.
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?
Extremely concise single sentence, front-loaded with the verb. Every word is relevant and earns its place.
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?
With 8 parameters and an output schema, a one-sentence description is insufficient; it omits details about city, pages, headless mode, and other important parameters.
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 baseline is 3. Description adds no extra meaning beyond the existing schema descriptions for parameters like keyword and days.
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 uses a specific verb ('Search'), identifies the resource ('Boss Zhipin jobs'), and adds scope ('keep postings from recent days'), differentiating it from sibling login-related tools.
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?
No guidance on when to use this tool versus alternatives; no prerequisites or context for using with login tools are mentioned.
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.
v0.1.0get_boss_login_statusopen_boss_loginsearch_boss_jobsScored across 3 tools
Each tool has a distinct and clear purpose: checking login status, opening the login page, and searching jobs. No overlap in functionality.
All tool names follow a consistent verb_noun snake_case pattern (get_boss_login_status, open_boss_login, search_boss_jobs), making them predictable.
Three tools is minimal but reasonable for a focused job-hunting assistant covering login and search. Could be slightly expanded but not undersized.
The tool surface lacks essential job-hunting operations like viewing job details, applying, or saving jobs. Only login and search are covered, leaving significant gaps.
Liepin job search and resume workflows backed by the official Liepin MCP server.
Search live startup jobs from Claude, Cursor, or ChatGPT via MCP. Free, no account needed.
SAP SuccessFactors public career-site jobs via an Apify Actor, hosted MCP.
AI job search MCP — fact-checked jobs, application tracker, alerts. ChatGPT, Claude, Cursor.
