Search 104 job listings, retrieve job details, and prepare applications without final submission.
Search 104 jobs by keyword, with optional location and page.
Fetch detailed content and requirements for a specific job URL.
Open an application window and prefill job application/cover letter info.
Use dry-run mode to complete steps without submitting and return a screenshot.
Requires human review and final manual submission; it does not auto-send applications.
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., "@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 人力銀行的繁瑣操作。
專注於精準過濾、深度調研、競爭者情報反推與客製自薦信代填，拒絕無意義的亂槍打鳥。
這套工具不是寫來展示技術的 Demo。我自己轉職 AI 工程師時，就是靠著這套流程，精準拿到面試並成功落地。
在 104 上找工作，大家一定都體會過這種無力感：
雜訊太多：職缺標題寫著「AI 工程師」，點進去才發現工作內容只是資料標註，或者混雜了一堆與關鍵字無關的付費廣告（例如搜工程師跑出精品專櫃）。
競爭模糊：104 只給籠統的人數區間（如「6~10 人」或「30 人以上」），你根本不知道對手是誰、具備什麼學歷與技能背景。
精力有限：認真研究公司背景、核對職缺條件、手寫客製化自薦信，一天頂多投 3 家，腦袋就乾了。
罐頭履歷無效：市面上許多標榜「自動求職」的工具，本質只是狂按送出的垃圾信發報機，充滿 ChatGPT 套話，HR 一看就直接丟垃圾桶。
因此我寫了這套 MCP 工具，把 AI 當作自己的「求職特助」：
它清楚我的技能樹、職涯目標與地雷紅線；在背景幫我擋掉 95% 不合適與廣告職缺；調閱對手背景與確切應徵人數進行勝率診斷；接著調出我原本存在 104 的自薦信語氣，針對職位痛點微調，並把推薦信填妥在應徵視窗裡，最後交給我親自把關確認。
這套人機協作流程幫我拿到了滿意的工作。現在我把這套系統完整開源出來。
flowchart TD
subgraph Input["1. 輸入設定"]
A["求職宣言 (MY_PROFILE.md)"] --> B["AI Agent (大腦)"]
A2["帳號內既有推薦信範本<br>(保持真實語氣)"] --> B
end
subgraph Core["2. 篩選與競爭調研 (MCP)"]
B -->|攔截 API 搜尋| C["104 職缺庫"]
C -->|背景自動比對| D{"條件/紅線/廣告過濾"}
D -- 排除不符條件與廣告 --> X["捨棄"]
D -- 挑選 Top 3 --> E["深度調研職缺與企業"]
E -->|反推確切人數與對手背景| E2["📊 競爭態勢分析 (apply_analysis)"]
E2 --> F["撰寫客製自薦信<br>(突圍優勢 + 去 AI 腔調)"]
end
subgraph HITL["3. Hit-in-the-Loop 安全邊界"]
F --> G["自動代填至 104 應徵視窗<br>(job104_prepare_application)"]
G --> H{"人類最終肉眼審查"}
H -->|滿意| I["👤 人類手動點擊確認送出"]
H -->|需修改| F
end
classDef accent fill:#f96,stroke:#333,stroke-width:2px;
class H,I accent;AI 抓回搜尋結果後，不會一股腦把十幾頁列表倒給你。它會對照你的 MY_PROFILE.md，自動濾掉薪資不符、踩到地雷或技術棧差太遠的職缺，並能一鍵過濾 104 付費廣告（excludeFeatured），只整理出 3 到 5 筆真正值得看的選擇。
104 網站只提供粗略的應徵人數區間（如「11~30 人」），且 API 的 total 常態為 0。本專案透過兩位小數的百分比數值，利用數學解題器精準反推確切應徵總人數，並還原出對手的學歷、年資、擅長技能與證照分布，讓你在投遞前就知道自己贏在哪裡。
工具會直接讀取你 104 帳號現有的推薦信範本（job104_get_cover_letters），以你平常講話的習慣為底稿，針對該職缺的需求微調。徹底拿掉「深感榮幸、為貴司賦能」這種浮誇套話，把重點放在實際做過的專案邊界與解題過程。
這套工具絕不替你按最後的「確認送出」。job104_prepare_application 會打開投遞彈窗、選好履歷、填入推薦信，然後停下來。投哪家、怎麼投，是你的個人職涯，最後的送出鍵必須由你親眼看過、親手按下。
Related MCP server: jobjourney-claude-plugin
🔍 進階 API 攔截搜尋：監聽 104 後端 JSON API，支援薪資下限 (salaryMin 搭配 scstrict=1)、排除面議、排除廣告職缺 (excludeFeatured)、最新排序 (sort: 'newest') 與遠端工作篩選，並內建台灣縣市 Area Code 自動解析。
📊 競爭情報精算：獨創 job104_get_apply_analysis，反推職缺不重複應徵人數，並掌握學歷（碩博/大學）、年資階層、對手 Top 10 技能與證照。
🏢 企業深層調研與 JD 內文搜尋：除提取企業福利與公司簡介外，支援以 keyword 直接在該公司所有職缺的 JD 內文中全文比對，挖掘職稱沒寫但內文要求的寶藏職缺。
🔒 本地優先 (Local-First)：
100% 在你本機運作，不對外傳輸帳號密碼或個人資料。
登入使用獨立的本機 Chrome Profile，完全由你在官方頁面操作，免除重複登入困擾。
🚦 併發互斥防護 (Concurrency Protection)：工具呼叫內建排隊互斥鎖，防止 Agent 平行發送多個請求時分頁互相搶導航而當機。
開始使用前，請確認你的電腦已安裝好以下基礎工具：
項目 | 建議版本 | 必要性 | 說明與用途 | 下載來源 |
Node.js |
| 必備 | 執行 MCP 伺服器、編譯 TypeScript 與套件管理 | |
Google Chrome | 官方穩定版本 | 必備 | 本專案借用本機 Chrome 儲存 Profile，免除爬蟲驗證並維持登入 | |
Git | 任意版本 | 必備 | 用於下載專案及日後 | |
MCP Client | 支援 MCP 之客戶端 | 必備 | 載入並調用本工具的 AI 環境 (如 Antigravity, Claude Desktop, Cursor) | - |
104 會員帳號 | 個人正常帳號 | 必備 | 請先在 104 網站完成基本履歷填寫與自薦信範本儲存 |
一鍵環境診斷：安裝完套件後，可在終端機執行 npm run check，系統會自動檢測 Node.js 版本、Chrome 執行檔路徑、編譯狀態與登入 Profile，若有缺少會給出具體提示。
如果你是被人類指派來協助設定或操作本專案的 AI 代理（如 Antigravity, Claude Desktop, Cursor 等）：
立即讀取操作手冊：請優先研讀專案根目錄的 AGENTS.md，內含完整的決策狀態機與去 AI 化推薦信規格。
主動引導建立分身：檢查根目錄是否存在 MY_PROFILE.md。若尚無此檔，請暫停搜尋，主動向人類提問索取簡歷/專案經歷，並參考 MY_PROFILE.example.md 協助生成專屬 Profile。
遵守安全防線：嚴格落實 Hit-in-the-Loop 規範，代填表單後將視窗交還人類，絕不替人類代按最終送出鍵。
git clone https://github.com/YuJunWang/104-job-hunter-mcp.git
cd 104-job-hunter-mcp
npm install
npm run check # 💡 檢查本機環境與 Chrome 是否就緒
npm test # 🧪 執行 5 組單元測試套件
npm run buildnpx tsx src/login.ts執行後會跳出 Chrome 視窗，請在 104 官方頁面登入。登入成功後腳本會自動儲存 Cookie 並安全關閉。
將設定加入你的 MCP 用戶端設定檔（例如 Antigravity 的 mcp_config.json 或 Claude Desktop 的 claude_desktop_config.json）：
{
"mcpServers": {
"104-job-hunter": {
"command": "node",
"args": ["D:\\your-path\\104-job-hunter-mcp\\build\\index.js"]
}
}
}複製根目錄的 MY_PROFILE.example.md，命名為 MY_PROFILE.md。
填入你的專案經驗、技能樹、薪資期望、地點與絕對紅線。
直接告訴你的 AI：
「請閱讀專案裡的
MY_PROFILE.md與AGENTS.md，照著標準劇本幫我找工作。」
工具名稱 | 用途說明 | 運作機制 |
| 檢查登入是否有效 | 支援新版 |
| 搜尋職缺 | 支援關鍵字、地點代碼轉換、薪資下限、排除面議、排除廣告職缺、遠端型態與最新排序 |
| 讀取職缺完整內容 | 取得詳細 JD、薪資條件、加分技能與 HR 聯絡人資訊 |
| 應徵者競爭情報分析 | 數學反推確切應徵總人數，並回傳學歷、年資、年齡、語言、Top 10 技能與證照分布 |
| 取得現有自薦信範本 | 讀取帳號內的預設與自訂推薦信標題與全文，保留個人原始口吻 |
| 代填應徵表單 (HITL) | 開啟彈窗並填入微調後的推薦信，支援 Dry Run 截圖，不替你送出 |
| 搜尋企業資訊 | 查詢公司代碼、規模、產業類別與現有職缺數 |
| 公司深度分析 | 提取企業福利文化與開放職缺，支援以 |
| 收藏職缺 | 解析職缺所屬公司並加入我的收藏名單 |
| 追蹤公司 | 帶入完整規格 Payload 追蹤心儀企業 |
| 優雅重載 MCP | 伺服器更新代碼後安全發送重啟信號，不中斷 stdio 通道 |
104-job-hunter-mcp/
├── src/
│ ├── index.ts # MCP 入口，註冊 10 組工具與 runExclusive 佇列防護
│ ├── browser.ts # Playwright 瀏覽器單例管理與 fetchIn104 頁內請求封裝
│ ├── login.ts # 互動登入與 Cookie 本地持久化腳本
│ ├── utils/
│ │ ├── url.ts # 職缺/公司 URL 提取與新版 signin 登入網址判斷
│ │ ├── area.ts # 104 官方台灣縣市 Area Code 雙向對照工具
│ │ └── applyAnalysis.ts # 應徵者人數精算反推與多維度正規化
│ ├── tools/ # 10 組核心工具實作
│ └── __tests__/ # 5 組單元測試套件與 runAllTests.ts 測試運行器
├── AGENTS.md # AI 操作手冊（含去 AI 寫作原則、競爭情報分析與 4 步投遞 SOP）
├── MY_PROFILE.example.md # 求職分身設定檔範本
└── package.json # v1.2.0求職不該是求職者與企業人資之間的「垃圾信轟炸攻防」。
善用 AI 替你過濾雜訊、診斷競爭態勢、填寫繁瑣表單，把時間和精力省下來，留給真正與未來主管、團隊交流的關鍵時刻。
希望這個專案能幫你少走一點冤枉路，順利找到合適的位置。
檢查 104 人力銀行的登入狀態。在開始求職流程前，可呼叫此工具確認 Cookie 是否仍有效，避免在最後投遞時才發現未登入。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It implies a read-only status check but never says what the tool actually returns (a boolean? an identity? an expiry time?) or whether calling it has any side effects such as refreshing the session — the one thing an agent most needs to know from a session-check tool.
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 tight sentences, front-loaded with the operation and then the motivation for calling it. No filler, though the second clause is motivation rather than specification.
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 no annotations and no output schema, the description is the only source of truth about behavior — yet it omits the return value entirely, which for a status-check tool is the primary piece of information an agent needs to act on the result.
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 tool takes no parameters, so there is nothing for the description to disambiguate and the schema is complete as-is; baseline 4 applies.
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?
States a specific verb and resource (check 104 job bank login status) that no sibling covers — the other tools search, save, or fetch details, so an agent can route to this one unambiguously.
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?
Gives a clear trigger condition: call it before starting the job-application flow to confirm the Cookie is still valid, and explains the failure mode it prevents (finding out you're logged out at final submission). It does not name alternatives or state a when-not case, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取得單一職缺的應徵者競爭情報分析：透過數學精算反推確切應徵人數（total），以及學歷、年資、年齡、語言、主要科系、擅長技能與證照分布。僅在評估競爭態勢或求職信對齊時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| jobUrlOrId | Yes | 104 職缺網址或代碼，例如 'https://www.104.com.tw/job/7bsyk' 或 '7bsyk' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It adds useful context that the applicant count is back-derived through mathematical calculation and lists the returned distributions. However, it does not explicitly state that the operation is read-only, nor does it mention permissions, rate limits, data freshness, or 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?
The description consists of two sentences with no wasted words. The core purpose and output dimensions are front-loaded, followed by the usage restriction, making it efficient and well-structured.
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 1-parameter analytics tool without an output schema, the description is reasonably complete: it explains what the tool computes and lists the return dimensions. It lacks some detail about the response format and caveats around derived estimates, but covers the essentials an agent needs to decide and call.
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 description coverage is 100%, and the single parameter jobUrlOrId is already documented with examples in the schema. The description implies a single job posting but does not add any parameter meaning beyond what the schema provides, so the baseline of 3 applies.
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: '取得單一職缺的應徵者競爭情報分析' (obtain applicant competition intelligence analysis for a single job posting). It enumerates the analysis dimensions, making the tool's purpose clear. It does not explicitly distinguish itself from siblings like job104_get_details, but the single-posting competition-analysis scope is distinctive.
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 final sentence provides an explicit usage condition: '僅在評估競爭態勢或求職信對齊時使用' (use only when assessing competitive situation or aligning cover letter). This gives clear context for when to use it. However, it does not name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取得單一公司的詳細內容（簡介、福利、聯絡人）與開放職缺列表，支援以 keyword 在該公司所有職缺 JD 內文中全文比對關鍵字。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | 在該公司內部搜尋職缺的關鍵字（比對職稱與 JD 內文，如 'C++' 或 'AWS'） | |
| companyInput | Yes | 公司代碼或是公司網址。例如 '1a2x6bmutz' 或 'https://www.104.com.tw/company/1a2x6bmutz' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the whole burden; it does disclose the payload the tool returns and how the keyword is applied (a full-text pass over every job description at that company). It says nothing about pagination, result caps on the open-job list, or rate/access constraints, which matter for a listing tool.
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?
One dense sentence that front-loads the output contents before the optional keyword behavior. Nothing is redundant, though the single run-on construction makes the keyword clause easy to skim past.
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 2-parameter read tool with no output schema, the description usefully names the returned sections, which is the right kind of compensation. It still leaves the shape of the open-job list (count, paging, fields) and the required companyInput forms unaddressed, so it is adequate rather than complete.
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 both parameters are already documented, and the description largely restates the schema's own wording. It adds a little on keyword scope but actually narrows it to JD 內文 while the schema says 職稱與 JD 內文, a minor mismatch that could confuse the agent about whether job titles are matched.
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 gives a specific verb and resource (取得單一公司的詳細內容) and enumerates what comes back: profile, benefits, contacts, and the open-job list. It does not differentiate itself from siblings such as job104_search_companies or job104_get_details, so the agent must infer the split.
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 'single company' phrasing implies you should call it once you already have a specific company identifier, which is the key usage signal versus job104_search_companies. No explicit when-not conditions or named alternatives are given, so guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
讀取您 104 帳號中儲存的所有自我推薦信（Cover Letter）範本，包含範本名稱、內文與是否為預設。
| Name | Required | Description | Default |
|---|---|---|---|
| job_url | Yes | 必填。任一有效的 104 職缺頁面網址（用於開啟應徵視窗以讀取推薦信範本）。請提供確定存在的職缺連結，例如您目前想應徵的任一職缺 URL。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implies a read-only operation and lists returned fields, but it does not explicitly state read-only safety, authentication/session requirements, or any side effects or limits.
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 front-loaded sentence with no redundant wording. It efficiently states the action, scope, and returned fields.
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 one-parameter read tool with no output schema, the description is largely complete: it identifies the resource and enumerates the returned fields. It could be stronger by explicitly noting login/session requirements, but the required job_url is fully documented in the schema.
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 description coverage is 100%, and the job_url parameter is clearly documented in the schema, including its role in opening the application window. The tool description adds no additional parameter meaning beyond that baseline.
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 (讀取), a specific resource (自我推薦信範本), and a clear scope (您 104 帳號中儲存的所有). It also enumerates returned fields (範本名稱、內文、是否為預設), making the tool's purpose 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?
The description states what the tool reads but gives no guidance on when to use it versus alternatives such as job104_prepare_application or job104_get_apply_analysis. There are no explicit when/when-not conditions or prerequisites.
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 |
|---|---|---|---|
| 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 職缺頁面網址 | |
| template_title | No | 選填。指定選用 104 帳號內的推薦信範本名稱（例如 '系統預設'、'自訂推薦信1' 等）。 | |
| cover_letter_text | No | 選填。自傳或給公司的求職信內容。若提供則會填入並覆蓋推薦信文字框。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it usefully discloses that the tool is assistive and requires human confirmation before submission. However, this conflicts with the schema's dry_run description implying the non-dry-run path actually clicks 送出, leaving the agent unsure whether the tool submits — a critical ambiguity for an action tool. No mention of auth/session requirements or side effects beyond that.
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 tight sentences, front-loaded with the action and followed by the safety caveat. No filler or 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?
All four parameters are documented in the schema and there is no output schema to explain, but for an action tool with zero annotations the description should unambiguously resolve whether submission occurs and what a non-dry-run call does. That ambiguity remains unresolved.
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; the description adds real value by clarifying the relationship between the two letter inputs — a template can be selected, or custom text overrides/fills the letter box. It doesn't explain dry_run in the description text, but the schema already does.
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?
States a concrete verb+resource: '開啟應徵視窗並填入資訊', plus the two cover-letter modes (template vs. custom override). It is distinguishable from siblings like job104_get_cover_letters or job104_get_apply_analysis, though it never explicitly names an alternative.
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?
'此工具僅作輔助，需人類最後確認送出' gives context about where this fits in the flow (assist, then human confirms), but there is no explicit when-to-use/when-not guidance and no pointer to siblings such as job104_get_cover_letters for discovering template names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
優雅重新啟動 MCP 伺服器以載入新編譯的代碼，不中斷 stdio 管道。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does disclose the important behavioral trait that the stdio pipe is not interrupted, which is exactly the risk an agent would worry about with a restart. It says nothing about what else is lost or reset — in-flight requests, cached data, session state (note the sibling job104_check_session) — so a mutation-like operation remains partly opaque.
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?
A single sentence that front-loads the action and follows with the purpose and the key safety guarantee. No filler.
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 no-argument, no-output-schema tool with no annotations, the description covers what happens and why, which is enough for correct invocation. It could go further by noting session/state loss or transient unavailability, but the essentials are present.
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 tool takes zero parameters and the schema has no properties, so there is nothing for the description to disambiguate; baseline 4 applies.
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 names a specific verb and resource ('優雅重新啟動 MCP 伺服器') plus the reason ('載入新編譯的代碼'), which is unambiguous. It is trivially distinguishable from the job104_* search/save siblings, so no explicit differentiation is needed.
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 trigger condition is stated: use it after code is recompiled, in order to load the new build. There are no competing alternatives to route against and no explicit 'when not to use', which keeps it out of the top band.
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 |
|---|---|---|---|
| companyInput | Yes | 公司代碼或是公司網址。例如 '1a2x6bmutz' 或 'https://www.104.com.tw/company/1a2x6bmutz' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It correctly identifies the tool as a direct write operation and notes the login requirement, but it does not explain duplicate handling, idempotency, what is returned, or what happens if the company is already tracked.
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 short sentences and front-loads the core action before the authentication prerequisite. There is little wasted text, though the second sentence could be slightly more informative for a mutation tool.
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 one-parameter mutation tool with no annotations and no output schema, the description covers the basic purpose, write behavior, and login prerequisite. It is still incomplete because it omits result behavior, duplicate-save semantics, and operational caveats that matter for a write operation.
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 description coverage is 100%, and the single parameter is already documented as accepting either a company code or company URL. The description adds no parameter syntax or format details beyond what the schema provides, so the 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 states a specific verb and resource: adding a specified company code to the user's 104 account tracking list. It clearly distinguishes a company-tracking action from job-saving or company-detail retrieval, though it does not explicitly contrast with sibling tools such as job104_save_job.
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 an important prerequisite: the user must already be logged in. However, it does not state when to use this tool versus job104_search_companies or job104_get_company_detail, nor does it describe exclusions or alternatives.
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 |
|---|---|---|---|
| jobInput | Yes | 職缺代碼或是職缺網址。例如 '796uv' 或 'https://www.104.com.tw/job/796uv' |
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 explicitly discloses that this is a direct write operation ('會直接執行寫入操作') and states the authentication prerequisite, which are the key behavioral traits for a save/mutation tool. It does not describe response format or what happens on duplicate saves, leaving minor gaps.
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 tightly scoped sentences: the purpose and target are front-loaded, followed immediately by the write/auth caveat. No filler or redundancy.
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 1-parameter write tool with no output schema and no annotations, the description covers purpose, mutation nature, and login requirement adequately. Only minor gaps (duplicate handling, return behavior) remain.
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 description coverage is 100%, with the single jobInput parameter already documented with examples ('796uv' or a URL). The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.
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?
States a specific verb+resource: adds a specified job code (職缺代碼) to 'My Favorites' (我的收藏) in the 104 account. The resource distinction from the sibling job104_save_company (jobs vs companies) is self-evident, though siblings are not named explicitly.
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 a real prerequisite ('需先確認已登入' – must confirm you're logged in first), which implies checking session before calling. However it does not name job104_check_session as the sibling to use, nor state when to use this versus other save operations.
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 | |
| sort | No | 排序方式：'newest' 最新更新優先 / 'salary' 待遇高到低 / 'relevance' 相關度優先 | relevance |
| remote | No | 遠端型態：'full' 完全遠端 / 'partial' 部分遠端 / 'any' 皆可 | |
| jobType | No | 工作性質：'fulltime' 全職 / 'parttime' 兼職 | |
| keyword | Yes | 職缺關鍵字，例如 '前端工程師' 或 'Node.js' | |
| location | No | 工作地點關鍵字，例如 '台北市'（非必要） | |
| salaryMin | No | 月薪下限（新台幣），例如 60000。自動附加 scstrict 確保篩選生效 | |
| excludeFeatured | No | 是否排除 104 付費廣告職缺（如 COACH 等無關推廣缺），預設為 false | |
| excludeNegotiable | No | 是否排除面議職缺，預設為 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it says nothing about authentication/session requirements, pagination limits, result caps, or rate behavior — relevant given the job104_check_session sibling. It only mentions the side-effect that salaryMin auto-appends scstrict, which is documented in the schema instead.
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?
A single front-loaded sentence that leads with purpose and then enumerates filters — no filler. It does slightly duplicate the schema's parameter list, which keeps it just short of ideal.
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 9 parameters, no output schema, and no annotations, the description should state what a search returns (job IDs usable with job104_get_details), pagination semantics, and any auth prerequisite. None of that is covered, leaving a meaningful gap for an agent that must chain this call into follow-up tools.
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 description coverage is 100%, so every parameter including enums for sort, remote, and jobType is already well documented in the schema. The description merely restates a subset of those filters and adds no syntax, format, or interaction detail beyond schema content; baseline 3 applies.
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 names a specific verb and resource (搜尋 104 職缺) and enumerates the supported filter capabilities, so the agent knows exactly what the tool retrieves. It does not explicitly contrast itself with siblings like job104_get_details or job104_search_companies, though the resource noun implicitly separates it from the company search.
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 capability list (salary floor, excluding 面議/廣告, remote, full/part-time, newest sort) implies when the tool is appropriate, but there is no statement of when to prefer it over job104_get_details, nor any prerequisite such as needing a session first. Usage is inferable rather than instructed.
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 | 公司名稱關鍵字，例如 '台積電' 或 'Google' | |
| pageSize | No | 每頁顯示數量，預設為 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that this is a company search returning industry, location, and current job count, but it omits details such as matching behavior, pagination constraints, and any session or permission requirements.
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, front-loading the tool purpose and keyword search scope. Every part contributes useful context with no filler.
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 three-parameter search tool with full schema coverage, the description is mostly complete. It helpfully states the return fields despite there being no output schema, though it could say more about pagination behavior and result matching.
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 description coverage is 100%, so the schema already documents keyword, page, and pageSize. The description adds only that keyword refers to company name and mentions example-like return fields, without adding format or constraint details beyond 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 states a clear verb and resource: searching company information on 104 Job Bank by company-name keyword. It distinguishes the tool as company search rather than job search or company detail retrieval, though it does not explicitly name sibling alternatives.
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 usage by saying it can search by company-name keyword, but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent can infer the basic use case but not how it compares with job104_search or job104_get_company_detail.
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.1.5job104_check_sessionjob104_get_apply_analysisjob104_get_company_detailjob104_get_cover_lettersjob104_prepare_application2 fields changedInput schema / properties / cover_letter_text / descriptionPrevious value: -"自傳或給公司的求職信內容"New value: +"選填。自傳或給公司的求職信內容。若提供則會填入並覆蓋推薦信文字框。"Input schema / properties / template_titleAdded value: +{
+ "description": "選填。指定選用 104 帳號內的推薦信範本名稱（例如 '系統預設'、'自訂推薦信1' 等）。",
+ "type": "string"
+}job104_reload_serverjob104_save_companyjob104_save_jobjob104_search6 fields changedInput schema / properties / excludeFeaturedAdded value: +{
+ "default": false,
+ "description": "是否排除 104 付費廣告職缺（如 COACH 等無關推廣缺），預設為 false",
+ "type": "boolean"
+}Input schema / properties / excludeNegotiableAdded value: +{
+ "default": false,
+ "description": "是否排除面議職缺，預設為 false",
+ "type": "boolean"
+}Input schema / properties / jobTypeAdded value: +{
+ "description": "工作性質：'fulltime' 全職 / 'parttime' 兼職",
+ "enum": [
+ "fulltime",
+ "parttime"
+ ],
+ "type": "string"
+}Input schema / properties / remoteAdded value: +{
+ "description": "遠端型態：'full' 完全遠端 / 'partial' 部分遠端 / 'any' 皆可",
+ "enum": [
+ "full",
+ "partial",
+ "any"
+ ],
+ "type": "string"
+}Input schema / properties / salaryMinAdded value: +{
+ "description": "月薪下限（新台幣），例如 60000。自動附加 scstrict 確保篩選生效",
+ "type": "number"
+}Input schema / properties / sortAdded value: +{
+ "default": "relevance",
+ "description": "排序方式：'newest' 最新更新優先 / 'salary' 待遇高到低 / 'relevance' 相關度優先",
+ "enum": [
+ "newest",
+ "salary",
+ "relevance"
+ ],
+ "type": "string"
+}job104_search_companiesv1.0.0job104_get_detailsjob104_prepare_applicationjob104_searchScored across 11 tools
Each tool targets a clearly distinct resource and action: job search/details, company search/details, application preparation, competition analysis, session check, cover letters, and saving jobs/companies. The job and company variants are easy to distinguish, and the specialized analysis/application tools do not overlap with the core search tools.
All tools use the same job104_ prefix and snake_case, with mostly predictable verb_noun naming such as get_details, search_companies, save_job, and check_session. Minor deviations exist, notably search without an explicit noun and reload_server as an operational utility.
Eleven tools is well-scoped for a job-hunting workflow covering search, company research, application preparation, competition analysis, and saved-item actions. The set is neither thin nor bloated, and each tool has a plausible role.
Core workflows are covered: searching jobs and companies, viewing details, checking login, reading cover letters, preparing applications, and saving jobs/companies. However, lifecycle coverage is incomplete: saved jobs/companies have save but no list/remove operations, cover letters are read-only, and application history/status tracking is absent.
Public MCP server for discovering open jobs. Search, filter, and get application links.
GetJobzi MCP server for job search, application tracking, and career forecasting.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
