Servidor MCP para la API de Rakuten RMS — Panel de ventas y gestión de pedidos
Obtención de datos de Rakuten RMS desde Claude Code (o cualquier cliente MCP):
Herramienta | Descripción |
| Resumen de ventas diarias (cantidad, impuestos, cupones, gastos de envío) |
| Ranking por producto (cantidad, ventas, precio medio) |
| JSON con todos los detalles especificando el número de pedido |
| Tasa y número de cancelaciones |
Related MCP server: Rakuten API MCP Server
git clone https://github.com/yasuhidekoizumi-afk/rms-mcp.git
cd rms-mcp
uv syncEmita serviceSecret y licenseKey desde la pantalla de gestión de RMS → Configuración de API.
export RMS_SERVICE_SECRET="SP404839_xxxxxxxxxx"
export RMS_LICENSE_KEY="SL404839_xxxxxxxxxx"RMS_SERVICE_SECRET="..." RMS_LICENSE_KEY="..." uv run python -c "
from rms_mcp.order_api import OrderAPI
from rms_mcp.client import RMSClient
c = RMSClient('SP...', 'SL...')
api = OrderAPI(c)
r = api.search_orders('2026-05-01T00:00:00+0900','2026-05-08T23:59:59+0900')
print(len(r.get('orderNumberList',[])), '件')
c.close()
".mcp.json:
{
"mcpServers": {
"rms-mcp": {
"command": "uv",
"args": ["run", "rms-mcp"],
"cwd": "/path/to/rms-mcp",
"env": {
"RMS_SERVICE_SECRET": "SP404839_xxx",
"RMS_LICENSE_KEY": "SL404839_xxx"
}
}
}
}Ventas diarias: Muéstrame las ventas de Rakuten de hoy → rms_daily_sales
Ranking de productos: ¿Cuál es el TOP 10 de Rakuten de este mes? → rms_product_ranking(top_n=10)
Tasa de cancelación: ¿Cuál es la tasa de cancelación de este mes? → rms_cancel_rate
Detalles de pedido: Detalles de este pedido → rms_order_detail(order_numbers=[...])
[x] RakutenPayOrderAPI (searchOrder, getOrder)
[x] PurchaseItemAPI (searchOrderItem)
[ ] InventoryAPI
[ ] ProductAPI
[ ] CouponAPI
Consulte SETUP.md para obtener instrucciones detalladas de instalación.
MIT — 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.
