楽天RMSのMCPサーバー — 自然言語で楽天市場運用を操作するAIエージェント向けツール群
26ツール | 読取12 + 書込10 + ブラウザ操作4
ツール | 説明 |
| 日別売上サマリー（件数・税・クーポン・送料） |
| 商品別ランキング（数量・売上・平均単価） |
| キャンセル率・件数 |
ツール | 説明 |
| 注文番号指定で全詳細JSON |
| 未確認（注文確認待ち）の注文一覧 |
| 発送待ち注文一覧 |
| サブステータス一覧 |
| 受注確認（確認待ち→処理中） |
| 配送情報更新（配送業者・追跡番号） |
| サブステータス更新 |
| 注文メモ更新 |
| 注文キャンセル |
ツール | 説明 |
| 商品検索（管理番号・商品名・ジャンル） |
| 全商品の管理番号・商品名・価格の一覧 |
| 商品の新規登録・更新 |
| 商品価格の変更 |
ツール | 説明 |
| 指定商品の在庫情報を取得 |
| 在庫数の更新（バリアント単位） |
ツール | 説明 |
| 発行済みクーポンの一覧 |
| 新規クーポンの発行 |
ツール | 説明 |
| 問い合わせ管理（件数・一覧・詳細・返信） |
ツール | 説明 |
| レビューに返信を投稿 |
| RPP広告の月予算を設定 |
| イベントカレンダー確認 |
| R-Mail（メルマガ）文面自動生成 |
Related MCP server: Rakuten API MCP Server
git clone https://github.com/yasuhidekoizumi-afk/rms-mcp.git
cd rms-mcp
uv syncRMS管理画面 → API設定 で serviceSecret と licenseKey を発行。
export RMS_SERVICE_SECRET="SP404839_xxxxxxxxxx"
export RMS_LICENSE_KEY="SL404839_xxxxxxxxxx".mcp.json または claude_desktop_config.json:
{
"mcpServers": {
"rms-mcp": {
"command": "uv",
"args": ["run", "--directory", "/path/to/rms-mcp", "rms-mcp"],
"env": {
"RMS_SERVICE_SECRET": "SP404839_xxx",
"RMS_LICENSE_KEY": "SL404839_xxx"
}
}
}
}{
"mcpServers": {
"rms-mcp": {
"url": "https://rms-mcp-production.up.railway.app/mcp",
"headers": {
"Authorization": "Bearer oryzae-rmcp-2026"
}
}
}
}RMS_SERVICE_SECRET="SP404839_xxx" RMS_LICENSE_KEY="SL404839_xxx" uv run python -c "
from rms_mcp.order_api import OrderAPI
from rms_mcp.client import RMSClient
c = RMSClient('SP404839_xxx', 'SL404839_xxx')
api = OrderAPI(c)
nums = api.search_orders('2026-05-01T00:00:00+0900','2026-05-08T23:59:59+0900').get('orderNumberList', [])
orders = api.get_order(nums).get('OrderModelList', [])
total = sum(o.get('totalPrice', 0) or 0 for o in orders)
print(f'接続成功！ {len(nums)}件 {total:,}円')
c.close()
"uv sync --extra dev
uv run pytest
RMS_SERVICE_SECRET=SP_xxx RMS_LICENSE_KEY=SL_xxx uv run pytest tests/test_live_smoke.pyMIT — ORYZAE Inc.
Cancellation rate and counts
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | YYYY-MM-DD | |
| end_date | No | YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as read-only nature, data aggregation behavior, or any side effects. The tool's purpose implies read-only, but this is not explicitly stated.
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 extremely concise but is a noun phrase rather than a complete sentence. It could be improved with a verb for clarity without adding significant length.
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 tool has no output schema, and the description does not explain the return format (e.g., daily totals, overall rate). Missing details on what 'rate' means (percentage, fraction) and whether counts are segmented.
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% but only provides format (YYYY-MM-DD). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 it provides cancellation rate and counts, which is distinct from sibling tools like rms_daily_sales. However, it lacks a verb and could be more specific about the output format.
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?
No guidance on when to use this tool versus siblings or alternatives. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily sales summary (orders, revenue, tax, coupons, delivery)
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | YYYY-MM-DD | |
| end_date | No | YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions the data fields but does not disclose whether the summary is per day or over the range, any read-only nature, or other side effects.
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 a single, efficient line listing the included metrics. No unnecessary words, but could potentially add structured detail without becoming verbose.
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 no output schema, the description should cover return structure. It only lists components but does not specify aggregation level, format, or pagination, leaving significant gaps for a summary 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 parameter descriptions for start_date and end_date. The description adds no extra semantics beyond the schema, meeting the baseline for a 2-param tool.
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 provides a 'daily sales summary' and enumerates specific components (orders, revenue, tax, coupons, delivery). This differentiates it from siblings like rms_cancel_rate or rms_order_detail.
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 implies use for aggregated daily sales metrics but lacks explicit when-to-use or when-not instructions. No alternatives are mentioned, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full order detail by order number(s)
| Name | Required | Description | Default |
|---|---|---|---|
| order_numbers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read-only nature, response format, or any side effects. The description is too minimal to convey what the tool actually does beyond its basic purpose.
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 extremely concise, consisting of a single phrase. While it lacks necessary detail, it is not verbose and front-loads the primary action. However, the brevity comes at the cost of completeness.
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 absence of an output schema and annotations, the description should provide more context about return values or usage. 'Full order detail' is vague, and the tool's overall functionality is not sufficiently explained for an agent to use it effectively.
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?
With 0% schema description coverage, the description should compensate by explaining the parameter semantics. However, it only restates 'by order number(s)' without adding constraints like format, limits, or examples, adding minimal value over 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 that the tool retrieves full order details using order numbers, which is a specific verb-resource combination. It distinguishes from sibling tools like rms_cancel_rate and rms_daily_sales by its focus on order details.
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 provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites or scenarios, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Product sales ranking by revenue (from PackageModelList)
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | YYYY-MM-DD | |
| end_date | No | YYYY-MM-DD | |
| top_n | No | Top N |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only mentions data source ('PackageModelList') but does not specify if the operation is read-only, whether it aggregates data, or any performance implications.
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 a single sentence, very concise, and front-loaded with the main purpose. However, it could be slightly expanded with key context without losing conciseness.
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?
For a simple ranking tool, the description omits essential context: what the output looks like, whether results are ordered, and how to interpret the ranking. It lacks guidance on usage and behavioral transparency, making it incomplete.
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 input schema has 100% description coverage, so baseline is 3. The description adds context that the ranking is 'by revenue' from a specific list, but does not provide additional semantics for individual parameters (e.g., date range behavior, default for top_n).
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 ranks products by revenue from PackageModelList, which distinguishes it from sibling tools like cancellation rates or daily sales. However, it assumes knowledge of 'PackageModelList' without explanation.
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?
No guidance is provided on when to use this tool versus siblings. There is no mention of prerequisites, exclusions, or scenarios where alternative tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0rms_cancel_raterms_daily_salesrms_order_detailrms_product_rankingScored across 4 tools
Each tool targets a distinct aspect of RMS data: cancellation rates, daily sales, order details, and product rankings. There is no overlap in functionality, making it easy for an agent to select the correct tool.
All tools follow a consistent pattern: 'rms_' prefix followed by a descriptive noun phrase using underscores (cancel_rate, daily_sales, order_detail, product_ranking). This predictability aids both human and agent understanding.
With 4 tools, this server is well-scoped for a focused analytics/reporting domain. Each tool serves a clear purpose without unnecessary bloat, and the count fits comfortably within the optimal range of 3-15 tools.
The tool set covers key reporting and analytics needs for an RMS: cancellation, sales summary, order details, and product ranking. Minor gaps exist, such as the absence of time-range filtering or trend comparisons, but the core query functionality is present.
Products, customers, orders, subscriptions, benefits, revenue metrics and refunds.
Read-only Amazon seller analytics: sales, Buy Box, FBA inventory, alerts, revenue and fees.
Read your Cakto sales: orders, revenue analytics, subscriptions, churn, customers and products.
Read-only zobrx e-commerce data: P&L, orders, inventory, marketplace, tax & shelf insights.
