This MCP server enables AI-assisted job hunting on 104 Job Bank, prioritizing local privacy and human review. You can:
Search for jobs by keyword, location, and page, using the backend API directly.
Retrieve job details (description, requirements, benefits) from a posting's URL via a real browser.
Prepare applications with a pre-filled cover letter, open a browser for review, and require human confirmation for final submission; includes a dry-run mode for safe testing. All operations run locally, with persistent login sessions stored in a dedicated Chrome profile.
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., "@104 Job Hunter MCP 搜尋台北市的 TypeScript 前端工程師職缺"
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.
透過 MCP (Model Context Protocol) 讓 AI 直接操作 104 人力銀行。實現搜尋、比對、投遞自動化。 🤖 進階應用：利用
AGENTS.md啟動詢答，從現有履歷直接建立「求職者虛擬分身」(MY_PROFILE.md)，精準鎖定職缺。
🤖 給 AI Agent 的最高指導原則 (System Prompt for AI)
如果你是接手這個專案的 AI，你的下一步是立刻讀取專案根目錄的 AGENTS.md。
裡面有建立「虛擬分身」、過濾職缺與投遞的標準劇本。讀完前，禁止執行任何搜尋工具。
🔍 API 攔截式搜尋：直接攔截 104 後端 JSON API，繞過前端防爬蟲機制。
📄 職缺詳情讀取：用真實 Chrome 提取職位描述、條件要求與福利。
🛡️ Hit-in-the-loop 安全機制：投遞工具只會填好求職信，絕對不會幫你按送出。
🍪 持久化登入：Cookie 存入專屬 Chrome Profile，免重複登入。
🤖 Agent 行為規範：內建 AGENTS.md 提供自動化求職劇本。
Related MCP server: jobjourney-claude-plugin
這個工具採用本地優先 (Local-First) 架構，確保帳號安全：
100% 本地執行：MCP 伺服器只在你的電腦上跑，不回傳帳號密碼。
不經手密碼：登入時會跳出本地 Chrome，你自己在 104 官方頁面登入。
Cookie 安全隔離：加密存在本機的 .chrome-profile/。該資料夾已列入 .gitignore，不會上傳 GitHub。
git clone https://github.com/YuJunWang/104-job-hunter-mcp.git
cd 104-job-hunter-mcp
npm install
npm run build(系統需求：Node.js 18+、Google Chrome)
npx tsx src/login.ts執行後會跳出 Chrome 視窗，請手動登入 104，完成後關閉視窗。
把以下設定貼進 MCP 客戶端設定檔（如 Antigravity 的 mcp_config.json 或 Claude Desktop config.json）：
{
"mcpServers": {
"104-job-hunter": {
"command": "node",
"args": ["/絕對路徑/104-job-hunter-mcp/build/index.js"]
}
}
}(Windows 使用者請注意路徑反斜線跳脫：C:\\Users\\你的帳號\\...\\build\\index.js)
重啟 AI 客戶端，工具就準備好了。
複製根目錄的 MY_PROFILE.example.md，重新命名為 MY_PROFILE.md。
填入你的求職偏好與地雷。
讓 AI 讀取 AGENTS.md：
Antigravity：將 AGENTS.md 放進 .agents/rules/，或存成全域 Skill (~/.gemini/config/skills/104-hunter/SKILL.md)。
Cursor：把 AGENTS.md 內容貼進 .cursorrules。
Claude Desktop：貼進 System Prompt。
直接講：「請閱讀專案內的 MY_PROFILE.md 與 AGENTS.md 並按照流程幫我找工作」。
給 AI 的環境建置交接指令
如果你是負責幫人類安裝 MCP 的 AI，請執行以下步驟：
跑
git clone、npm install跟npm run build。請人類跑
npx tsx src/login.ts並手動登入。幫人類把 MCP 絕對路徑寫進設定檔。
讀取
AGENTS.md了解操作劇本。依據
AGENTS.md引導人類建立MY_PROFILE.md。
job104_check_session功能：檢查登入狀態。
時機：求職流程的最開頭，確保 Cookie 未過期。
job104_search必填參數：keyword (如：AI 全端工程師 Python)
選填參數：location (如：台北市)、page (預設 1)
注意：AI 應在背景比對結果，只向人類展示 Top 3～5 筆。
job104_get_details必填參數：job_url
功能：獲取職位描述、條件要求與福利。草擬推薦信前必備。
job104_get_cover_letters選填參數：job_url
功能：讀取 104 帳號中儲存的所有自我推薦信（Cover Letter）範本，包含範本標題與完整內容。可作為 AI 客製化潤飾的基底。
job104_prepare_application (Hit-in-the-loop)必填參數：job_url
選填參數：template_title (指定使用之範本名稱)、cover_letter_text (自訂推薦信內容)、dry_run (預設 false)
注意：只會開啟投遞確認頁與代填推薦信。AI 執行後必須提醒人類：「請手動點擊確認送出」。
job104_search_companies必填參數：keyword (公司名稱)
選填參數：page、pageSize
job104_get_company_detail必填參數：companyInput (代碼或網址)
功能：獲取公司福利、產品與開放職缺列表。
job104_save_job必填參數：jobInput (代碼或網址)
功能：將職缺加入 104 收藏。
job104_save_company必填參數：companyInput (代碼或網址)
功能：追蹤公司。
job104_reload_server功能：優雅重啟 MCP 伺服器以載入新編譯的代碼，避免進程鎖死或 stdio 管道中斷。
104-job-hunter-mcp/
├── src/
│ ├── index.ts # MCP 主程式，工具註冊入口
│ ├── browser.ts # Playwright 瀏覽器單例管理 (含 Stealth Plugin)
│ ├── login.ts # 登入輔助腳本
│ ├── utils/
│ │ └── url.ts # 職缺/公司 URL 與代碼解析模組
│ ├── __tests__/
│ │ └── url.test.ts # URL 單元測試
│ └── tools/
│ ├── search.ts # job104_search
│ ├── details.ts # job104_get_details
│ ├── letters.ts # job104_get_cover_letters
│ ├── apply.ts # job104_prepare_application
│ ├── company.ts # job104_search_companies, job104_get_company_detail
│ ├── save.ts # job104_save_job, job104_save_company
│ └── session.ts # job104_check_session
├── examples/
│ └── client.ts # 本地測試客戶端範例
├── build/ # npm run build 輸出 (不進 git)
├── .chrome-profile/ # Cookie 儲存目錄 (不進 git)
├── AGENTS.md # AI 操作劇本
├── MY_PROFILE.example.md # 虛擬分身範本
├── package.json
└── tsconfig.json取得單一職缺的詳細內容與條件要求
| Name | Required | Description | Default |
|---|---|---|---|
| job_url | Yes | 104 職缺頁面網址，格式如 https://www.104.com.tw/job/xxxxx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must shoulder the burden of disclosing behavioral traits. It only states the tool's function and does not mention whether it is read-only, how errors are handled, any authentication needs, rate limits, or what the response contains beyond 'details and requirements'. The name 'get_details' implies a read operation, but the description does not confirm this or add behavioral context.
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, efficient sentence that is front-loaded with the core purpose. It contains no fluff or redundant information, earning a top score for conciseness.
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?
For a simple single-parameter retrieval tool with no output schema, the description adequately covers the essence: it retrieves detailed content and condition requirements for one job. It is complete enough for an agent to understand the tool's scope, though it could be enhanced by explicitly noting that the job_url must be valid or that the tool is read-only, but given its simplicity, a slight deduction is made.
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 fully documents the one parameter (job_url) with a description and format example, achieving 100% schema description coverage. The tool description adds no additional parameter-level meaning. Per the baseline rule, with high schema coverage, a score of 3 is appropriate.
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 specifies the action (get) and resource (detailed content and conditions of a single job posting). It distinguishes this tool from siblings (job104_search for searching, job104_prepare_application for applying) by focusing on retrieving details for an already-known specific job, making the purpose unequivocal.
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 implies the tool is used when you have a job URL and need detailed information for that single job. However, it does not explicitly state when to use this vs. the siblings, nor does it mention any exclusions or prerequisites beyond having a URL. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
開啟應徵視窗並填入資訊。此工具僅作輔助，需人類最後確認送出。
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | Dry run 模式：走完所有步驟但不點送出，並截圖回傳。預設為 false。 | |
| job_url | Yes | 104 職缺頁面網址 | |
| cover_letter_text | No | 自傳或給公司的求職信內容 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait: it does not submit automatically and requires human confirmation. However, with no annotations, it does not cover other safety aspects like authentication, reversibility, or side effects, and the description is relatively thin.
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, one specifying the action and one specifying the human-in-the-loop caveat. No wasted words.
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 a simple purpose and complete schema coverage. The description covers the core behavior and human confirmation requirement, but could mention return values or prerequisites. Overall, 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?
All three parameters have descriptions in the schema with 100% coverage, so the baseline applies. The description itself does not add any parameter semantics, but none are needed given the schema.
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 application window and fills in information, specifying the action and resource. It does not explicitly differentiate from sibling tools, but siblings are search and get_details, so the purpose is distinct by name and context.
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 notes it is a helper that requires human final confirmation, implying it should be used as a step before manual submission. It does not explicitly state when to use it versus search or get_details, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋 104 人力銀行的職缺
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 頁數，預設為 1 | |
| keyword | Yes | 職缺關鍵字，例如 '前端工程師' 或 'Node.js' | |
| location | No | 工作地點關鍵字，例如 '台北市'（非必要） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral transparency. It only says 'search' which implies a read operation, but it does not disclose that results are paginated, how pagination works, or any other behavioral traits such as rate limits or data volume. The description adds no value beyond the schema's parameter hints.
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 extremely concise, a single sentence that clearly states the tool's purpose. It is front-loaded and contains no unnecessary words. Every word 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?
The tool has no output schema and no annotations. The description does not explain what the tool returns (e.g., a list of job listings) or any additional context needed to use it effectively. While the parameter schema is complete, the overall description leaves gaps in understanding the tool's behavior and results, making it less than minimally viable for an agent.
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 provides descriptions for all three parameters (keyword, page, location), covering 100% of them. The tool description adds no additional parameter semantics. According to the rubric, when schema description coverage is high, a baseline of 3 is appropriate.
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's function: '搜尋 104 人力銀行的職缺' (search job openings on 104 Job Bank). It uses a specific verb ('搜尋') and resource ('104人力銀行的職缺'), and it is distinguishable from sibling tools like 'job104_get_details' and 'job104_prepare_application'.
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 gives no explicit guidance on when to use this tool versus its siblings. The functionality itself implies that searching is the first step before getting details or preparing an application, but this is not stated. No exclusions or alternative recommendations are provided.
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.0job104_get_detailsjob104_prepare_applicationjob104_searchScored across 3 tools
Each tool has a distinct purpose: searching for jobs, retrieving details for a specific job, and preparing an application. There is no overlap in functionality, making it easy for an agent to select the correct tool.
All tool names follow the same pattern: the 'job104_' prefix followed by an action verb ('search', 'get_details', 'prepare_application'). This consistent verb_noun style makes the toolset predictable and easy to navigate.
With 3 tools, the server is well-scoped for its purpose. The tools map to the core job hunting workflow (search, view, apply) without unnecessary extras, fitting comfortably within the ideal 3-15 range.
The toolset covers the entire lifecycle from job discovery to application preparation, including a handoff to human confirmation. There are no obvious gaps that would prevent an agent from completing the core job hunting flow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Public MCP server for discovering open jobs. Search, filter, and get application links.
GetJobzi MCP server for job search, application tracking, and career forecasting.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
