HojinCheck — Japanese corporate verification API (hojin = 法人/corporate entity)

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

No annotations provided, so description must carry full burden. It states the tool returns metadata with source and acquisition date, but does not disclose error handling (e.g., invalid number), rate limits, or authentication needs.

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, front-loaded with purpose, no wasted words. Efficient and clear.

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 without output schema, the description adequately explains input, output contents, and data source. Slight lack of error or behavioral details, but sufficient for basic use.

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 schema description already details check digit verification and formatting absorption. The tool description adds no significant meaning beyond 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?

Description clearly states the tool returns corporate profile (location, representative, capital, employees) from a corporate number using gBizINFO. It distinguishes from siblings like resolve_company and verify_company by specifying the detailed profile 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?

No explicit guidance on when to use this tool vs siblings. The description implies use when full profile is needed, but does not mention when not to use or 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 carries the full burden. It discloses data sources (official CSV), business day definition, and parameter effect (year_end_as_holiday). It does not mention limitations, error handling, or whether operations are read-only, but the behavioral context is substantial for a computational 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?

The description is two concise sentences with no wasted words. It front-loads the core purpose and follows with key details. Every sentence 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?

The description covers the main functionality but lacks information about return values. Since there is no output schema, the description should mention what each operation returns (e.g., boolean for is_business_day, date string for next_business_day, list for list_holidays). This gap prevents full understanding of the tool's output.

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 baseline is 3. The description adds value by explaining the business day rule and the year_end_as_holiday parameter's effect beyond the schema's property descriptions. It clarifies that 'year_end_as_holiday=true' treats Dec 29-Jan 3 as non-business days, which is not covered 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 clearly states the tool's purpose: Japanese holiday determination and business day calculation, referencing the official Cabinet Office CSV. It defines business days as excluding weekends and holidays, and explains the year_end_as_holiday parameter behavior. This is distinct from sibling tools which focus on company info and address verification.

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 the tool is for Japanese calendar operations but does not explicitly state when to use it over alternatives. No exclusions or comparisons to sibling tools are provided. The usage context is inferred from the name and description rather than explicitly guided.

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 carries the burden of disclosing behavior. It details data sources (Address Base Registry, Japan Post), states it uses local master (no API dependency), explains the checking of postal code inconsistencies, and explicitly lists unsupported elements (block numbers, etc.). No contradictions.

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 well-structured with a separate section on limitations. It is front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise (e.g., repeating 'address' multiple times).

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 2 parameters and no output schema, the description is remarkably complete. It explains the decomposition level, what is returned (including residuals), data sources, and postal code matching behavior. No gaps remain for intelligent 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?

Schema coverage is 100%, so baseline is 3. The description adds extra meaning: postal_code overrides any embedded code, and address can handle various character formats. This goes beyond the schema descriptions.

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 normalizes Japanese addresses, decomposes into administrative units, resolves town ID, and checks postal code. It also explicitly lists limitations (v1 granularity, what is not parsed), making the purpose very specific and distinct from siblings.

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 a clear context of what the tool does and its limitations (e.g., no block/house number parsing), which helps an agent decide if it fits the use case. However, it lacks explicit 'when to use' or 'when not to use' statements or references to alternatives, though siblings are unrelated.

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 burden. It discloses data source and that results include confidence and evidence labels, but does not mention error handling, rate limits, or behavior when no match is found. Basic transparency but gaps remain.

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 and includes the data source. No redundant or 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?

Given the lack of output schema and annotations, the description provides minimal context beyond core functionality. It hints at output structure (candidates, confidence, evidence label) but lacks details on error handling, pagination, or interpretation of results.

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 each parameter has a description. The tool description adds overall context (notation variations, confidence) but does not meaningfully extend parameter meaning beyond what the schema already provides. Baseline score of 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 clearly states the verb (returns), resource (corporate number candidates and confidence), and input (company name with notation variations). It distinguishes from siblings like get_company_profile and verify_company by focusing on name-based resolution.

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 when you have a company name and need the corporate number, but it does not explicitly state when to use this versus alternatives, nor does it provide when-not-to guidance. Usage context is inferred from the sibling tool names.

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 mentions the data source (National Tax Agency) and the check digit verification, but it does not disclose error handling, rate limits, or authentication requirements. Without annotations, this leaves gaps 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?

The description is two sentences with no redundant information. It front-loads the main action and clearly explains the optional parameter in the second 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?

For a tool with two simple parameters and no output schema, the description covers inputs, outputs, and data source sufficiently. However, it would benefit from mentioning expected return format or error scenarios.

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 baseline is 3. The description adds context about the 13-digit format and check digit, but mostly reinforces what is in the schema. No additional parameter semantics beyond 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 clearly states it verifies existence and returns various corporate data from a 13-digit corporate number. However, it does not explicitly differentiate itself from sibling tools like resolve_company, which may cause confusion for an AI agent.

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 such as get_company_profile or resolve_company. The description does not include any when-not-to-use conditions or context.

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. It discloses the data source (NTA Web-API) and the returned information (status, date, history). However, it does not mention behavioral traits like authentication, rate limits, or side effects (e.g., read-only nature). This is adequate but not thorough.

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 paragraph that efficiently conveys all key points: purpose, input, optional parameters, data source, and limitations. While it could be more structured (e.g., bullet points), it is concise and front-loaded with the most critical 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?

There is no output schema, so the description must explain return values. It does so by listing registration presence, date, cancellation/invalidation, and optional history. However, it does not detail the exact response structure (e.g., field names like 'valid', 'as_of'), which would enhance completeness for an agent invoking the 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 coverage is 100% with descriptions for all three parameters. The description adds value by explaining the effect of on_date on validity and include_history for publication history. It also clarifies the accepted format for registration_number, including variations like T-less, full-width, and hyphens, which is beyond 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 clearly identifies the tool as verifying a specific Japanese invoice registration number (T+13 digits) and retrieving registration status, date, and cancellation/invalidation. It distinguishes itself from sibling tools by explicitly stating that name-based searches are not provided, implying it is specialized for invoice number verification.

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 explains the required input (registration number only) and optional parameters (on_date, include_history). It implicitly guides usage by stating what it does not do (no name search), providing context for when to use this tool over sibling tools like verify_company. However, it does not explicitly state 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.