jp-data-mcp

by kimotostudio

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: corporate number validation vs enrichment vs search, bank lookup vs search, branch lookup, and holiday list vs date check. The validate tool explicitly points to lookup for registry confirmation, eliminating any ambiguity.
Naming Consistency4/5
Six of eight tools follow a consistent verb_noun pattern (lookup_bank, search_banks, lookup_branch, etc.), but the holiday tools deviate with japan_holidays (a noun) and is_japan_holiday (is_ prefix). Minor pluralization inconsistency (search_banks vs lookup_bank) is acceptable.
Tool Count5/5
Eight tools is well-scoped for a Japan data server covering corporate registry, banking, and holidays. Each tool serves a distinct purpose and there is no redundancy.
Completeness5/5
The corporate domain has validate, lookup, and search; banking has bank/branch lookup plus search; holidays have list and check. Workflows like search-to-validate-to-lookup are supported, and there are no obvious gaps or dead ends.
Average 4.2/5 across 8 of 8 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jp-data-mcp MCP server](https://glama.ai/mcp/servers/kimotostudio/jp-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kimotostudio/jp-data-mcp)

Score Badge

Copy to your README.md:

[![jp-data-mcp MCP server](https://glama.ai/mcp/servers/kimotostudio/jp-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kimotostudio/jp-data-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kimotostudio/jp-data-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server