split_japanese_nameSplit a Japanese personal name into family and given parts using IPAdic person-name POS tags (with whitespace/length heuristics as fallback). Returns family, given, and a confidence score (0-1; warning when low). Useful for normalizing name fields in HR, CRM, or form data. Source: Shirabe Text API.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A Japanese personal name, e.g. 山田良介. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only operation. The description adds useful behavioral details: uses IPAdic POS tags and heuristics, returns confidence score with warnings for low confidence, and cites the source. This goes beyond annotations without contradiction.
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 concise (two sentences plus source note), front-loaded with the core purpose and method, and every sentence adds value. No excessive 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 tool has one required parameter, no output schema. The description explains the return values (family, given, confidence) and warns about low confidence. However, it does not specify the exact output structure (e.g., object fields), which would improve completeness given the lack of output schema.
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 a clear parameter description. The description adds an example and context about splitting, but does not significantly expand on the schema's description. 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 the tool splits a Japanese personal name into family and given parts, using specific methods. It distinguishes itself from sibling tools like normalize_japanese_address and corporation_lookup by focusing on name splitting.
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 mentions use cases (normalizing name fields in HR, CRM, form data), providing context for when to use. It does not explicitly state when not to use or compare to alternatives, but the purpose is clear enough for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: corporate number lookup vs. search, calendar lookup, address normalization, and name splitting. No overlap, and the corporation tools explicitly cross-reference each other.
Tools generally use snake_case verb_noun pattern, but 'lookup_calendar' begins with 'lookup' while others place the verb after the noun (e.g., 'corporation_lookup'), creating minor inconsistency.
5 tools is well-scoped for a Japan data hub, covering core areas (corporations, addresses, names, calendar) without being too few or too many.
The tools cover key operations but leave gaps common for a data hub, such as address lookup by postal code, phone normalization, or reverse geocoding. No CRUD cycles exist, but each tool is a standalone lookup.