Skip to main content
Glama
Sign In

PlugRail JP Corporate

by dev.plugrail
OverviewDiscussionsAdmin

lookup_corporate

法人番号の確定照会と名称・所在地の候補探索を分離して返す。名称だけでは断定せず複数候補と根拠別scoreを返す。候補探索は name 指定時は prefecture 任意（省略時は全国前方一致で searchedNationwide:true・候補に県コード付き・県か住所を足すと絞り込める）。prefecture は '13' または '東京都' のどちらでも可。address が「東京都渋谷区…」のように都道府県名で始まれば prefecture は省略可（推定）。address のみの検索は prefecture または推定が必須（全国非対応）。番号確定例: {"corporateNumber": "1180301018771"}／候補例: {"name": "渋谷", "prefecture": "13", "limit": 10}／全国例: {"name": "山田工業"}corporateNumber はハイフンなし13桁の文字列（数値・ハイフン付き・先頭 T 付きは不可）。番号と name は併用不可。

Input Schema

NameRequiredDescriptionDefault
nameNo法人名の検索語（候補探索）。例: "渋谷"
limitNo取得件数 1〜20（省略時は10）
cursorNo前回応答の nextCursor（透過・省略可）。
addressNo所在地の絞込語（候補探索の任意）。例: "渋谷"
prefectureNo都道府県（name 指定時は任意・省略時は全国検索。address のみのときは必須。address 先頭の都道府県名から推定できれば省略可）。JISコード "13"・13・"1" または都道府県名 "東京都"・"東京" のどちらでも可
corporateNumberNo13桁の法人番号（確定照会）。例: "1180301018771"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / corporateNumber / description
      Previous value: -"13桁の法人番号（確定照会）。例: \"8000000000001\""New value: +"13桁の法人番号（確定照会）。例: \"1180301018771\""
  2. Changed1 schema field changed
    • changedInput schema / properties / prefecture / description
      Previous value: -"都道府県（候補探索で必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"New value: +"都道府県（name 指定時は任意・省略時は全国検索。address のみのときは必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"
  3. Changed4 schema fields changed
    • addedInput schema / properties / prefecture / anyOf
      Added value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  }
+]
    • changedInput schema / properties / prefecture / description
      Previous value: -"都道府県コード2桁（候補探索は必須）。例: \"13\"（東京）"New value: +"都道府県（候補探索で必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"
    • removedInput schema / properties / prefecture / pattern
      Removed value: -"^\\d{2}$"
    • removedInput schema / properties / prefecture / type
      Removed value: -"string"
  4. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose key behavior: results are separated into definitive vs candidate, candidates carry per-basis scores, and nationwide searches set searchedNationwide:true. It does not cover permissions, rate limits, or the full response shape, but the important semantic traits are exposed.

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?

The separation between definitive lookup and exploration is front-loaded, and the three worked examples are efficient and useful. It is dense but nearly every clause carries distinct operational information, with little waste.

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 6-parameter, dual-mode tool with no output schema, the description covers the critical invocation conditions and hints at return fields (scores, searchedNationwide). A fuller description of the returned candidate structure would be needed for a 5.

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 coverage is already 100%, so the schema documents parameters fully; the description largely repeats prefecture/address inference rules that the schema also states. The one genuinely extra rule is that corporateNumber and name cannot be combined, so it adds only marginal value over the schema.

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 states the specific resource (corporate number/name/location) and distinguishes two operating modes: definitive lookup by corporateNumber and candidate exploration by name/address. However, it never names or routes against the siblings search_corporate_by_number, search_corporate_by_name, or search_corporate_by_address, which clearly overlap with this tool's modes.

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?

It gives explicit conditional usage: when name is given prefecture is optional, address-only search requires a prefecture or inference, and name+corporateNumber cannot be combined. What is missing is any statement of when to prefer this tool over the sibling search_corporate_by_* tools.

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

All PlugRail JP Corporate toolsInspect
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