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

No annotations are provided, so the description carries the full burden. It states the core function but does not disclose behavior for invalid dates, return format, or any edge cases. Since an output schema exists, the return type might be visible elsewhere, but the description itself offers minimal behavioral insight.

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, well-structured sentence that immediately conveys the tool's purpose and parameter format. No wasted words, and the essential details are front-loaded.

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 single-parameter tool, the description provides sufficient context: what the tool does and the date format. The presence of an output schema reduces the need to explain return values. Minor gap: no mention of error handling or edge cases, but given the low complexity, this is acceptable.

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%, but the description compensates by specifying the exact format 'YYYY-MM-DD' for the 'day' parameter. This adds meaning beyond the bare string type, clarifying the expected input format.

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 uses a specific verb 'Check whether' with a clear resource 'date (YYYY-MM-DD)' and outcome 'Japanese national holiday'. It clearly distinguishes the tool's purpose from siblings like lookup_corporate_number or japan_holidays, which have different focuses.

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 implies usage: to test if a given date is a public holiday. However, it does not explicitly mention when to prefer this tool over siblings like japan_holidays, which likely lists holidays. No alternative or exclusion is stated, so guidance is only implied.

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 full responsibility for behavioral disclosure. It does add context that the data comes from the official Cabinet Office syukujitsu.csv and is bundled, implying deterministic local data. However, it does not disclose error behavior, valid year ranges, or other edge cases, leaving gaps for an agent to discover at runtime.

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 one concise, front-loaded sentence. It starts with the verb 'List' and immediately states the resource and scope, with a parenthetical for source context. No wasted words.

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?

The tool is simple (1 param) and has an output schema, so the description need not detail return values. The description provides essential purpose and data source, but it lacks guidance on when to use this over the sibling 'is_japan_holiday', making the overall context incomplete for an agent deciding between tools.

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 single parameter 'year' in the schema is just an integer. The description clarifies that this is the year for which holidays are listed, adding meaningful semantic context. For a single simple parameter, this is sufficient even though schema description coverage is 0%.

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 'List Japanese national holidays for a year' clearly states the tool's function with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tool 'is_japan_holiday' (which likely checks a single date), so it is clear but lacks explicit sibling differentiation.

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?

No guidance is provided on when to use this tool versus alternatives like 'is_japan_holiday'. The description only states what it does, with no mention of use cases, exclusions, or alternative 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?

With no annotations provided, the description carries the burden but does well by stating the input format and the exact return fields (name/kana/hiragana/romaji). The read-only nature is implied by 'look up', and no side effects or hidden behaviors are plausible for a simple lookup. It does not explicitly state 'read-only' or error handling, but for this tool the disclosure is sufficient.

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, and the key information is front-loaded. Every word adds value, making it an exemplary concise description.

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?

The tool is simple with one parameter and an existing output schema, so the description covers all necessary context: what input is needed, how to format it, and what will be returned. No further behavioral details are required for this use case.

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 0%, so the description must compensate for the sole parameter. It does so explicitly: '4-digit zengin bank code (統一金融機関コード)' provides both the format and domain meaning, going well beyond the bare schema property.

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 uses a specific verb ('look up') and resource ('Japanese bank') with a defined key ('4-digit zengin bank code'), clearly distinguishing from sibling tools like search_banks (which implies searching) and lookup_branch (which targets branches). It also lists the output fields, making the purpose unambiguous.

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 clearly implies the use case: when you have a 4-digit bank code and need bank details. However, it does not explicitly contrast with search_banks or state when not to use this tool, so it falls short of a 5 but is still contextually clear.

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. It discloses that branch data is lazily fetched from the public zengin-code dataset and cached locally, providing important context about network dependency and potential staleness. This exceeds what the schema/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?

The description is two sentences, front-loaded with the action and resource. The additional sentence about lazy fetching and caching is valuable and does not waste space.

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 a simple input schema and an output schema present, the description covers the purpose, input formats, data source, and caching behavior. No critical gaps are evident for the tool's complexity.

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 schema provides no descriptions (0% coverage), but the description compensates by specifying that bank_code is a 4-digit bank code and branch_code is a 3-digit branch code (支店コード). This adds concrete format meaning beyond the schema's empty strings.

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 uses the specific verb 'Look up' with a clear resource ('bank branch') and explicitly defines the required identifiers (4-digit bank code + 3-digit branch code). This distinguishes it from sibling tools like lookup_bank, which operates at the bank level.

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 implies usage for branch lookup by stating the exact input formats, but it does not provide explicit guidance on when to choose this over sibling tools like lookup_bank or search_banks. No exclusions or alternatives are mentioned.

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 present, so the description carries the full burden. It discloses a significant behavioral trait: results come from a live API only when NTA_APP_ID is set, otherwise it falls back to bundled synthetic data that is 'clearly tagged.' This prevents misinterpretation of data provenance and is highly valuable for the agent.

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: the first states the core purpose, the second explains the data source and fallback behavior. Every word earns its place; no fluff or redundancy.

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 a simple 1-parameter interface and an output schema present, the description appropriately focuses on behavior. It covers what data is returned, the conditional external dependency, and the synthetic fallback. It does not discuss error handling or prerequisites like NTA_APP_ID setup, but that is beyond the essential context for selection and 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?

