ALGO BIZ: Japan towns, jobs and industries

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the content categories (source, scope, reading cautions), but it says nothing about the return shape, whether the call is side-effect-free, or how large the response is. For a zero-parameter tool the risk is low, but this is still a real gap, because nothing in the structured fields covers it either.

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?

It is a single compact phrase that covers three distinct content categories without any filler. The content is front-loaded. It is a noun phrase rather than a sentence, which slightly weakens the framing.

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?

There is no output schema and no annotations, so the description is the only structured source of information about what comes back. It names the topics the tool covers, but it does not say how that information is returned: as a single string, as sections, or as structured fields. That leaves a gap for an agent that must decide whether to put this content straight into an answer.

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 there is nothing for the description to disambiguate; the baseline of 4 applies here. The description correctly does not invent inputs.

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 states concretely what the tool returns: the provenance of the dataset (the name of the national statistics), its coverage, and caveats on how to read it. That is specific enough to set it apart from the sibling data-fetching tools (get_industry, get_town, job_openings, list_industries). It never names a verb such as 'returns' or 'describes', which is what keeps it from 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 description says nothing explicit about when to use this tool or when to pick an alternative; it only implies usage through what it returns. An agent can work out that this is a call for metadata rather than for data, since the siblings cover data, but nothing states that case directly. Implied usage, no exclusions.

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?

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses the datasets, years, and statistical sources behind the returned values, but it does not state that this is a read-only lookup, how errors or unknown industries are handled, or how results are structured.

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?

The description is a single, front-loaded sentence beginning with the resource and then enumerating the included metrics. It is dense but every clause adds data-scope information; the parenthetical source citations are somewhat heavy but not wasteful.

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 one parameter, no output schema, and no annotations, the description should clarify return structure and usage boundaries. It adequately inventories the kinds of data returned but leaves unclear whether the response covers one queried industry or all industries, and how the metrics are organized.

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%, and the single query parameter is already documented with examples in the schema. The description does not mention the query parameter or add syntax or format details beyond what the schema provides, so baseline 3 is appropriate.

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 specifies the resource (industry-level statistics) and enumerates the concrete metrics returned: job-opening ratios, wages, prefecture comparisons, and company-size financial metrics with sources/years. It is clear what data the tool retrieves, but it does not explicitly distinguish itself from the sibling list_industries or job_openings.

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 or when-not-to-use guidance. The description never says to use list_industries first to find valid industry names, nor how this differs from job_openings, which appears to overlap with the job-opening-ratio data.

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?

With no annotations, the description carries the full burden and does reasonably well: it discloses coverage (1,889 municipalities, 政令市 split by ward), the exact vintage and source of each metric (住民基本台帳 2026-01-01, 経済センサス 令和3年, 社人研 2050), and the fallback behavior of returning candidates when names collide. It does not state read-only/side-effect profile or any rate/limit behavior, though 'get_town' makes read-only self-evident.

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?

There is no filler — every clause names a returned metric — but it is delivered as a single dense run-on sentence with an embedded colon list, which is hard to scan. Splitting the metric list into a structured enumeration would make it materially easier to parse at similar length.

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?

There is no output schema, so the description must describe return values, and it does so thoroughly, including provenance and the ambiguity case. For a two-param lookup tool this is close to sufficient; the gaps are the missing not-found behavior and the unexplained relationship to get_industry / about_data.

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 both parameters already carry descriptions including the name-or-code format and the disambiguation purpose of prefecture. The prose adds nothing about parameter format or behavior beyond the schema — the duplicate-name candidate behavior is the only extra, and it is arguably return-value semantics rather than input semantics. 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?

The description enumerates exactly what is returned for a Japanese municipality: population (住民基本台帳 2026-01-01), 5-year change, 65+ share, 2050 IPSS projection, and industry-class counts plus two comparative category signals. That is highly specific to the resource. However, the framing verb 「数を返す」('returns the number of') is misleading for what is actually a multi-field profile lookup, and there is no differentiation from the sibling get_industry despite overlapping industry-category content.

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 rather than stated: the query param accepts a name or 5-digit code and prefecture disambiguates, and 「名前が同じ町が複数あれば候補を返す」 tells the agent what happens on ambiguity. But there is no explicit when-to-use versus about_data or get_industry, and no guidance on what to do when candidates come back.

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?

