Japan data tools for AI agents: calendar (rokuyo), address, name splitting, corporate number lookup
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 5 of 5 tools scored.
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.
corporation_lookupLook up Japanese corporation by numberALook up a Japanese company by its 13-digit corporate number (法人番号) against the National Tax Agency (NTA) corporate-number registry. Returns the registered trade name, head-office address, change history and other public fields as JSON, plus mandatory NTA attribution. Useful when an AI agent already has a corporate number and needs canonical company facts (e.g. validating or enriching a B2B record). To go the other way (company name → number), use corporation_search. Source: Shirabe Corporation API.
| Name | Required | Description | Default |
|---|---|---|---|
| law_id | Yes | A 13-digit Japanese corporate number (法人番号), e.g. 1234567890123. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by naming the external source (NTA), mentioning mandatory attribution (NTA credit), and listing specific fields returned (trade name, address, history). No contradiction with annotations.
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 paragraph that front-loads the core action, then efficiently provides context, usage guidance, and source attribution. Every sentence contributes meaningful 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?
For a simple lookup tool with one parameter and no output schema, the description covers input format, output contents, data source, attribution requirements, and alternative tool. No critical information is missing.
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 one parameter. The description clarifies the parameter format ('13-digit corporate number') and provides an example, adding value beyond the schema's description.
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 corporation by number'), clearly states the registry (NTA) and output (trade name, address, change history). It distinguishes from sibling tool 'corporation_search' which goes the opposite direction.
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 states when to use ('when an AI agent already has a corporate number and needs canonical company facts') and when not to ('To go the other way, use corporation_search'). Provides clear context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
corporation_searchSearch Japanese corporations by nameASearch the Japanese corporate-number registry (National Tax Agency) by company name and return matching companies, each with its 13-digit corporate number (法人番号), registered name and address, plus mandatory NTA attribution. Handles trade-name variants (㈱ / (株) / 株式会社) via normalization. Useful when an AI agent has a company name and needs to resolve its corporate number / canonical record. To go the other way (number → company), use corporation_lookup. Source: Shirabe Corporation API.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A Japanese company name, e.g. 株式会社テックウェル (variants like ㈱テックウェル are accepted). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by noting that the tool handles trade-name variants via normalization and includes mandatory NTA attribution in the output, which are not covered by annotations.
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: first sentence states the core purpose and return values, second sentence notes variant handling, third sentence provides usage guidance and sibling reference. No fluff.
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 read-only tool with one parameter, the description is comprehensive. It explains what is returned, variant handling, source, and alternative tool. No output schema exists, but the description adequately covers return values.
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 'name' is fully described in the input schema (100% coverage). The description enhances this by providing an explicit example and noting that variants like ㈱ are accepted, adding practical guidance 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 the tool searches the Japanese corporate-number registry by company name and returns matching companies with corporate number, name, address, and NTA attribution. It also distinguishes from the sibling tool corporation_lookup by specifying the direction of the lookup.
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 states when to use the tool (when an AI agent has a company name and needs to resolve its corporate number/canonical record) and when not to use it (to go the other way, use corporation_lookup). This provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_calendarLook up Japanese calendarALook up Japanese calendar information for a given date: Rokuyo (six-day cycle such as Taian/Butsumetsu), Rekichu (almanac notes), Eto (sexagenary cycle), 24 solar terms, and purpose-based auspiciousness scores. Useful when an AI agent needs canonical Japanese calendar facts (e.g. choosing an auspicious date for a wedding or ceremony). Source: Shirabe Calendar API (shirabe.dev).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Target date in YYYY-MM-DD (between 1873-01-01 and 2100-12-31). | |
| categories | No | Optional purpose categories to score (e.g. marriage, funeral, groundbreaking). Omit to return all available categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds context by naming the external data source (Shirabe Calendar API) and listing the retrieved calendar fields, enhancing transparency 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?
Two concise sentences with no unnecessary words. Front-loaded with core functionality and supported by a usage note. Every sentence adds value.
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?
No output schema exists, but description hints at the kind of data returned (Rokuyo, etc.). It could be more explicit about the response structure, but given the tool's straightforward lookup nature and full annotations, it is sufficiently 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?
Schema describes both parameters completely (100% coverage). Description reinforces the purpose of categories for scoring but adds no new semantic information beyond what the schema already provides.
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 verb 'look up' and the resource 'Japanese calendar information', listing specific contents such as Rokuyo, Rekichu, Eto, solar terms, and auspiciousness scores. It is distinct from unrelated sibling tools.
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?
Description provides a usage context: 'useful when an AI agent needs canonical Japanese calendar facts' with a concrete example. However, it does not explicitly mention when not to use or suggest alternatives, though none are needed given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
normalize_japanese_addressNormalize Japanese addressANormalize a free-form Japanese address against the official Address Base Registry (ABR, all 47 prefectures). Returns the canonical form, structured components (prefecture/city/town/block/building), postal code, WGS84 coordinates, match level (0-4) and confidence, plus mandatory CC BY 4.0 attribution. Useful when an AI agent must clean or de-duplicate Japanese B2B/customer records. Source: Shirabe Address API.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | A raw Japanese address string (may include postal code, building, floor). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: returns canonical form, structured components, postal code, coordinates, match level, confidence, and mandatory attribution. No contradiction with annotations.
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 consists of three concise sentences. The first states the primary action and source, the second lists return components, and the third provides usage context. No unnecessary words; all content 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?
Given a single parameter, no output schema, but annotations cover safety and idempotency, the description fully explains the return structure (canonical form, components, postal code, coordinates, match level, confidence, attribution) and usage context. Complete for agent decision-making.
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% with a single parameter 'address' described as 'A raw Japanese address string (may include postal code, building, floor)'. The tool description adds context about normalizing against ABR but does not significantly enhance parameter meaning beyond the schema. 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 verb 'Normalize' and the resource 'free-form Japanese address against the official Address Base Registry'. It distinguishes from siblings which deal with corporations, calendars, and name splitting, making 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 explicitly states 'Useful when an AI agent must clean or de-duplicate Japanese B2B/customer records', providing clear context for use. It does not explicitly mention when not to use, but the sibling tools are sufficiently different to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_japanese_nameSplit Japanese personal nameASplit 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!