Skip to main content
Glama
tw-jobs-mcp

tw-jobs-mcp

by HsuanC0921

get_job

Read-onlyIdempotent

職缺完整內容,full=True 看全文。104 限定:applicants=近兩週應徵者人數與背景,similar=相似職缺。

Instructions

職缺完整內容,full=True 看全文。104 限定:applicants=近兩週應徵者人數與背景,similar=相似職缺。

Input Schema

NameRequiredDescriptionDefault
fullNo
job_idYes
similarNo
applicantsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.1
    • addedInput schema / properties / applicants
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
    • addedInput schema / properties / similar
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  2. First observedv1.1.0

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the description's job is to add semantics — and it does: it discloses that applicants data is scoped to the last two weeks and includes applicant background, and that both extra flags are restricted to 104-sourced data. It still omits what happens if a flag is requested on a non-104 job (error vs empty).

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?

Two dense clauses, zero filler, with the primary purpose and the full-text flag front-loaded. The telegraphic style (=, abbreviations) is efficient but slightly terse for non-Chinese-reading agents.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must frame the return payload; '職缺完整內容' gives a rough idea, but there is no indication of structure or size difference between full=True and default. The required job_id and the failure mode for restricted flags are the notable gaps for a four-parameter read tool.

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 0%, so the description must carry parameter meaning. It defines three of the four booleans (full, applicants, similar) with concrete semantics, including a time window for applicants, but says nothing about job_id — the one required parameter — such as its format or that it comes from search_jobs.

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?

States a specific verb+resource: retrieving the complete content of a job posting (職缺完整內容), and immediately clarifies the 'full' variant. It is implicitly distinguishable from search_jobs, but never names or contrasts any sibling, so it stops short of a 5.

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?

Says when to flip 'full' (full=True 看全文) and flags a hard constraint that applicants/similar only work on 104 data. However there is no guidance on when to use the applicants or similar flags versus calling search_jobs or get_company instead, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.