Torify — Japan Locale APIs for AI Agents
Server Details
39 Japanese locale APIs — wareki, NTA invoice, 法人番号, postal, romanization, kanji-kana (Workers AI).
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- torify-dev/torify-examples
- GitHub Stars
- 0
- Server Listing
- Torify — Japanese Locale APIs for AI Agents
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.
Tool Definition Quality
Average 3.9/5 across 20 of 20 tools scored.
Every tool is duplicated with a torify_ prefix, creating complete ambiguity about which version to use. The duplicates have identical descriptions, so agents cannot distinguish them.
The non-prefixed tools use dot notation (e.g., geo.geocode) while the prefixed ones use underscores (torify_geo.geocode), mixing conventions. The prefix itself is redundant and inconsistent.
20 tools is on the high side, but only 10 are unique. The duplication inflates the count unnecessarily, making the server feel heavier than it is. The actual scope is reasonable.
The 10 unique tools cover geocoding, reverse geocoding, corporate lookup, invoice validation/verification, kanji conversion, law search, romanization, postal lookup, and wareki conversion. Minor gaps exist (e.g., address validation) but core workflows are covered.
Available Tools
20 toolsgeo.geocodeJapan Address GeocoderARead-onlyIdempotentInspect
Geocode a Japanese address string to latitude/longitude via GSI (国土地理院) AddressSearch API (no auth required). Address format only — landmark names and station names are not supported. 日本語: 住所形式のみ対応・ランドマーク名・駅名は非対応
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Japanese address string in address format (e.g. 東京都千代田区丸の内一丁目). Landmark/station names (e.g. 東京駅) are not supported. / 住所形式（例: 東京都千代田区丸の内一丁目）。ランドマーク名・駅名は非対応 |
Output Schema
| Name | Required | Description |
|---|---|---|
| lat | Yes | 緯度 |
| lng | Yes | 経度 |
| title | Yes | 正規化住所 |
| source | Yes | データソース |
| addressCode | Yes | 住所コード |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds useful behavioral context: uses specific API, no authentication required, which is beyond 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?
Extremely concise: two sentences. Front-loaded with action. No 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?
Complete for a simple tool: one param, output schema exists, annotations cover safety. Title clarifies Japanese address focus.
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?
Input schema has 100% coverage for one parameter (q). Description does not add additional semantic meaning beyond the schema's description and example.
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 it gets lat/lng from address string, mentions specific API and no auth needed. Differentiates from sibling geo.reverseGeocode (reverse geocoding) implicitly.
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?
Describes when to use (get coordinates from address) but does not explicitly mention when not to use or provide alternatives. Sibling tools exist but no guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geo.reverseGeocodeJapan Reverse GeocoderARead-onlyIdempotentInspect
Reverse geocode lat/lng to municipality code and town name via GSI (国土地理院) reverse-geocoder API. 日本語: 緯度経度 → 市区町村・町名
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | 緯度（日本領域: 20-46） | |
| lon | Yes | 経度（日本領域: 122-154） |
Output Schema
| Name | Required | Description |
|---|---|---|
| town | Yes | 町名 |
| source | Yes | データソース |
| muniCode | Yes | 市区町村コード |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent behavior. The description adds that the tool uses the GSI reverse-geocoder API and returns specific address components, providing useful context beyond the 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 two sentences: one for purpose and one for API source. It is concise, front-loaded with the main action, and contains no unnecessary 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?
The description specifies domain (Japan), output components, and underlying API. Given the presence of an output schema, it is mostly complete. It could mention coordinate order or error behavior, but not critically 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?
Input schema provides 100% coverage with descriptions for both lat and lon, including valid ranges for Japan. The tool description does not add additional parameter-specific meaning, so baseline score 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 tool obtains address (municipality code, town name) from latitude/longitude, specifying it is a reverse geocoder. It differentiates from sibling geo.geocode which is forward geocoding, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reverse geocoding in Japan, but does not explicitly state when to use it versus alternatives like geo.geocode. It lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
houjin.lookupJapanese Corporate Number LookupARead-onlyIdempotentInspect
Look up Japanese corporate number (法人番号, 13 digits) → company name, address, kind, and status via NTA official API. 日本語: 法人番号 → 企業情報（社名・住所・種別・状態）
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | 法人番号（13桁の数字、例: 7000012050002） |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | 法人種別 |
| name | Yes | 法人名 |
| nameEn | No | 法人名（英語） |
| source | Yes | データソース |
| status | Yes | 法人状態 |
| address | Yes | 住所 |
| nameKana | No | 法人名（フリガナ） |
| lastUpdated | No | 最終更新日 |
| houjinBangou | Yes | 法人番号（13桁） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. Description adds the specific data fields returned and the API source, which is helpful beyond annotations. No contradiction detected.
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 that front-load the purpose and include essential context (data fields, API source). No unnecessary 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 an output schema exists, the description sufficiently explains return values (name, address, legal type, status). It covers the basic inputs and outputs without over-explaining.
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 only parameter 'number' is fully described in the schema (13-digit numeric string with example). The description adds context that it's a Japanese corporate number, enhancing usability.
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 retrieves corporate information (company name, address, legal type, status) from a 13-digit corporate number, citing the source API. This distinguishes it from sibling tools like postal.lookup and invoice.validate.
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?
While it doesn't explicitly list when to use or not use, the context of sibling tools (invoices, kana, romanization, postal, wareki) makes it clear this tool is for Japanese corporate number lookups. The description mentions the source API, implying it requires a valid number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice.validateInvoice Number Format ValidatorARead-onlyIdempotentInspect
Validate Japanese qualified invoice number (T-number) format and check digit. T + 13 digits. 日本語: 適格請求書番号フォーマット・チェックデジット検証
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | インボイス番号（例: T7000012050002） |
Output Schema
| Name | Required | Description |
|---|---|---|
| type | No | 番号種別 |
| input | Yes | 入力値 |
| valid | Yes | フォーマットおよびチェックデジットが正しいか |
| format | Yes | バリデーション結果コード |
| checkDigit | No | チェックデジット詳細 |
| houjinBangou | No | T を除いた13桁の法人番号部分 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that the tool checks both format and check digit, which is behavioral context beyond the annotations. It does not contradict 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 two sentences, front-loaded, and contains no unnecessary words. Every sentence adds value, meeting conciseness and structure criteria.
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 output schema exists, the description does not need to detail return values. It covers the core purpose and validation scope, though it could optionally mention that the tool is read-only and idempotent (already in annotations). Completeness is high.
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 an example for the 'number' parameter. The description adds the format pattern (T+13 digits) which is not present in the schema description, thus providing added value 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 validates the format and check digit of invoice numbers (適格請求書発行事業者登録番号) with a specific pattern T+13 digits. This distinguishes it from siblings like houjin.lookup and invoice.verify, which have different purposes.
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 does not explicitly indicate when to use this tool versus alternatives like invoice.verify. It provides no guidance on exclusions or comparison contexts, leaving the agent to infer based on purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invoice.verifyInvoice Number NTA VerificationARead-onlyIdempotentInspect
Verify invoice number registration against NTA public registry API. Returns registrant name, address, and registration date. Requires INVOICE_APP_ID (free, apply via NTA). 日本語: インボイス番号の実在を NTA 公表サイトで確認
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | インボイス番号（例: T7000012050002） |
Output Schema
| Name | Required | Description |
|---|---|---|
| input | Yes | 入力値 |
| source | Yes | データソース |
| cancelDate | No | 取消日（nullの場合は未取消） |
| disclaimer | No | 国税庁利用規約に基づく免責表示 |
| registered | Yes | 登録されているか |
| registrantName | No | 登録事業者名 |
| registrationDate | No | 登録日 |
| registrantAddress | No | 登録事業者住所 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and openWorld. The description adds valuable context: it calls an external NTA API, requires a free app ID, and checks existence. 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?
Two concise sentences that front-load the purpose and key requirement. No wasted words; 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?
Given the simple input (one parameter), available annotations, and an output schema (not shown but present), the description is complete enough. It covers purpose, external dependency, and configuration, leaving no major gaps.
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 description of the 'number' parameter and an example. The description does not add additional parameter meaning beyond the schema, so 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 that the tool verifies the existence of an invoice registration number using the NTA public site API, distinguishing it from siblings like invoice.validate which may validate a different aspect. It uses specific verbs and resources.
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 a prerequisite (INVOICE_APP_ID required) but does not explicitly state when to use this tool versus alternatives like invoice.validate or houjin.lookup. Usage context is implied but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kanji.toKanaKanji to Kana ConverterARead-onlyIdempotentInspect
Convert kanji-containing Japanese text to hiragana or katakana using Cloudflare Workers AI (Qwen 1.5 14B, Japanese/Chinese optimized). 日本語: 漢字→かな変換（ひらがな／カタカナ）
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 変換するテキスト（最大500文字） | |
| output | No | 出力形式（既定: hiragana） |
Output Schema
| Name | Required | Description |
|---|---|---|
| kana | Yes | ひらがな/カタカナ変換結果 |
| input | Yes | 入力テキスト |
| output | Yes | 出力形式（hiragana または katakana） |
| source | Yes | 変換エンジン |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world behavior. The description adds the use of an external service (Yahoo! JLP), which is useful context, but does not disclose error handling, limitations, or dependency specifics.
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?
A single sentence that is front-loaded with the core function and includes the service source. No extraneous words; every part 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?
For a simple tool with 2 parameters, good annotations, and an output schema (acknowledged but not needed to describe), the description is mostly complete. It mentions the external service, which adds context. Minor gap: no example or note on handling of non-kanji text.
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?
Input schema covers both parameters with descriptions (100% coverage). The description adds no additional parameter meaning beyond stating the conversion direction, so it meets the baseline without extra value.
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 converts Japanese text containing kanji to hiragana or katakana, using a specific external service. This distinguishes it from sibling tools like name.romanize (romaji) and wareki.convert (date).
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 for hiragana/katakana conversion but does not explicitly state when to use this tool over alternatives or provide exclusions. The agent can infer, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
law.searchJapan Law SearchARead-onlyIdempotentInspect
Search Japanese laws by title via e-Gov Hourei API v2 (no auth required). Returns law ID, number, title, and promulgation date. 日本語: 法令タイトル検索（e-Gov 法令 API v2）
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数（1-50、既定: 10） | |
| title | Yes | 法令タイトル（部分一致、例: 労働基準法） |
Output Schema
| Name | Required | Description |
|---|---|---|
| laws | Yes | 法令一覧 |
| count | Yes | 取得件数 |
| total | Yes | 総ヒット件数 |
| source | Yes | データソース |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, providing a strong behavioral profile. The description adds value by noting the use of a specific external API and that no authentication is needed, which is beyond the annotations. 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 exceptionally concise: two sentences that cover purpose, data source, and authentication requirements. Every sentence adds value, with no redundant information. It is front-loaded and appropriate for the tool's simplicity.
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 tool's low complexity (2 parameters, output schema exists, rich annotations), the description is mostly complete. It mentions the external API and authentication status, but lacks details on potential error messages or pagination behavior. However, with output schema and annotations, this is sufficient.
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?
Input schema has 100% description coverage for both parameters (title and limit), so the schema itself provides full parameter meaning. The tool description does not add any additional semantic information beyond the schema, meeting the baseline for high coverage.
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 that the tool retrieves law information (ID, number, title) from a law title. It specifies the data source (e-Gov Law API v2) and that authentication is not required. The title 'Japan Law Search' aligns with the description, and it is distinct from sibling tools like geo.geocode or postal.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?
The description implies the tool is for searching Japanese law by title and mentions it uses an external API without authentication. While it does not explicitly state when not to use it or name alternatives, the context of sibling tools (all in different domains) makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
name.romanizeJapanese Name RomanizerARead-onlyIdempotentInspect
Hepburn romanize Japanese names (katakana/hiragana) in passport style. Supports family-first and given-first order. 日本語: 日本人名のヘボン式ローマ字化（パスポート方式）
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Japanese name in katakana or hiragana. Kanji input is returned as-is (not converted). Add space between family and given name to split parts. / カタカナ必須・漢字入力時は変換されません。姓名の間にスペースを入れると姓/名を分離して変換 | |
| order | No | family-first: family name first / 姓名順（既定）, given-first: given name first / 名姓順 |
Output Schema
| Name | Required | Description |
|---|---|---|
| input | Yes | 入力値 |
| order | No | 適用した名前順序 |
| parts | No | 姓名に分離できた場合の各パーツ |
| romaji | Yes | ローマ字変換結果（例: SUZUKI ICHIRO） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's addition of 'modified Hepburn romanization' provides useful standard-specific context. It does not disclose edge cases or error behavior, but the annotations cover safety.
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 sentence that is front-loaded with the key action and context. It is concise but limited to Japanese, which may reduce accessibility for non-Japanese speakers, but given the tool's domain, this is acceptable.
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 output schema exists and annotations are provided, the description is sufficient for its domain. It explains the purpose and standard, though it could briefly outline what 'modified Hepburn' entails for complete self-containment.
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%. The description adds no extra meaning beyond what the schema provides; the schema already describes both parameters adequately. 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 ('converts'), the resource ('Japanese name katakana/hiragana'), the target format ('modified Hepburn romanization'), and the domain ('passport applications'). It also implicitly distinguishes itself from sibling 'kanji.toKana' by focusing on romanization.
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 specifies the use case (passport applications), which implies when to use. However, it does not explicitly contrast with siblings or state when not to use, which would raise the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
postal.lookupJapanese Postal Code LookupARead-onlyIdempotentInspect
Japanese postal code (7 digits) → prefecture, city, and town name via zipcloud (no auth required). 日本語: 郵便番号 → 都道府県・市区町村・町域
| Name | Required | Description | Default |
|---|---|---|---|
| zipcode | Yes | 郵便番号（7桁、ハイフン任意。例: 1000005 または 100-0005） |
Output Schema
| Name | Required | Description |
|---|---|---|
| kana1 | Yes | Prefecture name in katakana / 都道府県名（カタカナ） |
| kana2 | Yes | City/ward/town name in katakana / 市区町村名（カタカナ） |
| kana3 | Yes | District name in katakana / 町域名（カタカナ） |
| cityEn | No | City/ward name in English (romanized) / 市区町村名（英語・ローマ字） |
| townEn | No | District name in English (romanized) / 町域名（英語・ローマ字） |
| zipcode | Yes | Postal code (7 digits) / 郵便番号（7桁） |
| address1 | Yes | Prefecture name / 都道府県名 |
| address2 | Yes | City/ward/town name / 市区町村名 |
| address3 | Yes | District/neighborhood name / 町域名 |
| prefcode | Yes | Prefecture code / 都道府県コード |
| prefectureEn | No | Prefecture name in English (e.g. Tokyo) / 都道府県名（英語） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate those. It adds useful behavioral context: the tool uses an external API (zipcloud) and requires no authentication, which is 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 a single sentence that conveys essential information without wasted words. It is front-loaded with the primary action and quickly provides pertinent details (external API, no auth).
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 tool's simplicity (one parameter, read-only, idempotent), the description and annotations together provide complete context. The existence of an output schema further reduces the need for return-value descriptions. The mention of the external API adds helpful provenance.
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 input schema has 100% coverage with a clear description of the zipcode parameter, including examples. The description does not add additional parameter-level information beyond what the schema provides, so baseline score 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's function: retrieving address components from a 7-digit Japanese postal code. It mentions the specific API used (zipcloud) and notes no authentication is needed. This distinguishes it clearly from sibling tools like houjin.lookup or invoice.validate, which are unrelated domains.
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 context by naming the input (postal code) and output (address). Although it does not explicitly state when not to use or list alternatives, the sibling tools are sufficiently different that confusion is unlikely. The guidance is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_geo.geocodeJapan Address Geocoder [Torify namespace — official]ARead-onlyIdempotentInspect
Geocode a Japanese address string to latitude/longitude via GSI (国土地理院) AddressSearch API (no auth required). Address format only — landmark names and station names are not supported. 日本語: 住所形式のみ対応・ランドマーク名・駅名は非対応 [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Japanese address string in address format (e.g. 東京都千代田区丸の内一丁目). Landmark/station names (e.g. 東京駅) are not supported. / 住所形式（例: 東京都千代田区丸の内一丁目）。ランドマーク名・駅名は非対応 |
Output Schema
| Name | Required | Description |
|---|---|---|
| lat | Yes | 緯度 |
| lng | Yes | 経度 |
| title | Yes | 正規化住所 |
| source | Yes | データソース |
| addressCode | Yes | 住所コード |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the tool is safe and idempotent. The description adds that it uses GSI API and requires no auth, which are useful beyond annotations. It does not detail rate limits or error handling, but the core behavioral traits are well covered.
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 succinct English sentences, one Japanese sentence, and a bracketed namespace note. It immediately states the core function and constraints without wordiness. Every sentence serves a purpose.
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 adequately covers purpose, constraints, and data source. Given the presence of an output schema and informative annotations, the description is mostly complete for a simple geocoder. Missing details about potential error responses or exact output format, but these are likely covered by the 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?
Only one parameter 'q' exists, and its schema description is already very detailed and matches the tool description almost verbatim. With 100% schema coverage, the baseline is 3. The tool description reinforces the address format constraint but adds no new semantic information.
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 geocodes Japanese addresses to lat/lng via GSI API. It specifies address format only, distinguishing it from landmark/station geocoding. The title reinforces the Japan-specific scope, and sibling tools like geo.geocode are differentiated by region and data source.
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 address format only and that landmark/station names are not supported. No auth required is mentioned. While it does not name alternative tools like geo.geocode, the context implies when to use this versus a general geocoder. A score of 4 reflects clear guidance but room for explicit sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_geo.reverseGeocodeJapan Reverse Geocoder [Torify namespace — official]ARead-onlyIdempotentInspect
Reverse geocode lat/lng to municipality code and town name via GSI (国土地理院) reverse-geocoder API. 日本語: 緯度経度 → 市区町村・町名 [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | 緯度（日本領域: 20-46） | |
| lon | Yes | 経度（日本領域: 122-154） |
Output Schema
| Name | Required | Description |
|---|---|---|
| town | Yes | 町名 |
| source | Yes | データソース |
| muniCode | Yes | 市区町村コード |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds value by naming the external API (GSI), but lacks details about rate limits, authorization, or error handling.
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 (one English, one Japanese) with no superfluous information. The structure is front-loaded with purpose, followed by locale context.
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 presence of output schema, high schema coverage, and simple parameter set, the description provides sufficient context (API source, region) for correct tool 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 already provides 100% coverage with descriptions for both lat and lon (including ranges). Description does not add additional semantic meaning beyond what the schema specifies.
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 converts lat/lng to municipality code and town name via GSI API, specifying Japan region and including bilingual text. It distinguishes from sibling geo.reverseGeocode by mentioning Torify namespace and GSI source.
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 Japan-specific usage through coordinate ranges and GSI API, but does not explicitly state when to use this tool over alternatives like geo.reverseGeocode or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_houjin.lookupJapanese Corporate Number Lookup [Torify namespace — official]BRead-onlyIdempotentInspect
Look up Japanese corporate number (法人番号, 13 digits) → company name, address, kind, and status via NTA official API. 日本語: 法人番号 → 企業情報（社名・住所・種別・状態） [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | 法人番号（13桁の数字、例: 7000012050002） |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | No | 法人種別 |
| name | Yes | 法人名 |
| nameEn | No | 法人名（英語） |
| source | Yes | データソース |
| status | Yes | 法人状態 |
| address | Yes | 住所 |
| nameKana | No | 法人名（フリガナ） |
| lastUpdated | No | 最終更新日 |
| houjinBangou | Yes | 法人番号（13桁） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds that it uses the 'NTA official API' and lists output fields, but does not detail behavioral traits beyond what 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences (English and Japanese) with no waste. The key information is front-loaded and 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?
Given the presence of an output schema and annotations, the description adequately covers the tool's purpose, input format, and output fields. It does not mention error handling or rate limits, but these are not critical given other available context.
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% for the single parameter 'number', which includes a description in Japanese. The tool description adds that it is 13 digits with an example, providing minimal additional 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 looks up Japanese corporate numbers and returns company info, specifying input format and output fields. However, it does not distinguish from the sibling tool 'houjin.lookup' which appears to serve a similar purpose.
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 on when to use this tool over alternatives (e.g., houjin.lookup) or any prerequisites. The description lacks context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_invoice.validateInvoice Number Format Validator [Torify namespace — official]ARead-onlyIdempotentInspect
Validate Japanese qualified invoice number (T-number) format and check digit. T + 13 digits. 日本語: 適格請求書番号フォーマット・チェックデジット検証 [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | インボイス番号（例: T7000012050002） |
Output Schema
| Name | Required | Description |
|---|---|---|
| type | No | 番号種別 |
| input | Yes | 入力値 |
| valid | Yes | フォーマットおよびチェックデジットが正しいか |
| format | Yes | バリデーション結果コード |
| checkDigit | No | チェックデジット詳細 |
| houjinBangou | No | T を除いた13桁の法人番号部分 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, indicating safe, idempotent operation. Description adds that it validates format and check digit, providing specific behavioral context beyond 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?
Two short sentences (English and Japanese), front-loaded with core action. No redundant or unnecessary 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?
For a simple validation tool with an existing output schema, the description adequately covers purpose and core behavior. It could mention what the tool does not do (e.g., registry check) to better complete the picture.
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 Japanese example. The description's mention of 'T + 13 digits' adds a precise format constraint, offering meaning beyond the schema's example.
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 'Validate Japanese qualified invoice number (T-number) format and check digit', specifying verb and resource. It distinguishes from siblings like torify_invoice.verify by focusing on format validation, but does not explicitly differentiate.
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 on when to use this tool versus alternatives. It does not mention exclusions or when to prefer torify_invoice.verify over this tool, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_invoice.verifyInvoice Number NTA Verification [Torify namespace — official]ARead-onlyIdempotentInspect
Verify invoice number registration against NTA public registry API. Returns registrant name, address, and registration date. Requires INVOICE_APP_ID (free, apply via NTA). 日本語: インボイス番号の実在を NTA 公表サイトで確認 [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | インボイス番号（例: T7000012050002） |
Output Schema
| Name | Required | Description |
|---|---|---|
| input | Yes | 入力値 |
| source | Yes | データソース |
| cancelDate | No | 取消日（nullの場合は未取消） |
| disclaimer | No | 国税庁利用規約に基づく免責表示 |
| registered | Yes | 登録されているか |
| registrantName | No | 登録事業者名 |
| registrationDate | No | 登録日 |
| registrantAddress | No | 登録事業者住所 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, fully covering safety and idempotency. The description adds the prerequisite of an app ID but does not disclose additional behavioral traits beyond what annotations provide, such as rate limits or error handling.
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 with two English sentences plus a Japanese translation. It front-loads the main action and includes the prerequisite. While efficient, the Japanese repetition adds minor redundancy for non-Japanese agents.
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 single parameter with full schema coverage and presence of an output schema (indicated by context signals), the description adequately covers purpose, returned data, and a key prerequisite. However, it omits details on error cases or behavior when the invoice number is invalid, which would be helpful for an agent handling edge cases.
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?
Input schema coverage is 100% with a single parameter 'number' described in Japanese. The tool description does not add any new meaning or format guidance for this parameter beyond what the schema already provides, so it meets the baseline expectation.
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 invoice number registration against the NTA public registry and lists the returned data (registrant name, address, registration date). However, it does not explicitly differentiate from sibling tools like invoice.verify or torify_invoice.validate, which may cause confusion for an AI agent choosing between similar 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?
The description mentions a required prerequisite (INVOICE_APP_ID) but provides no guidance on when to use this tool versus alternatives like invoice.validate. There is no explicit statement of when-not-to-use or which sibling to prefer, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_kanji.toKanaKanji to Kana Converter [Torify namespace — official]ARead-onlyIdempotentInspect
Convert kanji-containing Japanese text to hiragana or katakana using Cloudflare Workers AI (Qwen 1.5 14B, Japanese/Chinese optimized). 日本語: 漢字→かな変換（ひらがな／カタカナ） [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 変換するテキスト（最大500文字） | |
| output | No | 出力形式（既定: hiragana） |
Output Schema
| Name | Required | Description |
|---|---|---|
| kana | Yes | ひらがな/カタカナ変換結果 |
| input | Yes | 入力テキスト |
| output | Yes | 出力形式（hiragana または katakana） |
| source | Yes | 変換エンジン |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent. The description adds useful context about using Cloudflare Workers AI and the specific model, which informs the agent about potential latency and external dependencies.
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, front-loaded with essential information, and includes a helpful Japanese translation. Every sentence provides value without redundancy.
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 tool's simplicity and the presence of an output schema, the description is mostly complete. It covers the core functionality and model context, though it lacks details on potential failure modes or character limits (handled by 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%, so the baseline is 3. The description does not add significant new meaning beyond what the parameter descriptions provide.
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 converts kanji text to hiragana/katakana using a specific AI model. However, it does not differentiate from the sibling tool 'kanji.toKana', which may have similar functionality.
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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or limitations. It only describes the core function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_law.searchJapan Law Search [Torify namespace — official]ARead-onlyIdempotentInspect
Search Japanese laws by title via e-Gov Hourei API v2 (no auth required). Returns law ID, number, title, and promulgation date. 日本語: 法令タイトル検索（e-Gov 法令 API v2） [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数（1-50、既定: 10） | |
| title | Yes | 法令タイトル（部分一致、例: 労働基準法） |
Output Schema
| Name | Required | Description |
|---|---|---|
| laws | Yes | 法令一覧 |
| count | Yes | 取得件数 |
| total | Yes | 総ヒット件数 |
| source | Yes | データソース |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) already disclose non-destructive, open-world, idempotent behavior. The description adds useful context: 'no auth required' and what fields are returned, enhancing understanding beyond 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?
Two sentences, no waste. The first sentence immediately conveys core purpose and return values. The second sentence adds a Japanese translation and namespace label without redundancy.
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 tool's simplicity, annotations, and output schema, the description covers key aspects: API source, authentication, return fields. It is adequate though could mention pagination or result size limits beyond the 'limit' parameter.
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?
With 100% schema coverage, the baseline is 3. The description does not add new semantics beyond the schema; it repeats 'by title' but gives no extra details on limit or partial matching behavior.
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 'Search Japanese laws by title via e-Gov Hourei API v2' with specific verb and resource, and mentions returned fields. However, it does not explicitly differentiate from the sibling tool 'law.search', though the 'Torify namespace' implies an official wrapper.
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 context (no auth required, simple title search) but does not mention when to use this tool over alternatives like the non-torify 'law.search' or other search tools. Usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_name.romanizeJapanese Name Romanizer [Torify namespace — official]BRead-onlyIdempotentInspect
Hepburn romanize Japanese names (katakana/hiragana) in passport style. Supports family-first and given-first order. 日本語: 日本人名のヘボン式ローマ字化（パスポート方式） [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Japanese name in katakana or hiragana. Kanji input is returned as-is (not converted). Add space between family and given name to split parts. / カタカナ必須・漢字入力時は変換されません。姓名の間にスペースを入れると姓/名を分離して変換 | |
| order | No | family-first: family name first / 姓名順（既定）, given-first: given name first / 名姓順 |
Output Schema
| Name | Required | Description |
|---|---|---|
| input | Yes | 入力値 |
| order | No | 適用した名前順序 |
| parts | No | 姓名に分離できた場合の各パーツ |
| romaji | Yes | ローマ字変換結果（例: SUZUKI ICHIRO） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (read-only, idempotent), description adds that kanji input is returned as-is and space splits family/given name. 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?
Concise two-sentence English description plus Japanese translation. Slight redundancy from '[Torify namespace — official]' but otherwise efficient.
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?
Covers core functionality, input handling, and order options. However, lacks guidance on how it differs from sibling romanization tools and does not address edge cases.
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 description only summarizes order options already in schema. No additional parameter meaning added beyond 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?
Clearly states it Hepburn romanizes Japanese names in passport style, specifying katakana/hiragana input and order options. However, it does not differentiate from sibling 'name.romanize' tool.
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 on when to use this tool over alternatives like 'name.romanize' or 'kanji.toKana'. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_postal.lookupJapanese Postal Code Lookup [Torify namespace — official]ARead-onlyIdempotentInspect
Japanese postal code (7 digits) → prefecture, city, and town name via zipcloud (no auth required). 日本語: 郵便番号 → 都道府県・市区町村・町域 [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| zipcode | Yes | 郵便番号（7桁、ハイフン任意。例: 1000005 または 100-0005） |
Output Schema
| Name | Required | Description |
|---|---|---|
| kana1 | Yes | Prefecture name in katakana / 都道府県名（カタカナ） |
| kana2 | Yes | City/ward/town name in katakana / 市区町村名（カタカナ） |
| kana3 | Yes | District name in katakana / 町域名（カタカナ） |
| cityEn | No | City/ward name in English (romanized) / 市区町村名（英語・ローマ字） |
| townEn | No | District name in English (romanized) / 町域名（英語・ローマ字） |
| zipcode | Yes | Postal code (7 digits) / 郵便番号（7桁） |
| address1 | Yes | Prefecture name / 都道府県名 |
| address2 | Yes | City/ward/town name / 市区町村名 |
| address3 | Yes | District/neighborhood name / 町域名 |
| prefcode | Yes | Prefecture code / 都道府県コード |
| prefectureEn | No | Prefecture name in English (e.g. Tokyo) / 都道府県名（英語） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and openWorld hints. The description adds that the data source is zipcloud and that no auth is needed. It does not describe output format, error behavior, or rate limits, but the behavioral profile is largely 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 extremely concise with two English sentences and a Japanese repetition. It front-loads the core action and includes a practical note on no auth. Every sentence adds clear value with no redundancy.
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 is simple (single input, external service) and has an output schema. The description covers the input format, data source, and authentication. It lacks details on error handling or rate limits, but these are minor given the low complexity and presence 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% for the single parameter `zipcode`, which already has a description in Japanese. The description adds an English note about the 7-digit format with hyphen optional and an example, providing some added context but not deeply extending schema semantics.
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 function: converting a Japanese postal code to prefecture/city/town via zipcloud. The title and description specify the Torify namespace, but do not differentiate from the sibling `postal.lookup`. The purpose is specific and actionable.
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 indicates when to use (when you have a Japanese postal code) and notes no authentication is required. However, it does not mention when not to use it or contrast with sibling `postal.lookup`, which could be confusing. No explicit alternatives or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
torify_wareki.convertJapanese Era Date Converter [Torify namespace — official]ARead-onlyIdempotentInspect
Convert between Japanese era dates (wareki) and Gregorian. Supports Meiji/Taisho/Showa/Heisei/Reiwa. Handles era boundary dates accurately. 日本語: 和暦⇔西暦変換（改元日正確処理） [Torify namespace — official]
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | Day 1-31 / 日（1〜31） | |
| era | No | Era name (Reiwa/Heisei/Showa/Taisho/Meiji or 令和/平成/昭和/大正/明治) | |
| date | No | Gregorian date YYYY-MM-DD, required when direction=g2w / 西暦日付（direction=g2w 時必須） | |
| month | No | Month 1-12 / 月（1〜12） | |
| eraYear | No | Era year (1 or greater) / 元号年（1以上） | |
| direction | Yes | g2w: Gregorian to wareki / 西暦→和暦, w2g: wareki to Gregorian / 和暦→西暦 |
Output Schema
| Name | Required | Description |
|---|---|---|
| day | No | 日（w2g 時） |
| era | No | 元号（例: 令和） |
| year | No | 西暦年（w2g 時） |
| month | No | 月（w2g 時） |
| eraYear | No | 元号年 |
| eraRomaji | No | 元号ローマ字（例: Reiwa） |
| formatted | No | フォーマット済み日付文字列 |
| eraYearLabel | No | 元号年ラベル（例: 元年） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, idempotent operation. The description adds value by noting accurate handling of era boundary dates, which is a behavioral trait beyond what annotations provide. It does not contradict 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 extremely concise: two sentences plus a Japanese translation. It conveys the core purpose, supported eras, and accuracy guarantee without unnecessary words. Every sentence earns its place, and the structure is front-loaded with the main action.
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 moderate complexity (date conversion with era boundaries) and includes an output schema, so return value explanation is unnecessary. The description covers conversion direction, supported eras, and accurate boundary handling. It lacks mention of the output format but is sufficiently complete for the task given the schema coverage and annotations.
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 the schema fully documents all parameters (direction, era, day, month, date, eraYear) with descriptions. The tool description does not add further parameter details, but baseline is 3 for high coverage. The description does not detract but adds no new semantic meaning for parameters.
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 function: converting between Japanese era dates and Gregorian. It lists the supported eras (Meiji, Taisho, Showa, Heisei, Reiwa) and emphasizes accuracy at era boundaries. The verb 'convert' and resource 'Japanese era dates' make the purpose specific and distinct from sibling tools, which are in different domains.
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 context: it converts between wareki and Gregorian, supports specific eras, and handles boundary dates accurately. However, it does not explicitly state when to use this tool versus alternatives (e.g., when a simpler conversion is needed or when not to use it). The usage is implied but not compared to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wareki.convertJapanese Era Date ConverterARead-onlyIdempotentInspect
Convert between Japanese era dates (wareki) and Gregorian. Supports Meiji/Taisho/Showa/Heisei/Reiwa. Handles era boundary dates accurately. 日本語: 和暦⇔西暦変換（改元日正確処理）
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | Day 1-31 / 日（1〜31） | |
| era | No | Era name (Reiwa/Heisei/Showa/Taisho/Meiji or 令和/平成/昭和/大正/明治) | |
| date | No | Gregorian date YYYY-MM-DD, required when direction=g2w / 西暦日付（direction=g2w 時必須） | |
| month | No | Month 1-12 / 月（1〜12） | |
| eraYear | No | Era year (1 or greater) / 元号年（1以上） | |
| direction | Yes | g2w: Gregorian to wareki / 西暦→和暦, w2g: wareki to Gregorian / 和暦→西暦 |
Output Schema
| Name | Required | Description |
|---|---|---|
| day | No | 日（w2g 時） |
| era | No | 元号（例: 令和） |
| year | No | 西暦年（w2g 時） |
| month | No | 月（w2g 時） |
| eraYear | No | 元号年 |
| eraRomaji | No | 元号ローマ字（例: Reiwa） |
| formatted | No | フォーマット済み日付文字列 |
| eraYearLabel | No | 元号年ラベル（例: 元年） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that era change dates are processed accurately, which is behavioral context beyond the annotations, though the core safety profile is already clear.
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 short sentences in Japanese, front-loaded with the main action. Every word is necessary; no redundancy or 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?
Given the existence of an output schema and annotations, the description sufficiently covers the tool's capability. It specifies supported eras and accuracy, leaving no obvious gaps for a conversion 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 all parameters described. The description does not add parameter-level details beyond the schema, so it meets the baseline expectation without additional value.
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 converts Japanese era dates to Gregorian and vice versa, listing supported eras (Meiji, Taisho, Showa, Heisei, Reiwa). This specific action distinguishes it from sibling tools which handle invoices, postal lookups, etc.
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 implies usage for date conversion but provides no explicit guidance on when to use this tool versus alternatives. No contraindications or alternatives are mentioned, though sibling tools are unrelated.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.