Skip to main content
Glama

Resolve Japanese entity from English name or identifier

jp_company_resolve
Read-onlyIdempotent

Find the Japanese legal entity from an English or brand name (e.g. au -> KDDI), English address, website or e-mail domain, T-number, corporate number, LEI or securities code; results in English. Brand matches are candidates, never a confirmation. Use when: You hold an English, brand or romanized Japanese company name, an English address or postal code, a website or e-mail domain, a T-number, corporate number, LEI or securities code and need the Japanese legal entity, in English. Returns: Decision (matched / likely_match / candidates), legally binding Japanese name, kana, English name with source, contract party name, status and qualified-invoice registration. Brand names (au, MOS Burger) find the owner as candidates; listing, Wikidata prominence and gBizINFO employee counts only order candidates. Price: $0.25 USDC per successful call, paid with x402 on Base. / 英語名・ブランド名(例: au→KDDI)・英語住所・ドメイン・T番号・法人番号・LEI・証券コードから日本の法人を特定します。ブランド名の一致は候補であり、確定ではありません。 用途: 英語名・ブランド名・ローマ字・英語住所・郵便番号・Webサイト/メールのドメイン・T番号・法人番号・LEI・証券コードから日本の法人を特定したい場合。 返却: 判定、正式な日本語商号、読み、出典付き英語名、契約当事者名、状態、適格請求書登録を返します。ブランド名(au、MOS Burger)からは所有企業を候補として返し、上場・Wikidataの知名度・Gビズインフォの従業員数は候補の並び順だけに使います。 料金: 成功した呼び出し1回あたり $0.25 USDC(Base上のx402決済)。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "jp_company_resolve"
  }
}

Input Schema

NameRequiredDescriptionDefault
leiNoLegal Entity Identifier (20 characters).
dunsNoD-U-N-S number; echoed only and never verified.
nameNoEnglish, romanized or Japanese company name. / 会社名(英語・ローマ字・日本語)。
emailNoA contact e-mail at the company; only its domain is used, and free webmail domains are ignored. The address itself is not stored. / 企業のメールアドレス(ドメインのみ使用)。
addressNoAddress in English or Japanese, e.g. 1-10-1 Higashikotari, Nagaokakyo-shi, Kyoto. Postal code, prefecture, municipality and town are compared with each candidate's registered address. / 住所(英語・日本語)。郵便番号・都道府県・市区町村・町名を登記住所と比較します。
websiteNoCompany website, e.g. https://www.example.co.jp; its domain is compared with the official websites we know (Wikidata). / 企業のWebサイト。
t_numberNoQualified invoice registration number, T + 13 digits (登録番号); the check digit is verified.
prefectureNoPrefecture in English or Japanese, e.g. Tokyo, Osaka-fu, 京都府. / 都道府県。
postal_codeNoJapanese postal code, e.g. 100-0005. / 郵便番号。
max_candidatesNoMaximum candidates returned for a name search.
securities_codeNoJapanese securities code, e.g. 6981. / 証券コード。
corporate_numberNo13-digit corporate number (法人番号); the check digit is verified.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, open-world, non-destructive, so the description is free to add what they cannot: the meaning of the returned decision (matched / likely_match / candidates), the explicit warning that brand matches are candidates and never a confirmation, the ranking caveat that listing, Wikidata prominence and gBizINFO employee counts only order candidates, and the cost model ($0.25 USDC per successful call via x402 on Base). That is exactly the extra context an agent needs before spending money on a call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded and segmented into purpose, 'Use when:', 'Returns:' and 'Price:', so an agent can skim to what it needs. The cost is a full mirror in Japanese that doubles the length without adding information for one of the two audiences, and the 'Use when:' list largely repeats the opening enumeration.

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?

With 12 all-optional parameters and no output schema, the description carries the full burden and meets it: it explains the decision semantics, the specific returned fields (legally binding Japanese name, kana, sourced English name, contract party, status, qualified-invoice registration), and the pricing/auth requirement. Nothing an agent needs to call it correctly and interpret the result is missing.

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 100%, so the schema already documents every parameter including the DUNS 'echoed only, never verified' caveat and the domain-only handling of e-mail. The description only restates the accepted identifier families and adds the au -> KDDI brand example, which is marginal value over the schema; baseline 3 applies.

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?

States a specific verb and resource ('Find the Japanese legal entity') and enumerates the exact input types it accepts (English/brand/romanized name, address, domain, T-number, corporate number, LEI, securities code) plus the output language. It is highly distinctive, but it never names a sibling such as jp_company_verify or jp_supplier_resolve, so the agent must infer the boundary itself.

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 explicit 'Use when:' clause gives a clear triggering condition: the caller holds an English/brand/romanized name, English address, domain, or identifier and needs the Japanese legal entity. There is no when-not guidance and no named alternative, so routing among the sibling verify/resolve/issuer tools is left to the agent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources