PlugRail JP Recall

Name: PlugRail JP Recall
Author: plugrail

Server Details

Search Japanese product recalls by keyword and category using public Consumer Affairs Agency data.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 29 days
Last Tested: 2026-10-30 11:27
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: plugrail/servers
GitHub Stars: 0
Server Listing: jp-calendar

TDQS

A3.9/5.0

Scored 2026-10-06 15:30 across 2 tools

Disambiguation5/5

get_recall_detail retrieves a single record by management number, while search_recalls queries by keyword and category. Their purposes are clearly distinct with no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent snake_case verb_noun pattern: get_recall_detail and search_recalls. The slight singular/plural difference is natural for the operations and does not break predictability.

Tool Count4/5

Two tools cover the core search and detail operations for a read-only recall lookup service. While slightly below the typical 3–15 range, each tool is well-scoped and earns its place for this narrow domain.

Completeness4/5

Search and detail provide complete coverage for retrieving recall information, including pagination and filtering. A minor gap is the absence of a tool to list available categories or metadata, which could help agents construct searches without guessing category codes.

Available Tools

2 tools

get_recall_detailBInspect

管理番号（11桁）からリコール詳細1件を取得します。入力例: {"management_number": "00000035877"}

Name	Required	Description	Default
`management_number`	Yes	11桁の管理番号。例: "00000035877"

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not state that this is a read-only operation, whether the lookup can fail for a nonexistent/invalid number, or anything about the returned record's shape. The verb 取得 weakly implies a read, but that is the extent of the disclosure.

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

Conciseness5/5

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

Two short sentences, purpose front-loaded, example tucked at the end. Nothing wastes space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter lookup with a fully documented schema this is roughly sufficient, but with no annotations and no output schema the description could reasonably say what the returned detail contains and that the call is non-mutating. Those gaps keep it at minimum-viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter is already documented as an 11-digit management number with an example in the schema. The description repeats the digit count and adds an input example, which is marginal value over the structured field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieves one recall detail keyed by an 11-digit management number. The singular '1件' (one record) implicitly contrasts with the sibling search_recalls, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer it should call this when it already holds a management number and wants the full record. There is no explicit guidance on when to prefer search_recalls instead, nor any note on what happens with an unknown number.

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

search_recallsAInspect

消費者庁リコール情報サイトをキーワード＋カテゴリで検索します。検索語は日本語推奨（英語の代表語は日本語に読み替えます。例: stroller→ベビーカー）。かな/全角/英語を読み替えて検索した場合は summary に「〜として検索しました」と明記します。JAN・型番の照会は keyword にそのまま渡せます。入力例: {"keyword": "サーキュレーター", "category": "0", "limit": 15}掲載日の絞り込み posted_since/posted_until（YYYY-MM-DD・両端含む）を指定すると、上流の新しい順に最大5ページ（75件）まで走査して絞り込みます。total_count・range・nextCursor はいずれも limit 単位の論理位置（絞り込みありは絞り込み後、なしは上流順の続き）を示します。上限で打ち切った場合は summary に「上流の先頭75件までを確認」と明記します。

Name	Required	Description
`limit`	No	取得件数 1〜15（省略時は15）。例: 15
`cursor`	No	前回応答の nextCursor（透過・省略可）。
`keyword`	No	検索キーワード（30文字以内）。例: "サーキュレーター"
`category`	No	カテゴリ 0-13（0=すべて）。例: "0"。1-13 指定時は keyword 空でも可
`posted_since`	No	掲載日の下限（YYYY-MM-DD・両端含む。省略＝下限なし）。例: "2026-09-01"
`posted_until`	No	掲載日の上限（YYYY-MM-DD・両端含む。省略＝上限なし）。例: "2026-09-30"

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 delivers: it discloses transliteration feedback in summary ('〜として検索しました'), the 75-item upstream scan cap and its truncation notice, and the logical position semantics of total_count/range/nextCursor under filtering. This is unusually rich behavioral disclosure for a search tool.

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?

Front-loads the purpose, then usage rules, an example, and pagination semantics. Dense but every clause carries operational information; minor overlap with the schema's date-inclusivity wording.

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?

No output schema and no annotations, so the description must cover behavior — and it explains pagination, truncation, and summary-signaling well. Missing only auth/rate-limit context, which is minor for a public read-only search endpoint.

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 baseline is 3, but the description adds real meaning beyond the schema: keyword accepts JAN/model numbers verbatim, transliteration is applied, and it clarifies what total_count/range/nextCursor represent relative to limit. Adds value on top of documented params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: searches the Consumer Affairs Agency recall site by keyword+category. The sibling get_recall_detail is not named, but the search-vs-detail distinction is unambiguous. Strong but lacks explicit sibling routing.

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?

