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

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the description doesn't need to repeat that. It adds one useful behavioral detail — that with_openings=True attaches current job openings — but says nothing about what the default response contains or what the full parameter changes.

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 short sentences, front-loaded with purpose and parameter guidance, with no filler. Every sentence earns its place by conveying purpose or parameter behavior.

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 tool with three parameters, zero schema descriptions, and no output schema, the description is incomplete. It covers company_id sourcing and with_openings but fails to explain the 'full' parameter or what the returned company profile actually includes.

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 0%, so the description must carry parameter meaning. It explains company_id's source and the effect of with_openings=True, but completely omits the third parameter 'full', leaving a significant semantic gap.

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 the specific resource (公司簡介/company profile) and states what the tool returns, distinguishing it clearly from job-focused siblings like get_job and search_jobs. However, it does not explicitly name or contrast with any alternative tool.

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?

It tells the agent where the required company_id comes from (搜尋結果或 get_job), which is useful prerequisite context. But it provides no when-to-use/when-not guidance and does not mention any alternative tools or conditions for choosing this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds a trait the annotations do not: the default response is truncated and full=True is needed for the complete text, which materially affects how an agent invokes the 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?

A single tightly packed sentence with parentheticals: the surface (full job content), the input source (search_jobs), and the full-text flag are all front-loaded with zero 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 two-param read with no output schema, it discloses the key operational fact (default truncation) and the input source. It does not describe the return shape or what fields a truncated vs full response contains, which is a minor gap.

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 0%, so the description must carry the params. It explains that `full` toggles between truncated and complete text, and it clarifies the provenance of the required `job_id`, covering both parameters' meaning beyond the bare schema types.

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 resource (full job posting) and the parenthetical names search_jobs as the origin of job_id, which differentiates it from the sibling listing tool. It stops short of an explicit verb (get/retrieve) and does not contrast with get_company/salary_overview, so it is clear but not maximally distinguishing.

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 parenthetical "job_id 來自 search_jobs" implies the workflow (search first, then fetch), and "full=True 看全文" hints at the option, but there is no explicit when-to-use/when-not or comparison against alternatives like get_company.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the traversal behavior (empty name returns children of parent), which is genuine context beyond the annotations, but says nothing about output shape or result 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?

Two short, front-loaded sentences with zero filler; the primary purpose is stated first and the parameter behavior second. Nothing is redundant.

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 3-parameter lookup with no output schema and 0% schema coverage, the description covers the parameter interplay but does not document the full set of valid kind values or what a returned code list looks like. Adequate but with visible gaps given the complete absence of structured parameter documentation.

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 0%, so the description must carry the load, and it does reasonably well: it implies kind takes 'area' or 'jobcat', and it explains the interaction between name and parent (empty name = list next level; empty parent = top level). It omits the default values and exact accepted kind strings, keeping it from a 5.

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 pairs a specific verb (查/look up) with a specific resource (地區 area codes, 職類 jobcat codes), so an agent understands this is a reference-code lookup tool. It does not, however, differentiate itself from siblings like search_jobs or get_job, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives implied usage: empty name lists the next level under parent, and empty parent means top level. That tells the agent how to invoke it for hierarchy traversal, but there is no explicit when-to-use guidance or comparison against the sibling lookup/search tools.

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

Does 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.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real behavior: per_page is capped at 30, sponsored/pinned ads are filtered by default, and unmatched area/jobcat values return candidate lists rather than failing.

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, with the highest-value routing info (id→get_job, source table) first. Every clause carries semantic weight; it reads as a compact parameter legend rather than prose, though the run-on formatting slightly reduces scannability.

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 15-parameter tool with no output schema, the description does well by naming the table return and covering most high-value filters. Gaps remain for page, new_only, with_sponsored, and keyword, so it is not fully complete but is well above adequate.

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 0%, so the description carries the full burden. It documents source, area/jobcat (Chinese names with fuzzy-match fallback), salary_min + salary_unit units, education, job_type, sort, my_years semantics, and per_page limit — substantial compensation, though page, new_only, with_sponsored, and keyword remain undefined.

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 ('搜尋職缺' / search job listings) and immediately clarifies the return shape ('回傳表格'), routing the id to get_job and company_id to get_company. This differentiates it cleanly from its detail-lookup siblings without opening their schemas.

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 explicit per-source routing guidance (104 default/most complete, yourator for startups, boards for foreign official sites, all for merged) and warns that the latter two sources only support keyword/area/sort=newest, so other filters are silently dropped. Strong selection guidance, though no explicit 'don't use this when' framing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety and network-dependence profile is covered. The description adds value by naming the specific external boards probed and implying a reachable/blocked result shape, but it says nothing about timing, rate limits, or caching behavior.

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 with no filler that front-loads the action (即時檢查) and then the resources inspected. Every clause carries information.

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 parameterless probe with no output schema, the description conveys what is examined and the binary outcome (reachable vs. blocked). It leaves the exact result format unspecified, but that is a minor gap for a tool this simple.

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, so the baseline is 4. There are no parameters whose meaning the description would need to clarify.

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 concrete verb (即時檢查 / check in real time) and a concrete resource (reachability of 104, Yourator, and foreign job boards). It is unambiguous what the tool does despite the vague tool name 'sources'. It does not, however, explicitly distinguish itself from siblings like search_jobs, which is why it falls 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives. An agent can infer this is a health/probe check to run before searching, but nothing in the text states that or excludes any scenario.

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