A Rakuten Ichiba (Japan's largest e-commerce marketplace) MCP server for searching, browsing, and comparing products with enhanced pricing and shipping insights. Requires RAKUTEN_APP_ID and RAKUTEN_ACCESS_KEY for authentication.
Tools:
ichiba_item_search — Search products by keyword with optional filters for price range, genre, and shop. Returns enriched fields:
quantity (parsed from product name, e.g. "24本入り×2ケース" → 48)
unitPrice (price ÷ quantity)
postageLabel (送料無料 / 送料別 / 要確認)
estimatedTotalPrice (itemPrice when free shipping)
shippingVerified (whether shipping cost is confirmed via API)
ichiba_genre_search — Browse the genre/category hierarchy; pass '0' for top-level genres or a specific genre ID to drill into subcategories.
ichiba_tag_search — Look up details for a specific tag ID (facet attributes like size, color), including the tag's group, name, and parent tag.
ichiba_item_ranking — Retrieve bestseller rankings, filterable by genre, time period (realtime/daily/weekly/monthly/yearly), age demographic, and gender. Returns the same enriched pricing/shipping fields as item search.
ichiba_product_search — Cross-seller product search (Item Price Navi) comparing prices for identical products across multiple shops, returning min/max/average prices and number of sellers. Supports filtering by maker/brand code.
Prompt:
compare_ichiba_value — Guides agents through a structured unit-price and shipping-inclusive comparison workflow, including web-searching unconfirmed shipping costs and re-ranking by total cost, ensuring accurate cost-per-unit comparisons.
Provides tools for searching items, genres, tags, rankings, and product comparisons on Rakuten Ichiba, with enhanced fields like quantity, unit price, and shipping cost labels.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rakuten-pantry-mcp find the cheapest bulk pasta with free shipping and best unit price"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mrslbt/rakuten-mcp をベースにした楽天市場（Ichiba）向け MCP サーバーです。
upstream（npm の rakuten-mcp）にはない機能を追加しています。
フィールド / 機能 | 説明 |
| 商品名から総個数を解析（例: |
|
|
|
|
| 送料無料時は |
| 送料が API 上で確定しているか |
| 単価比較＋送料ウェブ確認のガイドプロンプト |
改造の詳細は CHANGES.md。upstream へのパッチは patches/ を参照。
Related MCP server: rakuten-mcp
rakuten-pantry-mcp/
├── src/
│ ├── index.ts # エントリポイント
│ ├── server.ts # MCP サーバー組み立て
│ ├── client.ts # 楽天 API クライアント
│ ├── config.ts / errors.ts / i18n.ts / auth.ts
│ ├── tools/
│ │ ├── ichiba.ts # ★ 改造の本体（5ツール）
│ │ ├── index.ts
│ │ ├── types.ts
│ │ └── meta.ts
│ ├── prompts/
│ │ ├── ichiba.ts # ★ compare_ichiba_value
│ │ ├── schema.ts # ★ プロンプト引数の型変換
│ │ └── index.ts
│ ├── transports/ # stdio / HTTP
│ └── resources/
├── test/ # ichiba / prompts / http のテスト
├── patches/ # upstream 向け差分
├── dist/ # ビルド成果物（npm run build）
├── package.json
├── README.md
├── CHANGES.md
├── AGENTS.md
└── LICENSEIchiba ツール 5個のみ（Books / Travel / Recipe / Kobo / GORA は含みません）。resources/ は現時点では未使用（空のレジストリ）です。
git clone https://github.com/yukin_co/rakuten-pantry-mcp.git
cd rakuten-pantry-mcp
npm install
npm run build環境変数 RAKUTEN_APP_ID と RAKUTEN_ACCESS_KEY が必要です（楽天デベロッパーで取得）。
args には clone 先の dist/index.js への絶対パス を指定します。
{
"mcpServers": {
"rakuten-pantry": {
"command": "node",
"args": ["/path/to/rakuten-pantry-mcp/dist/index.js"],
"env": {
"RAKUTEN_APP_ID": "your-app-id",
"RAKUTEN_ACCESS_KEY": "your-access-key"
}
}
}
}{
"mcpServers": {
"rakuten-pantry": {
"command": "npx",
"args": ["-y", "rakuten-pantry-mcp"],
"env": {
"RAKUTEN_APP_ID": "your-app-id",
"RAKUTEN_ACCESS_KEY": "your-access-key"
}
}
}
}npm の
rakuten-mcp（mrslbt/rakuten-mcp）は別パッケージです。上記のrakuten-pantry-mcpを指定してください。
ツール | 内容 |
| キーワード検索（quantity / unitPrice / 送料フラグ付き） |
| ジャンルツリー |
| タグ参照 |
| 売れ筋ランキング |
| 複数店舗横断の価格比較 |
プロンプト | 内容 |
| 単価比較と送料確認の手順をエージェントに渡す |
npm run typecheck
npm test
npm run buildMIT — 元: mrslbt/rakuten-mcp（MIT）
Browse the Rakuten Ichiba genre (category) hierarchy. Pass '0' to list top-level genres, or a specific genre ID to fetch its ancestors, siblings, and direct children. Useful for narrowing item searches to a specific category, or for discovering what categories exist.
[JA] 楽天市場のジャンル(カテゴリ)階層を参照します。'0' を渡すとトップレベル、特定のジャンルIDを渡すと祖先・兄弟・直下の子ジャンルを取得します。商品検索を特定カテゴリに絞り込んだり、カテゴリ構造を発見するのに使えます。
| Name | Required | Description | Default |
|---|---|---|---|
| genre_id | No | Genre ID to query. '0' returns the top-level genres; pass a child genre ID to drill down. ジャンルID。'0' はトップレベル。子ジャンルIDを渡して掘り下げます。 | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the annotations: fetching ancestors, siblings, and direct children for a given genre ID. The annotations already indicate read-only, idempotent, and open-world, and the description does not contradict them.
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 concise English sentences (plus Japanese translation) with no wasted words. It front-loads the purpose and then explains behavior.
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 is complete for a simple read-only browse tool: it explains what the tool does, when to use it, and the parameter behavior. It does not describe the output format, but given the tool's simplicity and lack of output schema, this is acceptable.
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 single parameter genre_id has 100% schema coverage; the description adds the special behavior for value '0' (top-level) and drilling down, which is not explicitly in the schema description but is implied. This adds 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 browses the genre hierarchy, specifies the verb (Browse), resource (genre hierarchy), and the effect of passing '0' vs a specific genre ID. It is distinct from sibling tools that search or rank items.
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 explicitly says it is useful for narrowing item searches or discovering categories, providing clear context. It does not give explicit when-not-to-use or alternatives, but the sibling tools are sufficiently different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Rakuten Ichiba bestseller ranking — overall or filtered by genre, time period, age, and gender demographic. Returns ranked items with rank, price, review stats, purchase URL, quantity, unitPrice, postageLabel, estimatedTotalPrice, and shippingVerified. Use ichiba_genre_search to find genre IDs. For cheapest / per-unit / shipping-inclusive comparisons (送料込み, コスパ, 安い順, 最安): use the compare_ichiba_value PROMPT instead of this tool alone. If you must use this tool directly: (1) pre-sort by unitPrice ascending; (2) shippingVerified=true → estimatedTotalPrice is final; (3) web-search top 3–5 shippingVerified=false items for JPY shipping; (4) re-rank by itemPrice+shipping; never guess shipping.
[JA] 楽天市場の売れ筋ランキングを取得します。quantity・unitPrice・postageLabel・estimatedTotalPrice・shippingVerifiedを含みます。送料込み・コスパ・安い順・最安の比較は compare_ichiba_value プロンプトを使うこと(このツール単体は不十分)。直接使う場合: (1) unitPrice昇順 (2) shippingVerified=trueは確定 (3) false上位3〜5件をウェブ検索 (4) 再ソート。送料推測禁止。
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Filter to a specific age demographic (e.g., '20s' = users in their 20s). 年代フィルタ。 | |
| sex | No | Filter to a specific gender demographic. 性別フィルタ。 | |
| page | No | Page number (1–34; Rakuten caps rankings at ~1000 items). ページ番号(1〜34)。 | |
| period | No | Time window for the ranking. Default depends on Rakuten's current configuration. ランキングの集計期間。 | |
| genre_id | No | Genre ID for the ranking. '0' returns the overall ranking. 0はジャンル全体のランキング。 | 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds significant context: states the tool returns specific fields (rank, price, review stats, etc.), gives detailed shipping analysis steps (shippingVerified handling, web-search for shipping costs, never guess shipping), and notes Rakuten's ranking cap of ~1000 items. 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?
The description is relatively long but well-structured: main purpose first, then usage guidance, then detailed protocol steps in numbered format. Japanese version follows efficiently. Slightly verbose due to duplication of steps in both languages, but necessary for bilingual audience. Front-loaded key information.
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 complexity (5 optional params, no output schema), the description is highly complete. It covers purpose, filtering options, returned fields, usage protocols, and shipping analysis steps. The absence of an output schema is compensated by listing returned data fields. All essential information for correct agent invocation is present.
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 each parameter already has a description. The tool description adds extra value by explaining usage constraints (page max 34 due to Rakuten cap, genre_id default 0 for overall) and contextual hints (age demographic filtering), going beyond the schema. Deduction for not elaborating on all parameters, but adequate given high schema 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 the tool retrieves Rakuten Ichiba bestseller rankings, supports filtering by genre, period, age, and gender, and lists returned fields. It distinguishes from sibling tools like ichiba_genre_search by mentioning genre ID lookup, and includes both English and Japanese for clarity.
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 tells when to use the tool vs alternatives: directs to ichiba_genre_search for genre IDs, and recommends the compare_ichiba_value prompt for cost comparisons. Provides a numbered step-by-step protocol for direct use, including pre-sorting and shipping handling rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search products on Rakuten Ichiba (Japan's largest e-commerce marketplace) by keyword. Supports price range filtering, sorting by review count/average/price, and restricting results to a specific genre or shop. Returns items with prices, review stats, images, purchase URLs, quantity, unitPrice, postageLabel (from postageFlag), estimatedTotalPrice, and shippingVerified. For cheapest / per-unit / shipping-inclusive comparisons (送料込み, コスパ, 安い順, 最安): use the compare_ichiba_value PROMPT instead of this tool alone. If you must use this tool directly: (1) pre-sort by unitPrice ascending; (2) shippingVerified=true → estimatedTotalPrice is final; (3) web-search top 3–5 shippingVerified=false items for JPY shipping; (4) re-rank by itemPrice+shipping; never guess shipping.
[JA] 楽天市場で商品をキーワード検索します。各商品にquantity・unitPrice・postageLabel・estimatedTotalPrice・shippingVerifiedを付与します。送料込み・コスパ・安い順・最安の比較は compare_ichiba_value プロンプトを使うこと(このツール単体は不十分)。直接使う場合: (1) unitPrice昇順 (2) shippingVerified=trueは確定 (3) false上位3〜5件をウェブ検索 (4) 再ソート。送料推測禁止。
| Name | Required | Description | Default |
|---|---|---|---|
| hits | No | Number of results to return per page (1–30, default 10). 1ページあたりの取得件数(1〜30、デフォルト10)。 | |
| page | No | Page number (1+, default 1). ページ番号(1以上、デフォルト1)。 | |
| sort | No | Sort order. Prefix '+' = ascending, '-' = descending. 並び順。'+' は昇順、'-' は降順。 | standard |
| keyword | Yes | Search keyword. Accepts Japanese or English. 検索キーワード。日本語または英語。 | |
| genre_id | No | Restrict to a specific genre ID. Browse genres via ichiba_genre_search. ジャンルIDで絞り込み。 | |
| max_price | No | Maximum price in JPY (integer, inclusive). 最高価格(円、整数、以下)。 | |
| min_price | No | Minimum price in JPY (integer, inclusive). 最低価格(円、整数、以上)。 | |
| shop_code | No | Restrict to a specific shop. 特定の店舗で絞り込み。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds value by detailing the shipping verification logic and the derived fields (postageLabel, estimatedTotalPrice), but does not mention any behavioral edge cases beyond that.
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 bilingual with full Japanese translation, making it longer than necessary. While front-loaded with purpose, the repetition reduces conciseness. Could be trimmed to essential English.
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?
Despite no output schema, the description fully explains return fields and shipping logic. It covers usage guidelines, alternatives, and parameter summary, making it complete for the tool's complexity.
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 description adds little new meaning to parameters. It summarizes available filters but doesn't provide additional context beyond what the schema already describes.
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 'Search products on Rakuten Ichiba by keyword' with specific verb and resource. Lists supported filters and return fields, distinguishing it from sibling tools like genre_search or ranking.
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 tells when to use an alternative (compare_ichiba_value for value comparisons) and provides step-by-step instructions if used directly, including sorting, shipping verification, and prohibitions on guessing shipping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Rakuten's Item Price Navi — cross-seller product catalogue that groups identical products across multiple shops. Returns each product with its min/max/average price across all sellers and the total number of shops carrying it. Use this (instead of ichiba_item_search) when you want to compare prices for a specific product or answer 'is this a fair price?'. Filter by maker_code to restrict to a brand.
[JA] 楽天市場の商品価格ナビを検索します。同一商品を複数店舗にまたがって集約し、最安値/最高値/平均価格と取扱店舗数を返します。特定商品の価格比較や「妥当な価格か?」を判断する用途では、ichiba_item_search ではなくこちらを使用してください。maker_code でブランド絞り込みも可能。
| Name | Required | Description | Default |
|---|---|---|---|
| hits | No | Number of results per page (1–30, default 10). 1ページあたりの取得件数。 | |
| page | No | Page number (1+, default 1). ページ番号。 | |
| sort | No | Sort order. '+' ascending, '-' descending. 並び順。 | standard |
| keyword | No | Product keyword. Required unless product_id is provided. 商品キーワード。product_id 省略時は必須。 | |
| genre_id | No | Restrict results to a specific genre. ジャンルIDで絞り込み。 | |
| maker_code | No | Restrict results to a specific manufacturer (maker code). メーカーコードで絞り込み。 | |
| product_id | No | Specific product ID (format like '1:12345'). When provided, returns that product. 特定の商品ID。指定時はその商品を返します。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, indicating safe, read-only behavior. The description adds that the tool groups products across shops and returns min/max/average prices and shop count, which is useful 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?
The description is concise with two languages, each sentence is meaningful and front-loaded. It efficiently covers purpose, usage, and an example filter with 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?
The description explains the core function, when to use, and filter options. It does not detail pagination or sort behavior, but these are covered in the schema. No output schema exists, but the description outlines what is returned (min/max/average price, shop count).
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 baseline is 3. The description does not add significant new meaning to parameters beyond what the schema already provides, though it reinforces keyword vs product_id dependency and the purpose of maker_code.
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 searches Rakuten's Item Price Navi, a cross-seller product catalogue grouping identical products. It includes the verb 'search' and distinguishes itself from the sibling 'ichiba_item_search' by specifying it is for price comparison.
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 says to use this tool instead of ichiba_item_search when comparing prices or determining if a price is fair. It also mentions filtering by maker_code. Lacks explicit when-not-to-use statements, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up details for a specific Rakuten Ichiba tag by tag ID. Tags are facet-style attributes (size, color, etc.) attached to items. Returns the tag group this tag belongs to, the tag name, and any parent tag. Tag IDs surface in ichiba_item_search item responses (each item carries an attributeIds array) and in ichiba_genre_search.
[JA] 特定のタグIDの詳細を取得します。タグはファセット属性(サイズ、色など)で商品に紐づいています。タグ名、所属タググループ、親タグを返します。タグIDは ichiba_item_search の各商品 attributeIds や ichiba_genre_search から取得できます。
| Name | Required | Description | Default |
|---|---|---|---|
| tag_id | Yes | Tag ID to fetch details for. Tag IDs are discoverable from ichiba_item_search responses (each item carries tagIds) and from ichiba_genre_search. タグID。ichiba_item_search のレスポンス内 tagIds や ichiba_genre_search から取得できます。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, confirming safe, read-only, idempotent behavior. Description adds return structure but no additional behavioral traits beyond annotations. No contradiction.
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 (plus Japanese translation) with no fluff. Front-loaded with main purpose and immediately actionable. 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?
No output schema, but description covers all necessary details: input source, core action, and return fields (tag group, name, parent). Complete for a simple lookup 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 tag_id already documented. Description adds valuable context about where tag IDs originate (from other search tools), which goes beyond the schema's description.
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 verb 'Look up details' and the resource 'Rakuten Ichiba tag by tag ID'. It explains what a tag is (facet-style attributes) and specifies return fields (tag group, name, parent). Distinct from sibling search/ranking 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?
Description tells where to obtain the required tag IDs (from ichiba_item_search item responses and ichiba_genre_search), providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: genre navigation, ranking, item keyword search, cross-seller product comparison, and tag lookup. The descriptions explicitly differentiate them, e.g., ichiba_product_search is for price comparisons while ichiba_item_search is for general keyword search.
All tools follow the pattern 'ichiba_<domain>_<operation>' (e.g., ichiba_genre_search, ichiba_item_ranking). The only minor deviation is that most use '_search' but 'ichiba_item_ranking' uses '_ranking' instead. Overall, the convention is consistent and predictable.
With 5 tools, the server is well-scoped for browsing and searching the Rakuten Ichiba marketplace. Each tool covers a necessary function, and the count is neither too slim nor too heavy for this domain.
The tool set covers core browsing and search needs (genre, ranking, item search, product comparison, tags). A minor gap is the lack of a tool to retrieve detailed information for a single item by ID, which could be useful. However, the existing tools are sufficient for the main use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for real-time product search by barcode (EAN, UPC, GTIN) or keyword on ean-search.org
MCP server for IT hardware parts research: normalize PNs, search listings, get subs/comps.
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
Google Shopping products, prices, sellers, and deals as structured data via a hosted MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yukincom/rakuten-pantry-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
