Skip to main content
Glama
Sign In
104 Job Hunter MCP

104 Job Hunter MCP

by YuJunWang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

job104_search

搜尋 104 人力銀行的職缺，支援薪資下限、排除面議/廣告職缺、遠端型態、全兼職與最新排序

Instructions

搜尋 104 人力銀行的職缺，支援薪資下限、排除面議/廣告職缺、遠端型態、全兼職與最新排序

Input Schema

NameRequiredDescriptionDefault
pageNo頁數，預設為 1
sortNo排序方式：'newest' 最新更新優先 / 'salary' 待遇高到低 / 'relevance' 相關度優先relevance
remoteNo遠端型態：'full' 完全遠端 / 'partial' 部分遠端 / 'any' 皆可
jobTypeNo工作性質：'fulltime' 全職 / 'parttime' 兼職
keywordYes職缺關鍵字，例如 '前端工程師' 或 'Node.js'
locationNo工作地點關鍵字，例如 '台北市'（非必要）
salaryMinNo月薪下限（新台幣），例如 60000。自動附加 scstrict 確保篩選生效
excludeFeaturedNo是否排除 104 付費廣告職缺（如 COACH 等無關推廣缺），預設為 false
excludeNegotiableNo是否排除面議職缺，預設為 false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.1.5
    • addedInput schema / properties / excludeFeatured
      Added value: +{
+  "default": false,
+  "description": "是否排除 104 付費廣告職缺（如 COACH 等無關推廣缺），預設為 false",
+  "type": "boolean"
+}
    • addedInput schema / properties / excludeNegotiable
      Added value: +{
+  "default": false,
+  "description": "是否排除面議職缺，預設為 false",
+  "type": "boolean"
+}
    • addedInput schema / properties / jobType
      Added value: +{
+  "description": "工作性質：'fulltime' 全職 / 'parttime' 兼職",
+  "enum": [
+    "fulltime",
+    "parttime"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / remote
      Added value: +{
+  "description": "遠端型態：'full' 完全遠端 / 'partial' 部分遠端 / 'any' 皆可",
+  "enum": [
+    "full",
+    "partial",
+    "any"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / salaryMin
      Added value: +{
+  "description": "月薪下限（新台幣），例如 60000。自動附加 scstrict 確保篩選生效",
+  "type": "number"
+}
    • addedInput schema / properties / sort
      Added value: +{
+  "default": "relevance",
+  "description": "排序方式：'newest' 最新更新優先 / 'salary' 待遇高到低 / 'relevance' 相關度優先",
+  "enum": [
+    "newest",
+    "salary",
+    "relevance"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools