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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains input normalization (full-width digits, hyphens, spaces), explicitly warns about the personal number misuse risk, and discloses the limitation that it cannot determine number type. It does not describe the exact return format, but the purpose statement implies the 13-digit output, and no side effects are relevant for a pure calculation.

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 three sentences, each earning its place: the first states the purpose, the second covers input normalization, and the third provides a crucial safety warning. It is front-loaded and free of redundancy, achieving maximum clarity in minimal 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?

Given the tool's simple nature (single parameter, calculation-only, no output schema), the description covers all essential aspects: purpose, input normalization, limitations, and safety guidance. It does not need to explain return values in detail because the purpose sentence clearly indicates the output, and there are no complex side effects or prerequisites. Sibling tool relationships are not explicitly addressed, but the tool's own capability is clearly delineated.

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% for the single parameter, but the tool description adds significant value beyond the schema by detailing normalization rules (full-width, hyphens, spaces) and the safety constraint about personal numbers. This extra semantic context helps the agent correctly format input and avoid dangerous misuse.

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 specific action (calculate check digit) and resource (company corporate number to 13-digit corporate number). It distinguishes itself from sibling tools like validate_corporate_number and parse_corporate_number by focusing on calculation and explicitly noting it cannot determine number type, which is a key differentiator.

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 provides clear context: it is for converting a 12-digit company corporate number to a 13-digit corporate number and handles normalized input. It gives an explicit when-not guidance by warning against inputting personal numbers because the tool cannot distinguish types. However, it does not name alternative tools for validation or parsing, so it stops short of a 5.

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 full burden and exeeds it. It discloses return structure (verdict, evidence, machine-generated reasons), constraints on 'likely_different' (only when common prefix/suffix and clearly different remaining elements), the rationale for returning 'unknown' in ambiguous cases, confidence cap at 'medium' due to 2006 company law, and type-level enforcement that confidence cannot contradict verdict. This is exhaustive and non-redundant.

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 long but highly dense and well-structured. It front-loads the core purpose in the first sentence, then systematically addresses response format, verdict rules, edge cases, confidence constraints, and verification caveats. Each sentence introduces a distinct behavioral rule with rationale, so nothing is redundant. However, its length slightly exceeds minimal conciseness, though appropriate for the tool's complexity.

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 explain return values; it does so comprehensively by specifying the three verdict values, the evidence structure, the machine-generated nature of reasons, and the confidence constraints. It also covers all critical edge cases and the legal background for confidence capping. Given the tool's complexity and lack of structured output metadata, this description is complete and self-sufficient.

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%—both parameters (nameA and nameB) have descriptions ('比較する法人名A/B'). The tool description does not add parameter-specific semantics (e.g., required format, examples) beyond the schema. Since the schema fully documents parameters, the baseline of 3 is appropriate; the description's behavioral details don't directly enhance parameter understanding.

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 function: it normalizes and compares two corporate names, then returns a likelihood of them referring to the same entity along with reasoning and confidence. It distinguishes itself from siblings like normalize_company_name (which normalizes a single name) and generate_matching_key (which creates keys) by focusing on pairwise comparison and verdict output.

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 provides strong contextual usage guidance without explicitly naming sibling tools. It explains edge cases where the tool returns 'unknown' (character-type mismatch, prefix/suffix position difference, entity type difference), which helps an agent decide when output is unreliable. It also states that '確実な同一性判定には法人番号での突合が必要です' (definite identity requires corporate number matching), implicitly steering users to other tools for definitive verification.

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 does the heavy lifting and does disclose the transformation logic: removing legal entity suffixes, stripping whitespace, and normalizing via normalize_company_name. However, it omits details about the exact output format, edge cases (e.g., unrecognizable names), or whether the key is deterministic beyond the normalization step.

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, focused sentence that front-loads the tool's purpose and then details the transformation. It is concise with no unnecessary 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 tool with one required parameter and no output schema, the description gives enough context: input is a corporate name, transformation is specified, and the output is implicitly a matching key. Missing edge cases and explicit return-type info are minor gaps for a tool of this simplicity.

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 already covers the only parameter 'name' with a clear description ('キーを生成したい法人名'), and schema coverage is 100%. The description adds little parameter-specific detail beyond confirming that the input is a corporate name, so the baseline of 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 clearly states a specific action: generating a normalization key for name matching from a corporate name, removing legal entity suffixes and whitespace. It also distinguishes itself from sibling tools by referencing normalize_company_name as the dependency and framing the output as a matching key.

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 phrase '名寄せ用' (for name matching) provides a clear use case, and the reference to normalize_company_name indicates a workflow dependency. However, it does not explicitly contrast with alternatives like compare_company_names or state when not to use 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?

Since no annotations are provided, the description carries the full burden. It discloses behavioral traits (conversions, old character handling) and a limitation (dictionary incomplete), but does not specify the return value structure or error 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?

The description is two sentences: the first lists the core actions and scope, the second states the limitation. No extraneous detail, with the main function 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?

Given the tool's complexity and lack of output schema, the description should clarify what the returned result contains (e.g., whether both normalized full name and body are returned). The limitation is disclosed, but the return format remains ambiguous.

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 describes the single parameter as 'corporate name to normalize,' while the description enriches this by listing the types of variations handled (e.g., full-width/half-width, legal entity conversions), giving the agent a clearer idea of acceptable 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 clearly states it normalizes Japanese corporate name notation variations (e.g., 株式会社 vs (株)) and separates the legal entity to return the main name. This distinguishes it from sibling tools like validate_corporate_number or parse_corporate_number, which focus on validation or parsing.

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 Japanese company names with notation variations, but does not explicitly state when to use this tool versus alternatives. The limitation that the dictionary covers only major forms suggests it may not be suitable for exhaustive coverage, serving as a soft 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?

The description discloses that the check digit is verified first, that classification categories are returned, and that organization type labels are deliberately omitted due to lack of authoritative sources. It does not describe behavior for invalid check digits or the exact return structure, which are notable gaps given no annotations are provided.

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 concise sentences that front-load the core behavior and then mention a key limitation. Every sentence earns its place without redundancy or irrelevant detail.

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 description explains the main output components (classification, registry office code, raw organization type, serial number) and the limitation about organization type mapping. However, it lacks explicit error-handling behavior for invalid check digits and does not provide an exact return format, which would be helpful given no output schema exists.

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 parameter's format and allowed characters (full/half-width digits, hyphens, spaces) are already fully documented. The tool description adds no additional parameter syntax or examples beyond what the schema provides, so the 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 clearly states the tool's function: verifying the check digit of a corporate number and returning a breakdown into classification and component codes. It distinguishes from sibling tools like validate_corporate_number by focusing on structural parsing rather than simple validation.

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 context implies use for structural analysis of corporate numbers, which is clear from the description and title. However, it does not explicitly compare with sibling tools like validate_corporate_number or state when not to use this tool, so it falls short of full explicit guidance.

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 description discloses that inputs with full-width digits, hyphens, and spaces are normalized and accepted, and that validation is limited to format and check digit. Since no annotations are provided, the description carries the full burden and does so effectively, though it omits details about return values or error handling.

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?

Three sentences, each serving a distinct purpose: primary function, input normalization, and scope limitation. There is no redundancy, and the text is front-loaded with the core purpose.

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 description covers the tool's core behavior, input normalization, and non-existence checking, which is sufficient for a simple validation tool. The lack of an output schema and explicit return information is a minor gap, but the description is otherwise contextually complete and self-contained.

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 description already covers the allowed input formats (100% coverage), but the description adds that inputs are normalized, which is a behavioral guarantee beyond the schema's stated 'mixing allowed'. This small but meaningful addition goes beyond the schema's dry specification.

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 ('検証します' - verifies) and clearly identifies the exact resource: the check digit of a 13-digit corporate number. It also explicitly distinguishes between format validation and existence checking, which differentiates it from sibling tools that may parse or calculate check digits.

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 states that the tool only validates format/check digit and not existence, and directs users to the National Tax Agency's website for existence checks. This provides clear context about when to use this tool (for format validation) and when not to (for existence confirmation), though it doesn't explicitly name sibling tools as alternatives.

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 fully discloses behavioral traits: it explains that corporate numbers get mathematical check-digit verification, individual numbers only get format validation due to unpublished check-digit methods, and it explicitly disclaims existence/validity guarantees. This is exemplary transparency.

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 three sentences long, front-loaded with the main action ('形式を検証します'), and each sentence adds meaningful detail about the validation logic or limitations. There is no redundancy or 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?

The description thoroughly covers the input format, validation behavior for both entity types, and the tool's limitations, which is substantial given the simple single-parameter tool. However, because there is no output schema, the description could optionally mention the return value (e.g., boolean), 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 coverage for the single parameter is 100%, with the schema already describing the format ('T'+数字13桁) and allowed full-width/hyphen/space characters. The description adds no new parameter-level semantics beyond reinforcing the structure, which is already fully documented in the 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 opens with a specific verb '検証します' targeting the '適格請求書発行事業者の登録番号("T"+数字13桁)', clearly identifying the resource. It distinguishes from sibling validate_corporate_number by focusing on invoice registration numbers and even differentiates between corporate and individual number validation.

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 gives clear context for when to use the tool: it validates formats, and for corporate numbers also performs check-digit verification. It explicitly states when not to rely on it ('実在確認・登録の有効性は保証しません') and directs users to the official NTA site for existence confirmation, providing a clear boundary without naming sibling tools.

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