開啟應徵視窗並填入資訊，支援選擇特定推薦信範本或覆蓋填入客製化推薦信。此工具僅作輔助，需人類最後確認送出。
開啟應徵視窗並填入資訊，支援選擇特定推薦信範本或覆蓋填入客製化推薦信。此工具僅作輔助，需人類最後確認送出。
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | Dry run 模式：走完所有步驟但不點送出，並截圖回傳。預設為 false。 | |
| job_url | Yes | 104 職缺頁面網址 | |
| template_title | No | 選填。指定選用 104 帳號內的推薦信範本名稱（例如 '系統預設'、'自訂推薦信1' 等）。 | |
| cover_letter_text | No | 選填。自傳或給公司的求職信內容。若提供則會填入並覆蓋推薦信文字框。 |
Changes observed during successful MCP inspections.
v1.1.5Input schema / properties / cover_letter_text / descriptionPrevious value: -"自傳或給公司的求職信內容"New value: +"選填。自傳或給公司的求職信內容。若提供則會填入並覆蓋推薦信文字框。"Input schema / properties / template_titleAdded value: +{
+ "description": "選填。指定選用 104 帳號內的推薦信範本名稱（例如 '系統預設'、'自訂推薦信1' 等）。",
+ "type": "string"
+}v1.0.0Does 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.