The schema only defines 'number' as a string with no description, so coverage is 0%. The description partially compensates by specifying '13-digit corporate number,' adding a length constraint not present in the schema. However, it does not clarify format validation or normalization behavior, leaving a 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 uses a specific verb 'enrich' and clearly identifies the resource (13-digit corporate number) and the expected result (registry data including name, address, kind, dates). This distinguishes it from sibling tools like validate_corporate_number and search_corporations_by_name.

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 implies usage: apply when you have a corporate number and need registry data. It does not explicitly name alternatives but the context makes it obvious. It also adds a critical caveat about synthetic vs real data depending on NTA_APP_ID, which guides the agent in deciding whether to trust the output.

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 burden of behavioral disclosure. It states that matching supports multiple scripts and returns specific fields, which are useful behavioral traits. However, it does not disclose behavior like case sensitivity (for romaji), sorting, or pagination behavior. Despite this, it conveys a read-only search operation clearly and adds meaningful context beyond the schema.

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, well-structured sentence that front-loads the main action ('Search Japanese banks by name fragment') and packs details (scripts, return fields) into a compact parenthetical. Every word contributes meaning; there is no fluff or redundancy apart from the minor overlap between kana and hiragana.

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 search tool with an output schema, the description is reasonably complete: it explains what it searches, what the query means, and what it returns. Missing elements are explicit guidance on when to use vs lookup_bank, and the purpose of max_results. These are minor gaps that do not hinder the core usability.

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 compensate. It explains that the 'query' parameter is a name fragment, which is valuable. However, 'max_results' is not described at all, leaving the agent to infer its purpose from the schema name/default. Partial compensation: one of two parameters is clarified, but the missing explanation for max_results is a notable 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 clearly states the tool searches Japanese banks by name fragment, distinguishing it from sibling tools like lookup_bank which likely uses exact codes. It specifies supported scripts (kanji/kana/hiragana/romaji) and return values (zengin codes + names), making the purpose immediately clear.

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 implies when to use the tool: when you have a partial bank name and need matching zengin codes. It doesn't explicitly mention alternatives or exclusions, but the context of searching by fragment is clear. Sibling tools like lookup_bank or lookup_branch are not referenced, but the usage context is unambiguous enough for an agent.

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 transparency burden. It discloses a key behavioral trait: the data source depends on NTA_APP_ID and falls back to bundled synthetic data. It also signals partial matching, which is not inferable from the schema alone.

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 one concise, front-loaded sentence stating the action and the environment-dependent behavior. There is no filler or redundant restatement of the 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?

Since an output schema is present, return values are already specified and need not be repeated. The description covers the core purpose and conditional data source, though it omits explicit mention of result limits; the `max_results` parameter partially addresses this.

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 compensate. It clarifies that `name` accepts a partial string, adding meaning beyond the bare 'string' type. The `max_results` parameter is not mentioned, though its name and default value provide some implicit meaning.

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 opens with 'Search corporations by (partial) name,' a specific verb-object pair that clearly identifies the resource and matching behavior. It distinguishes this tool from siblings like validate_corporate_number and search_banks.

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 specifies when the live API is used (when NTA_APP_ID is set) and when the synthetic fallback applies. It does not explicitly name alternative sibling tools, but the search-vs-lookup/validate distinction is clear from the name and sibling list.

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 of disclosure. It adds key behavioral traits: offline operation and that it does NOT confirm registry existence. This is useful context beyond a basic 'validates a number' statement, though it doesn't detail edge-case behavior (e.g., response format or error handling), which is partially covered by the output schema.

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 fluff. Front-loaded with action and target, then a crucial limitation. Every word earns its place.

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 validation tool with an output schema present, the description covers purpose, usage, limitations, and parameter meaning. It also differentiates clearly from sibling tools. No obvious gaps for an agent to select and invoke it correctly.

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 schema provides only a type (string) with zero description coverage. The tool description compensates by specifying the parameter must be a 13-digit Japanese corporate number, giving both semantics and a length constraint. This goes beyond the schema's minimal information.

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 clearly states the tool's purpose: validate a 13-digit Japanese corporate number using format and check-digit rules. It explicitly distinguishes from sibling tool lookup_corporate_number, which confirms registry existence.

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 explicitly says when to use this tool (offline validation) and when not to (not for confirming existence), directing users to use lookup_corporate_number for that purpose. This is clear usage guidance with an explicit alternative.

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