Skip to main content
Glama

PlugRail JP Corporate

lookup_corporate

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

Input Schema

TableJSON 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

A4.2/5.0
Behavior5/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 so well: it discloses that name-only matches are returned as multiple candidates with evidence-based scores rather than a single assertion, that nationwide search sets searchedNationwide:true and carries prefecture codes, and that address-only search cannot fall back to nationwide. These are behavioral traits an agent could not infer from the schema alone.

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

Conciseness4/5

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

Dense and front-loaded, leading with the two-mode split before the conditional rules. The concrete call examples are genuinely useful, though the block is long and the rules could be tightened slightly without losing meaning.

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 tool with no output schema and no annotations, the description covers the essential call-shaping logic (mode selection, prefecture inference, nationwide behavior) and return semantics well. Pagination via cursor and the limit default are left to the schema, which is a minor remaining gap.

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 coverage is 100%, so the baseline is 3, but the description adds genuine semantics beyond the schema: prefecture accepting both '13' and '東京都', inference of prefecture from an address prefix, and the required/optional conditions tied to which other parameter is present. The schema already lists the accepted prefecture formats, so the added value is real but partial.

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 clearly states two distinct operations: confirmed lookup by corporate number and candidate search by name/location, and it explains that results are returned separately. That is a specific verb+resource with sub-mode detail. It loses a point because it never names or distinguishes itself from the sibling tools (search_corporate_by_name, search_corporate_by_address, search_corporate_by_number), which an agent may see as competing options.

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?

Strong in-tool guidance: prefecture is optional when name is given, required when only address is given, and omittable when the address starts with a prefecture name. It also states the nationwide fallback behavior. It stops short of explicit when-to-use-this-vs-sibling routing, so it is not a full 5.

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.