Analyze public salary data for Taiwan job postings by keyword, area, category, and filters, returning sampled counts, minimum, quartiles, median, and maximum pay.
薪資行情：取前 pages（1~5）頁有公開薪資的職缺，依單位統計筆數、最低、四分位、中位、最高。 參數同 search_jobs。樣本統計，非全站。
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| pages | No | ||
| jobcat | No | ||
| keyword | No | ||
| job_type | No | ||
| my_years | No | ||
| new_only | No | ||
| education | No | ||
| remote_only | No |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is a sample statistic (樣本統計，非全站) and covers only the first 1~5 pages, warning the agent its results are not population-wide.
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?
Dense and front-loaded: purpose, computed statistics, page cap, and the sampling caveat all land in a few short clauses with no filler. The '參數同 search_jobs' clause briefly offloads detail, which is efficient but leaves gaps.
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 output schema, the description helpfully names the returned statistics (count/min/quartiles/median/max). However, for a 9-param tool with zero schema coverage and no enum hints, delegating parameter semantics to search_jobs leaves the definition incomplete for correct invocation.
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?
Nine parameters sit at 0% schema description coverage, and the description only compensates with '參數同 search_jobs', delegating semantics to a sibling schema. The 'pages（1~5）' hint documents one param's range, but the remaining eight (area, jobcat, keyword, job_type, my_years, new_only, education, remote_only) are unexplained.
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 operation (取有公開薪資的職缺並統計) and the exact resource computed: 筆數、最低、四分位、中位、最高. It is clearly a salary-statistics tool rather than a listing tool, but sibling differentiation is only implicit via '參數同 search_jobs' rather than an explicit contrast with search_jobs/get_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 '參數同 search_jobs' note tells the agent params mirror a sibling and 'pages（1~5）' bounds the sampling, but there is no explicit when-to-use vs when-to-prefer search_jobs, and no stated prerequisites or constraints beyond the sample caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.