Japan Finance Reference Checks

Japan FSA register and warning list check

jp_fsa_registry_lookup

Read-only

Is this business (name, registration or 13-digit corporate number) on a Japan FSA register or warning list? Exact match (optional domain) against FSA registers (financial instruments, crypto-asset exchange, electronic payment instruments, funds transfer, money lending) and warnings to unregistered businesses. Returns matches with registration type, entity tie (domain alone: unverified), name candidates and as-of dates. Stated scope only; no warning match is not proof none exists. No advice.

Input Schema

Name	Required	Description
`name`	No	Business name as written, e.g. 株式会社SBI証券 or Bybit Fintech Limited
`domain`	No	Optional domain or URL, e.g. example.com
`number`	No	Registration number (e.g. 関東財務局長(金商)第44号) or 13-digit corporate number

Output Schema

Name	Required	Description
`note`	Yes
`query`	Yes
`terms`	Yes	URL of the terms of service.
`provenance`	Yes	Freshness receipts for every upstream source used.
`answered_at`	Yes
`interpreted`	Yes
`not_covered`	Yes
`source_errors`	Yes
`name_candidates`	Yes	Partial name matches, NOT confirmed to be the same entity.
`sources_checked`	Yes
`coverage_complete`	Yes	True only when every FSA list was loaded and recently verified.
`entity_resolution`	Yes	How the query ties to a listed entity. A domain alone is always unverified.
`warning_statement`	Yes	The warning-list result in one statement, with the scope and as-of dates checked.
`domain_association`	Yes
`warning_exact_matches`	Yes	Exact matches in FSA warnings to unregistered businesses.
`registry_exact_matches`	Yes	Exact matches in FSA registers of licensed businesses, each with its registration type and, where marked in the register, business categories.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 16, 2026

addedOutput schema / properties / entity_resolution

Added value: +{
+  "additionalProperties": {},
+  "description": "How the query ties to a listed entity. A domain alone is always unverified.",
+  "properties": {
+    "basis": {
+      "enum": [
+        "domain_only",
+        "name",
+        "number",
+        "name_and_number"
+      ],
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "exact_identifier",
+        "exact_listed_name",
+        "listed_alias",
+        "candidate",
+        "ambiguous",
+        "unverified"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "basis",
+    "note"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / registry_exact_matches / description

Previous value: -"Exact matches in FSA registers of licensed businesses."New value: +"Exact matches in FSA registers of licensed businesses, each with its registration type and, where marked in the register, business categories."

addedOutput schema / properties / registry_exact_matches / items / properties / business_categories_ja
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```

addedOutput schema / properties / registry_exact_matches / items / properties / registration_type

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "financial_instruments_business",
+        "crypto_asset_exchange_service",
+        "electronic_payment_instruments_exchange_service",
+        "funds_transfer_service",
+        "money_lending_business"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / registry_exact_matches / items / required
```
Added value: +[
+  "registration_type",
+  "business_categories_ja"
+]
```

addedOutput schema / properties / warning_statement

Added value: +{
+  "description": "The warning-list result in one statement, with the scope and as-of dates checked.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "query",
-  "interpreted",
-  "registry_exact_matches",
-  "warning_exact_matches",
-  "name_candidates",
-  "domain_association",
-  "sources_checked",
-  "coverage_complete",
-  "source_errors",
-  "not_covered",
-  "note",
-  "answered_at",
-  "provenance",
-  "terms"
-]New value: +[
+  "query",
+  "interpreted",
+  "entity_resolution",
+  "registry_exact_matches",
+  "warning_exact_matches",
+  "warning_statement",
+  "name_candidates",
+  "domain_association",
+  "sources_checked",
+  "coverage_complete",
+  "source_errors",
+  "not_covered",
+  "note",
+  "answered_at",
+  "provenance",
+  "terms"
+]

First observedOct 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses match semantics (exact match, optional domain), a critical trust caveat ('entity tie (domain alone: unverified)'), the shape of the result (registration type, name candidates, as-of dates), and an explicit scope disclaimer plus 'No advice'. These are behavioral traits annotations cannot convey.

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?

It is compact and front-loaded, leading with the core question and then the mechanism, result shape, and caveats. Some density (register list, result fields, disclaimers packed into two paragraphs) makes it slightly heavy, but no sentence is filler.

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 annotations covering the safety profile and an output schema covering return values, the description supplies exactly the missing pieces: accepted identifiers, exact-match behavior, domain-tie verification caveat, and scope limitations. An agent has everything needed to decide and invoke 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?

Schema description coverage is 100%, so the baseline would be 3. The description adds meaning beyond the schema by clarifying that name/registration/corporate number all feed an exact-match lookup and that domain input is optional and yields only an unverified entity tie — a reliability nuance not present in the schema text.

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 a precise question form that names the verb (lookup/check), the resource (Japan FSA registers and warning lists), and the accepted identifiers (name, registration number, 13-digit corporate number). It enumerates the covered register categories (financial instruments, crypto-asset exchange, electronic payment instruments, funds transfer, money lending), which clearly separates it from siblings like fsa_register_changes or fsa_enforcement_by_corporate_number.

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?

Usage context is clear: this is the tool for checking whether a named business appears on an FSA register or warning list, and it explicitly states the scope limit ('Stated scope only; no warning match is not proof none exists'). However, it never names an alternative tool or states when a sibling (e.g. fsa_enforcement_by_corporate_number) would be preferred over this one, so the routing is left implicit.

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

All Japan Finance Reference Checks tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?