No annotations are provided, so the description carries the full load, and it does disclose the data vintage (FY2025), the source, and the shape of the result for each call mode — including that the job-only case returns a ranked list. It omits error behaviour, refresh cadence, and any rate/permission notes, which is why it is not a 5.

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?

Extremely compact, front-loaded with the dataset and source, then the coverage, then the three call modes. Every clause carries information an agent would otherwise have to infer; 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 two-optional-parameter lookup with no output schema and no annotations, the description covers origin, year, granularity, and result shape for every call mode. The remaining gap is the absence of valid-value guidance for the free-text job/prefecture strings, which matters because neither parameter has an enum.

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% so the baseline is 3; the description exceeds it by specifying that omitting both parameters yields a listing and by defining the exact semantics of each one-parameter versus two-parameter call. It still does not enumerate the valid job/prefecture strings, and there are no enums.

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?

Names the exact resource (有効求人倍率), the statistical source (厚生労働省「一般職業紹介状況」), the fiscal year, and the granularity (23 jobs × 47 prefectures). The verb is only implied (a lookup), which keeps it from a 5, but an agent cannot mistake what data this returns.

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?

Explicitly maps each parameter combination to an outcome: prefecture only → that prefecture's 23 jobs, job only → 47 prefectures ranked descending, both → a single figure plus national rank. That is strong when-to-use-which guidance, though it never names or defers to the siblings (get_industry, list_industries) or states when not to use it.

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?

No annotations are supplied, so the description carries the full burden; 'list' implies a read-only operation and the parenthetical discloses the returned attributes, which is useful. It says nothing about ordering, pagination, or whether all 62 entries are always returned, and the odd 'ページ 62' phrasing could mean either '62 pages' or 'page 62'.

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 short sentence that front-loads the resource and appends the returned fields; nothing is padded or 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 zero-parameter list tool with no output schema, naming the returned fields is the right instinct, but the ambiguous '62' qualifier and the absence of any routing hint toward get_industry leave a small but real gap. It is adequate, not complete.

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 there is nothing for the description to disambiguate; baseline 4 applies. No parameter claims conflict with the empty schema.

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 states a specific resource — a list of the ALGO BIZ industry pages — and even names the returned fields (name, subtitle, page address). It does not differentiate itself from the sibling get_industry, so an agent must infer that this is the bulk-list counterpart.

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 when-to-use guidance and no mention of alternatives, even though get_industry clearly exists for fetching a single industry. The agent is left to guess whether this returns one entry or all 62.

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?

No annotations exist, so the description carries the full burden — and it does substantial work by detailing exactly which five data blocks come back, including the 50% threshold concept and the 2050 crossover set. It is implicitly a read-only lookup. It does not cover failure behavior for unknown town/industry names, which is the main remaining gap.

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?

Front-loaded with a one-line summary of the operation, then structured as ①–⑤ so an agent can scan the returned content. It is dense and reads as a long run-on sentence, but nearly every clause conveys real information about the payload rather than 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?

With no output schema and no annotations, the description is the only source of return-value information, and it enumerates all five response sections in enough detail that an agent knows what it will get. Missing only edge-case behavior (invalid town/industry, the role of prefecture), which keeps it short of a 5.

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%, so the baseline is 3. The description adds some value by naming the accepted industry families (61 ALGO BIZ sectors vs. census small-classification names or 3-digit codes) and example sectors, but it says nothing about the optional prefecture parameter, which only the schema documents.

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 concrete verb and resource: takes one municipality and one industry and returns a single combined card, then enumerates the five sections returned (population projection, industry presence thresholds, prefecture labor stats, national cost-ratio sensitivity, and a ready-to-read sentence). This clearly distinguishes it from the single-axis siblings get_town and get_industry, though it never names them explicitly.

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 'town × industry in one card' framing implies when to prefer this over the single-axis lookups, and the accepted industry vocabularies are spelled out. However, there is no explicit 'use this instead of get_town/get_industry when you need both dimensions' statement and no guidance on when the optional prefecture parameter is required beyond a terse hint in the schema.

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