@エール | Aile Jobs

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description's '（読み取り専用）' largely restates it. It adds the returned fields, but no auth, rate-limit, or error behavior beyond what annotations provide.

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 front-loaded sentence with the resource and return fields up front and source detail parenthesized. No filler, though the parenthetical is dense.

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 one-parameter read-only tool with no output schema, the description lists the return contents and explains the key source, giving the agent enough to call it correctly. Nothing critical is missing.

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% and the schema already states the 4–8 alphanumeric format, so baseline would be 3. The description goes further by explaining the parameter's provenance (the key from job_search result URLs or the https://aile-ai.jp/jobs/<key> form), which meaningfully aids correct invocation.

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?

Specific verb (返す/returns) plus resource (求人詳細) with an enumerated list of what the detail contains (求人説明・必要資格・選考フロー・勤務地・年収). It ties itself to the job_search sibling as the source of the key, though it does not differentiate itself from salary_market.

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?

Guides the agent on where the required input comes from ('job_search の結果 URL 末尾のキー'), which implies a use-after-search workflow. However, there is no explicit statement of when to use this vs. salary_market or any exclusion.

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/destructiveHint=false, and the description redundantly confirms 読み取り専用. Beyond that it adds real value by enumerating the returned fields (タイトル, 会社名, 給与レンジ, 公開 URL, etc.) and confirming the result is suited for reuse in salary_market, which annotations cannot convey.

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 sentences, no filler, with the read-only note and the filter list front-loaded. Dense but readable; the enumeration of return fields is slightly long yet justified given the absence of an output schema.

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 compensates by listing returned fields, and with no required parameters it clarifies each is optional. It omits pagination/ordering behavior for the limit parameter and any empty-result semantics, which are minor gaps for a read-only search tool.

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 100%, so all five parameters are already documented in the schema with defaults and units. The description restates the same filter dimensions (職種, 都道府県, 年収下限, リモート) without adding format or edge-case detail, so the baseline 3 applies.

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 and resource (検索する / 公開求人), scopes it to 掲載中の公開求人, and enumerates the filter dimensions. It also differentiates itself from the sibling salary_market by explaining the handoff of the returned 職種, so an agent can route between them without opening 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?

Usage is implied through the filter list and the explicit note that returned 職種 can be passed to salary_market, which is useful cross-tool guidance. However, there is no explicit when-to-use vs when-not guidance and job_detail is never mentioned, so the agent must infer the boundary between this and the other sibling.

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?

The '読み取り専用' tag merely repeats readOnlyHint=true and earns no credit, but the description does disclose behavior the annotations cannot: the data is derived from currently-listed postings, it is aggregated (count plus min/median/max), and values are in 万円. That is meaningful context for interpreting results, though it says nothing about caching, update frequency, or what happens with a sparse sample.

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 dense sentence that front-loads the resource (職種 × 都道府県の年収相場) before the returned metrics. Efficient, but the trailing parenthetical repeats the read-only hint already carried by annotations, which is mild waste in an otherwise tight sentence.

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 usefully enumerates the returned fields (posting count, min/median/max, unit 万円), which is what an agent needs to use the result. Annotations cover the safety profile. Remaining gaps are minor: no note on returned shape when prefecture is omitted or on thin-data behavior.

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 100%, so the schema already documents both parameters, including that prefecture is optional and that occupation requires an exact canonical match. The description only restates the occupation × prefecture key, adding no format or matching semantics beyond the schema. Baseline 3 applies.

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 precise verb+resource: returns annual-salary market data (posting count, min/median/max offered salary) keyed by occupation × prefecture. That clearly separates it from the job-listing siblings, but it never names job_search/job_detail as alternatives, so differentiation is inferred rather than stated.

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?

Usage is implied by the aggregation framing ('掲載中求人の…求人数・提示年収'): you call it when you want salary benchmarks rather than individual postings. There is no explicit when-to-use statement, no exclusion of cases where job_search would be the better call, and no prerequisites mentioned.

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