Gives clear context: Japanese keywords recommended, english terms auto-transliterated, JAN/model numbers can be passed directly to keyword, and a concrete input example. It also bounds date filtering to 75 items / 5 upstream pages. No explicit when-not or sibling alternative, so not a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesOct 6, 2026
- Changedget_recall_detail2 fields changed
  - addedInput schema / properties / management_number / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  }
+]
```
  - removedInput schema / properties / management_number / type
```
Removed value: -"string"
```
- Changedsearch_recalls12 fields changed
  - addedInput schema / properties / category / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  }
+]
```
  - removedInput schema / properties / category / type
```
Removed value: -"string"
```
  - addedInput schema / properties / cursor / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  }
+]
```
  - removedInput schema / properties / cursor / type
```
Removed value: -"string"
```
  - addedInput schema / properties / keyword / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  }
+]
```
  - removedInput schema / properties / keyword / type
```
Removed value: -"string"
```
  - addedInput schema / properties / limit / anyOf
```
Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "string"
+  }
+]
```
  - removedInput schema / properties / limit / type
```
Removed value: -"number"
```
  - addedInput schema / properties / posted_since / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  }
+]
```
  - removedInput schema / properties / posted_since / type
```
Removed value: -"string"
```
  - addedInput schema / properties / posted_until / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  }
+]
```
  - removedInput schema / properties / posted_until / type
```
Removed value: -"string"
```

1 tool updateOct 3, 2026

Changedsearch_recalls2 fields changed

addedInput schema / properties / posted_since

Added value: +{
+  "description": "掲載日の下限（YYYY-MM-DD・両端含む。省略＝下限なし）。例: \"2026-09-01\"",
+  "type": "string"
+}

addedInput schema / properties / posted_until

Added value: +{
+  "description": "掲載日の上限（YYYY-MM-DD・両端含む。省略＝上限なし）。例: \"2026-09-30\"",
+  "type": "string"
+}

2 tool updatesOct 2, 2026
- First observedget_recall_detail
- First observedsearch_recalls

Related MCP Connectors

China Product Recall & Safety Search A
io.github.huangjunsong404-crypto
Search recall records by company name or product keywords.
Government Data Search
1
https://mcp.agentdatacore.com/mcp/products/recall
DeepRecall - Product Safety Intelligence A
io.github.adrida
Search 120,000+ recalled products from 8 global safety agencies using AI similarity.
Search Open Data Government Data
22
https://mcp.deeprecall.io/mcp
mcp A
us.recalert
Search U.S. product recalls (CPSC, FDA, NHTSA, FSIS) by product, brand, model, or UPC code.
Government Data Search
61
https://ajlswjtsikbnpicienyu.supabase.co/functions/v1/mcp
Recall Check A
app.openkrill
Check US recalls for a car, a baby product, a food or a medicine in the official recall databases.
Government Data Health & Wellness
71
https://recalls.openkrill.app/mcp

Related MCP Servers

mcp-cpsc
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Access US consumer-product safety recalls from the CPSC, free and without authentication.
Updated a day ago (2026-10-29 02:24 UTC)
249 npm
MIT
deeprecall-mcpofficial
Government Data Open Data E-commerce & Retail
DeepRecall-io
A
license
Not graded
quality
D
maintenance
Search 120,000+ recalled products from CPSC, FDA, EU Safety Gate, and other global agencies via MCP. Enables AI agents to check product safety by text or image.
Updated 9 months ago (2026-01-27 20:03 UTC)
Apache 2.0
china-recalls
Government Data Search Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables searching and retrieving Chinese product recall announcements from the State Administration for Market Regulation, with title, category and date filters plus full notice text including recalling company, units affected, defect and remedy details. Answers questions about whether a company or product has been recalled in China and when.
Updated a day ago (2026-10-29 02:05 UTC)
183 npm
MIT
recall-check-mcp
Government Data Search Open Data
arhancanli
A
license
A
quality
B
maintenance
Searches US product recalls across CPSC, FDA, and NHTSA in one call, matching by name, brand, model number, UPC, or VIN with confidence scoring.
Updated 13 days ago (2026-10-17 18:34 UTC)
3
1
MIT