A
licenseA
qualityD
maintenanceEnables access to SORACOM IoT platform data including Harvest sensor data, file storage, SoraCam camera footage/events, and SIM statistics through authenticated API calls.
5
MIT
rms-mcp
The rms-mcp server provides 26 tools for AI agents to manage Rakuten Ichiba operations via the Rakuten RMS API, covering:
Sales & Analysis: Daily sales summaries, product rankings by revenue, and cancellation rates.
Order Management: View order details, list unconfirmed/pending orders, confirm orders, update shipping info, sub-statuses, memos, and cancel orders.
Product Management: Search and list products, create/update products, and change prices.
Inventory Management: Get and update inventory for specific products and variants.
Coupons: Search issued coupons and issue new ones.
Inquiries: View counts, lists, details, and send replies to customer inquiries.
Browser Automation: Post review replies, set RPP ad budgets, check event calendars, and generate R-Mail (newsletter) drafts.
Authentication uses RMS API credentials (service secret and license key), and the server supports both stdio (local) and HTTP (remote) connection modes.
Provides tools for accessing Rakuten RMS data including daily sales summaries, product rankings, order details, and cancel rates.
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., "@rms-mcpshow me today's Rakuten sales summary"
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.
rms-mcp
MCP server for Rakuten RMS API — Sales Dashboard & Order Management
Capabilities
Retrieve Rakuten RMS data from Claude Code (or any MCP client):
Tool | Description |
| Daily sales summary (count, tax, coupons, shipping) |
| Product ranking (quantity, sales, average unit price) |
| Full detail JSON by specifying order number |
| Cancel rate and count |
Related MCP server: Store Sales Data MCP Server
Setup
git clone https://github.com/yasuhidekoizumi-afk/rms-mcp.git
cd rms-mcp
uv syncAuthentication
Issue serviceSecret and licenseKey from the RMS management screen → API settings.
export RMS_SERVICE_SECRET="SP404839_xxxxxxxxxx"
export RMS_LICENSE_KEY="SL404839_xxxxxxxxxx"Verification
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()
"Claude Code Configuration
.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"
}
}
}
}Quick Reference
Daily sales:
Show me today's Rakuten sales→rms_daily_salesProduct ranking:
What are the top 10 Rakuten items this month?→rms_product_ranking(top_n=10)Cancel rate:
What is this month's cancel rate?→rms_cancel_rateOrder details:
Details for this order→rms_order_detail(order_numbers=[...])
API Coverage
[x] RakutenPayOrderAPI (searchOrder, getOrder)
[x] PurchaseItemAPI (searchOrderItem)
[ ] InventoryAPI
[ ] ProductAPI
[ ] CouponAPI
📖 Installation Manual
For detailed installation steps, please refer to SETUP.md.
License
MIT — ORYZAE Inc.
Available Tools
4 toolsrms_cancel_rateC
Cancellation rate and counts
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | YYYY-MM-DD | |
| end_date | No | YYYY-MM-DD |
TDQS
C2.8/5.0
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
rms_daily_salesB
Daily sales summary (orders, revenue, tax, coupons, delivery)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | YYYY-MM-DD | |
| end_date | No | YYYY-MM-DD |
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 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
rms_order_detailC
Full order detail by order number(s)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| order_numbers | Yes |
TDQS
C2.8/5.0
Behavior1/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
rms_product_rankingC
Product sales ranking by revenue (from PackageModelList)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | YYYY-MM-DD | |
| end_date | No | YYYY-MM-DD | |
| top_n | No | Top N |
TDQS
C2.9/5.0
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
rms_cancel_rate - First observed
rms_daily_sales - First observed
rms_order_detail - First observed
rms_product_ranking
TDQS
A3.5/5.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
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.
Query Churn Solution cancellation-flow metrics, revenue, and feedback analytics (read-only).
Sales analytics, ML forecasting, customer segmentation, and trend analysis.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables querying and managing daily store sales data stored in CSV files, including listing available dates, retrieving raw sales data, computing daily and per-item statistics, and saving new daily sales data.MIT
- AlicenseNot gradedqualityBmaintenanceEnables searching and retrieving information from Rakuten services (Ichiba, Books, Travel, Recipe, Kobo, GORA) via the new API endpoints with secure authentication.1MIT
- FlicenseNot gradedqualityCmaintenanceEnables querying sales data, identifying out-of-stock products, viewing top sellers, and receiving restock suggestions through natural language.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yasuhidekoizumi-afk/rms-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server