rakuten-rms-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Several tools have overlapping purposes, such as multiple inventory retrieval methods (rms_get_inventory, rms_get_variant_inventory, rms_bulk_get_inventory, rms_get_variant_lists) and product update methods (rms_update_price, rms_patch_product, rms_upsert_product). The rms_inquiries tool bundles count/list/detail/reply/read/complete operations into one, creating significant ambiguity for agents. While descriptions are clear, the sheer number of similar tools makes selection error-prone.
Naming Consistency2/5Naming conventions are mixed: most tools follow a verb_noun pattern (e.g., rms_get_product, rms_update_orderer), but some place the verb at the end (rms_thanks_coupon_get, rms_inquiry_attachment_post). Noun-only names like rms_health and rms_inquiries, and adjective-noun names like rms_daily_sales, further break consistency. The irregular placement of actions across similar functions makes tool names unpredictable.
Tool Count1/5With 58 tools, the server's tool count is excessively high, far beyond the typical range for an MCP server and making agent tool selection unwieldy. The broad domain coverage does not justify this count, as many tools could be consolidated (e.g., the inquiry operations could be split into separate tools or grouped). This is an extreme mismatch with recommended server scoping.
Completeness4/5The server provides comprehensive coverage of core lifecycles for orders, products, inventory, coupons, and inquiries, including create, read, update, delete, and search operations. Notable features like payment info retrieval, shipping updates (sync and async), and analytics tools are present. Minor gaps exist (e.g., no explicit return/refund management), but overall the surface is well-rounded and functional.
Average 2.5/5 across 58 of 58 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as safety, idempotency, rate limits, or return format. The description carries the full burden but offers none, leaving the agent blind to operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is not conciseness but under-specification. It adds no value beyond the title, so it fails to earn its place, though it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk operation with a nested input array and no output schema, the description is severely incomplete. It does not mention filtering, response shape, error conditions, or any operational context, making it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain what the 'inventories' parameter means, how to structure the array items, or how manageNumber and variantId are used. The nested object structure requires semantic explanation that is entirely absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '在庫一括取得' is a direct Japanese translation of the tool name 'Bulk get inventory' and title, adding no new information. It is a tautology that restates the name without specifying a unique verb or resource beyond what is already obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like rms_get_inventory, rms_bulk_get_inventory_range, or rms_get_variant_inventory. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is just a verb phrase. It does not disclose whether this is a read-only operation, whether specific permissions are needed, what the response contains, or any side effects. The description carries the full burden for behavioral transparency and completely fails to address it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than concise clarity. It is a single noun phrase with no structure or sentence, and it provides no usable information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter descriptions, the description is completely inadequate for a tool with two required parameters. The agent cannot determine how to invoke the tool correctly, what the expected inputs are, or what result to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required string parameters (variant_id and manage_number) with no descriptions, and the description provides no additional meaning. Schema description coverage is 0%, so the agent has no hint about the expected format, semantics, or relationship between these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'バリアント在庫取得' is just a Japanese translation of the title 'Get variant inventory' and adds no new information. It restates the name/title without explaining what specifically it does or how it differs from sibling tools like rms_get_inventory or rms_bulk_get_inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as rms_get_inventory or rms_bulk_get_inventory. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent without contextual rationale for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'get' without explaining return format (binary file, URL, etc.), whether authentication is required, or what error cases may occur. This is a significant gap for a file retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than appropriate conciseness. A single phrase that repeats the title does not earn its place because it adds no meaningful information. It lacks structure and any front-loaded key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter documentation, the description is entirely inadequate. The tool likely downloads a file, but the agent has no idea how the response is delivered or how 'path' and 'label' are used. The minimal text leaves the tool's behavior almost completely unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention either parameter ('path' or 'label'). The agent receives no information about what values are expected or how they affect the request, so the description fails to compensate for the schema's silence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '問い合わせ添付ファイル取得' is a Japanese translation of the title 'Get inquiry attachment' and essentially restates it. It mentions a verb and resource but adds no specific context, such as how it differs from the sibling rms_inquiry_attachment_post. This is tautological rather than clarifying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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, when not to use it, or what alternatives exist. It fails to mention any prerequisite like an inquiry ID or attachment path, and there is no contrast with the POST counterpart or related inquiry tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only provides a name. It does not mention whether the operation is read-only, how results are return, pagination behavior, or any side effects. This is a complete transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks the substantive content that would justify its brevity, offering no usable information beyond a label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is grossly incomplete. It fails to explain what the tool returns, how inputs interrelate, or any behavioral expectations, making it nearly useless for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. The five parameters (limit, end_date, date_type, start_date, progress_list) are entirely unexplained, leaving the agent without any semantic understanding of how to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '購入商品API: searchOrderItem' is essentially a translated label of the tool name, providing only a generic verb ('search') and resource ('order items') without specifying what the search does, its scope, or how it differs from sibling tools like rms_search_orders or rms_get_order_items. It is barely more than a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 alternatives. With siblings rms_search_orders and rms_get_order_items, there is no differentiation or context to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose safety, permissions, return format, etc. It provides none. The phrase (items.bulk.get) does not explain behavior beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified and adds no value beyond the name. It is not meaningfully concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description should explain the operation fully. It only restates the tool's purpose, missing parameter semantics, return value, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter manage_numbers is an array of strings with no description in schema (0% coverage). The tool description does not explain what these numbers are or how they are used, so the agent has no additional semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially the title translated to Japanese ('商品一括取得' = bulk acquisition of products) with an internal API endpoint reference. It does not differentiate from sibling tools like rms_get_product or rms_search_products, and does not clarify what 'bulk' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling list contains search_products, get_product, and other product-related tools, but no context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action name, omitting side effects, prerequisites, reversibility, or whether the operation is destructive beyond the implied cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it adds no value beyond the title. This is under-specification rather than effective conciseness, as the sentence fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description is inadequate. It does not explain valid order states, effects on shipping, or expected outcomes, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter order_number is undocumented in both the schema and the description. The description provides no meaning, format, or constraints, leaving the agent without necessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is a Japanese translation of the name/title, restating 'cancel order after shipping' without adding any new information. It does not differentiate from siblings such as rms_cancel_order or clarify what 'after shipping' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool vs. alternatives like rms_cancel_order for pre-shipping cancellations, or any other context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 of behavioral disclosure. It only states 'get payment information' with no mention of side effects, read-only nature, error conditions, or return format, leaving the agent with zero behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short phrase, but it is under-specified rather than concise. Every word repeats what the title already conveys, and no information is added that would help an agent; it does not 'earn its place'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one required parameter and no output schema, the description should at least clarify what the tool returns and how the parameter is used. It provides neither, making the tool effectively unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter order_number has a 0% schema description coverage, and the tool description provides no explanation of its meaning, format, or usage. The description fails to compensate for the missing parameter documentation, making it impossible to use correctly without additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '決済情報取得（getPayment）' is a direct Japanese translation of the tool name, restating the title without adding specificity. It does not distinguish the tool from sibling tools like rms_order_detail, which could also return payment-related data, and fails to clarify what 'payment' entails (e.g., status, method, amount).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as rms_search_orders or rms_order_detail. There are no prerequisites, exclusions, or contextual hints about the appropriate scenarios for invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it merely states the action 'stop' without disclosing side effects, reversibility, permissions, or behavior for invalid IDs. Agents cannot predict what 'stopping' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short Japanese phrase, but it under-specifies the tool's purpose and behavior. This is not conciseness but omission, leaving the agent without necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description fails to cover prerequisites, effects, or usage context. The tool is simple but still requires basic behavioral explanation, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (thanks_coupon_id, string) with 0% description coverage. The description does not mention or explain this parameter, relying entirely on its self-explanatory name and providing no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'サンキュークーポン停止' directly translates to 'Thanks coupon stop', restating the tool title without adding specificity or scope. It does not distinguish the 'stop' action from sibling operations like rms_delete_coupon or rms_thanks_coupon_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context or guidance is provided. The description does not indicate when to use this tool instead of alternatives such as rms_delete_coupon, rms_thanks_coupon_update, or rms_cancel_coupon-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 of behavioral disclosure. It only states the action 'update', without mentioning side effects, permissions, whether it is a partial or full update, or any response behavior. For a mutation tool with an unstructured body parameter, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified rather than concise. It does not earn its place because it simply restates the title and provides no actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested body object, no output schema, no annotations), the description is completely inadequate. It fails to explain how to construct the body, what the thanks_coupon_id refers to, or what the tool returns, making it impossible for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention either of the required parameters (thanks_coupon_id and body). The body is an arbitrary object, so its semantics are entirely unexplained. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'サンキュークーポン更新' is a direct Japanese translation of the title 'Update thanks coupon', providing no new information. It is a tautology that restates the title without adding detail or distinguishing from sibling tools like rms_update_coupon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must itself disclose behavioral traits like destructiveness, permissions, or side effects. The description only repeats the action 'delete' in another language and provides zero transparency about what this operation actually does to the data, making it dangerously incomplete for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise but also severely under-specified. Brevity only serves the user if all necessary information is packed in; here it simply restates the tool name, so the brevity is a deficiency rather than a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a deletion tool with two required parameters, no annotations, and no output schema, so the description must provide enough context for the agent to operate. However, it offers nothing beyond a literal translation of the title, omitting essential details about required identifiers, consequences, or conditions for use. The tool is simple, but the description is still far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists 'variant_id' and 'manage_number' as required strings but provides no descriptions for them. The description does not clarify what these parameters represent, how they relate to each other, or any format expectations. With 0% schema description coverage and no compensation in the description, the agent cannot confidently construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'バリアント在庫削除' translates to 'variant inventory deletion,' which directly restates the tool name and title without adding operational detail. It does not distinguish this delete operation from related tools like rms_get_variant_inventory or rms_upsert_variant_inventory, so it fails to clarify what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to invoke this tool, what preconditions must be met, or how it differs from sibling tools such as rms_update_inventory or rms_upsert_variant_inventory. There is no mention of appropriate contexts, exclusions, or alternatives, leaving the agent without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action of deletion without mentioning irreversibility, potential cascading effects, permission requirements, or error behavior for nonexistent coupons. For a destructive operation, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than appropriately concise. It adds no value beyond the title and does not earn its place with informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity (single parameter, no output schema), this is a deletion tool with significant safety implications. The description completely lacks warnings, side-effect information, or confirmation steps, making it insufficient for an agent to invoke safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not mention the 'coupon_code' parameter at all. It fails to explain what format the code should take, whether it is an exact match, or whether related codes are affected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'クーポン削除' clearly translates to 'Delete coupon', specifying the action and resource. However, it is essentially a direct restatement of the tool's name and title, offering no additional nuance or scope. It is not vague, but it does not meaningfully distinguish from siblings beyond the inherent verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as rms_get_coupon, rms_update_coupon, or rms_patch_coupon. It lacks prerequisites, context for coupling with other coupon operations, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of disclosing behavioral traits. The description only repeats the tool's name and provides no information about whether the operation is read-only, what the query does, pagination behavior, or return format. This is a complete failure of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise but severely under-specified. This is not effective conciseness; it omits essential information that should be present to make the tool usable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's one flexible object parameter, no output schema, no annotations, and ambiguous relationship to sibling tools, the description is entirely inadequate. It does not enable an agent to understand the tool's purpose, usage, or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes a 'query' object with arbitrary keys, but the description provides zero explanation of what keys are valid, what the query means, or how it filters results. With 0% schema description coverage, the description must compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'サンキュークーポン検索' translates to 'Thanks coupon search', which does state a specific verb (search) and resource (thanks coupons). However, it adds no new information beyond the title and does not clarify what distinguishes 'thanks coupons' from regular coupons, nor does it differentiate from sibling tools like rms_search_coupons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool instead of rms_search_coupons, rms_thanks_coupon_get, or other related coupon tools. There is no context about the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'update' without explaining upsert behavior (insert or update), the effect of the 'mode' parameter (ABSOLUTE vs RELATIVE), how quantity changes are applied, or any side effects. This is a serious gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one short phrase), but it under-specifies. It is not front-loaded with useful information; it is closer to a tautological label than a functional description. The brevity does not earn its place because it omits critical operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with an enum, no output schema, and no annotations, the description is wholly insufficient. It doesn't explain the upsert semantics, parameter interactions, or expected results, making it impossible for an agent to invoke it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameter. It fails to clarify the meaning of 'manage_number', 'variant_id', 'quantity', or 'mode'. The schema provides only types and constraints, leaving the agent without understanding semantics like the difference between ABSOLUTE and RELATIVE modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Variant inventory update (single)' states a specific verb and resource, but it is vague and does not capture the full 'upsert' semantics implied by the tool name and title. It does not distinguish this tool from sibling tools like rms_update_inventory or rms_get_variant_inventory beyond mentioning 'variant' and 'single'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as rms_update_inventory, rms_bulk_get_inventory, or rms_delete_variant_inventory. There is no mention of contexts, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 of behavioral disclosure. It does not mention whether this is a read-only operation, what data it returns, or any side effects. The description is just a noun phrase with no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than appropriately concise. It lacks any informative content that would help an agent decide when to invoke the tool, making the brevity a liability rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (two optional date parameters) and the lack of annotations or output schema, the description should at least clarify what 'cancel rate' refers to and what the tool returns. It does neither, leaving the tool's context essentially undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of both parameters (start_date and end_date) with clear defaults and formats. The description adds no extra meaning beyond what the schema already documents, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'キャンセル率・件数' is essentially a restatement of the title 'Cancel rate'. It lacks a verb and does not clearly state what the tool does (e.g., retrieves, calculates, or lists). It does not distinguish this tool from any sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or which alternatives might be more appropriate. The description provides no context about typical use cases, prerequisites, or whether it complements other RMS tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states 'update' without mentioning what is modified, whether it replaces or patches settings, any permission requirements, side effects, or return values. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it merely restates the title in Japanese ('Update inventory-related settings' vs. 'Update inventory-related settings'). It earns no place because it adds no additional information; this is under-specification rather than concise effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex nested 'settings' object, no output schema, and no annotations, the description is grossly incomplete. It does not explain what settings can be updated, how manage_number identifies the item, or what the response looks like. A adequate description would at least list common settings or reference the corresponding getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'settings' object structure or the meaning of 'manage_number'. The schema shows 'settings' as a generic object with additionalProperties, but the description gives no clue about valid keys or values. This leaves the agent completely in the dark about how to construct a correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '商品の在庫関連設定更新' (Update inventory-related settings) identifies a clear verb and resource, but 'inventory-related settings' is vague and does not distinguish from sibling tools like rms_update_inventory (which updates inventory quantities) or rms_get_inventory_related_settings (which reads settings). Without listing specific settings or scope, it fails to differentiate adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no exclusions. It does not mention that it complements rms_get_inventory_related_settings or that it differs from rms_update_inventory. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 states 'partial update' and 'XML IF,' but does not explain side effects, whether unspecified fields remain unchanged, required permissions, or any rate limits. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks necessary details about the tool's behavior and parameters, so the phrase does not earn its place as a useful specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one nested object parameter, no output schema, no annotations), the description is severely incomplete. It neither explains the meaning of 'XML IF' nor provides enough context for an agent to correctly invoke the tool with appropriate field mappings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the only parameter 'fields' is an arbitrary object with no property details. The description does not enumerate valid coupon fields, value formats, or provide examples, so it fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'クーポン部分更新' (coupon partial update) clearly identifies the action as a partial update on the coupon resource, which distinguishes it from the full update tool rms_update_coupon. However, it largely restates the title and does not specify which fields can be updated or explain the 'XML IF' suffix, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like rms_update_coupon or rms_get_coupon. There is no mention of context, prerequisites, or exclusions, so the agent receives no decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits beyond the word 'simulation'. It does not state whether the operation is read-only, what it returns, whether it has side effects, or how errors are handled. The description fails to carry the burden for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short phrase, which is extremely concise but under-specified. It lacks a full sentence or any structural elements that explain the tool's purpose or usage, so it is not 'appropriately sized' for a complex tool with a nested object parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has complex input (nested object), no output schema, and no annotations. The description provides no information about expected response format, example inputs, or edge cases. This is highly incomplete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with a vague description ('公式 IF のリクエストボディ' meaning 'official IF request body'). Since schema coverage is 100%, the baseline is 3, but the description adds no additional meaning about what fields the coupon_model object should contain or how to construct it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'クーポン利用額シミュレーション' translates to 'Coupon usage amount simulation', which conveys the general action but is a noun phrase rather than a clear verb-led statement. It does not specify what the simulation produces or how it differs from coupon CRUD tools like rms_get_coupon, though the tool name adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as rms_issue_coupon or rms_get_coupon. There is no mention of prerequisites, context, or exclusions, so an agent has no basis for determining appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely restates 'Thanks coupon issuance' without revealing any side effects, permissions required, data mutation implications, or return behavior. This is completely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase and technically concise, but it is severely under-specified. It adds no information beyond the title and fails to earn its place, making it closer to under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a free-form body object and no output schema, the description is vastly incomplete. It provides no context about required fields, expected request format, response contents, or error conditions, making the tool unusable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('body') with 0% description coverage, and the description does not explain what the body should contain or how it relates to issuing a thanks coupon. Since the body is an open free-form object, the description must compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'サンキュークーポン発行' (Thanks coupon issuance) clearly conveys the action of issuing a thanks coupon, matching the title. However, it fails to distinguish this tool from sibling tools like rms_issue_coupon or rms_thanks_coupon_update, which may have overlapping functionality, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention specific scenarios, prerequisites, or relationships to other coupon tools, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'get' without any mention of side effects, return format, required permissions, or safety profile. This is a complete lack of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. It essentially restates the title without adding value, making it too sparse to be useful. It is not an appropriately sized description; it is merely a label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema but no output schema or annotations, the description is insufficient. It does not explain the expected return value, input specifics, or potential errors, leaving the agent with too little information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'thanks_coupon_id' with no description and 0% schema coverage. The tool description does not explain what this ID represents or how it should be used, failing to add any meaning beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'サンキュークーポン取得' clearly conveys the action 'get' and the resource 'thanks coupon', making the purpose understandable. However, it does not distinguish this tool from sibling tools like rms_get_coupon or rms_thanks_coupon_search, and lacks scope details such as fetching by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 context, exclusions, or scenarios where this tool is preferred, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (get coupon) without explaining safety (read-only), required permissions, behavior when the coupon does not exist, or what the response contains. This is a minimal disclosure similar to the update_drive example, which received a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one short phrase with no redundancy or wasted words. However, it is under-specified and does not earn its place by adding value beyond the name. It is not verbose, but its brevity crosses into insufficiency, similar to the 'process' example but less severe.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, but the description does not explain what the tool returns, what constitutes a valid coupon_code, or how it differs from other coupon retrieval/search tools. Given the available sibling tools, the description is incomplete for an agent to confidently select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description adds no meaning to the parameter 'coupon_code'. It does not clarify the format, source, or how to obtain the code. Since schema coverage is low (0%), the description was expected to compensate but did not, leaving the parameter semantics completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'クーポン個別取得' (Get individual coupon) clearly states a specific action (getting) on a specific resource (coupon) and implies retrieval of a single coupon, distinguishing it from sibling tools like rms_search_coupons which is for searching. However, it does not explicitly mention the identifier 'coupon_code' or the exact information returned, but the verb+resource combination is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as rms_search_coupons or rms_thanks_coupon_get. There is no mention of prerequisites, use cases, or when not to use it. The name implies usage with a known coupon code, but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details. It does not disclose side effects, permissions, rate limits, or the nature of the operation (e.g., read-only) beyond what 'get' implies, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no wasted words, but it is under-specified to the point of being minimally informative. It lacks any structure or additional context, so while concise, it is not well-structured for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only a one-line description and no annotations or output schema, the tool is insufficiently described for an agent to understand what the settings are, how manage_number is used, or what the return value contains. More context is needed for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, and schema description coverage is 0%. The description does not explain the 'manage_number' parameter or its format/meaning. The parameter name provides some clue, but the description adds no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('get') and resource ('inventory-related settings'), making the primary purpose understandable. However, it does not differentiate this from sibling tools like rms_get_inventory or rms_get_variant_inventory, nor does it clarify what 'settings' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context is provided about scenarios, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Get' implies a read operation, but no details about behavior (e.g., error handling, permission requirements, return format) are disclosed. This is a minimal, non-informative transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it merely restates the tool's name in another language. It is not front-loaded with useful information and lacks structure; while efficient, it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations and no output schema, the description should provide more context. It does not explain the parameter, return value, or how this fits among the many sibling tools, making it inadequate for an agent to reliably use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'manage_number' parameter at all. The description adds no meaning beyond the schema field name, so the agent cannot infer what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '商品取得（items.get）' which clearly means 'Get product', with a specific verb and resource. However, it does not distinguish among sibling tools like rms_search_products or rms_bulk_get_products, though 'get' implies single-item retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. It does not mention that it fetches a single product by manage_number or when search/bulk operations 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing side effects, permissions, or mutation behavior. It does not explain that 'reply' likely sends a message, 'mark_complete' changes inquiry status, or any other behavioral impact. The bare action list offers no transparency about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the resource and lists all action families. It contains no wasteful verbiage. However, for a multi-action tool with 10 parameters, a more structured breakdown (e.g., grouping actions with their typical parameters) would improve clarity without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, an enum of 7 actions, and no output schema. The description only names the actions and gives no action-specific input requirements, return formats, error conditions, or examples. This is severely incomplete for an agent to invoke actions like 'reply' or 'mark_incomplete' correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, leaving 7 of 10 parameters undocumented. The description does not compensate by explaining the meaning or requirements of any parameter. It only lists actions and provides no insight into fields like 'page', 'message', 'inquiry_number', or 'no_merchant_reply'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool manages inquiries and lists supported operations (count, list, detail, reply, read, complete, incomplete). This clearly identifies the resource and distinguishes it from sibling tools, which are not inquiry-focused. However, the verb 'management' is generic and could be more specific, and the action list only names actions without detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives, or which action to select for a given scenario. The description merely enumerates actions like 'reply' and 'mark_read' without context, prerequisites, or exclusions. Usage is implied by the tool name but not explicitly clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'register inquiry attachment.' It does not disclose side effects, required permissions, request format, or response behavior, leaving the agent to infer only that it is a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise but underspecified. It largely restates the title in Japanese without adding operational detail, so it does not earn its place as a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter explanation, the description is factually incomplete. An upload tool with a free-form body parameter needs at least guidance on request structure or content type, which is entirely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'body' is an unconstrained object with 0% schema description coverage. The description does not explain what fields or structure the body should have, making it impossible to construct a valid request from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '問い合わせ添付ファイル登録' clearly states the action (register/upload) and resource (inquiry attachment), matching the tool's purpose. It does not explicitly differentiate from the sibling 'rms_inquiry_attachment_get', but the contrast is implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any context about prerequisites, typical scenarios, or caveats. It is purely descriptive without actionable usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of behavioral disclosure. It merely states 'Update delivery method / delivery destination information' without detailing side effects, permission requirements, idempotency, or how existing data is affected. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief noun phrase in Japanese, which is concise and front-loaded. However, its brevity is almost under-specification, and the structure lacks a full sentence to provide context. For a tool with a nested schema, more structure would be beneficial.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters (one nested), no output schema, and no annotations, while the description is a single phrase. Given the many similar sibling tools (e.g., rms_update_shipping, rms_update_sender), the description does not adequately contextualize usage, return values, or errors, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either 'order_number' or 'delivery'. The nested 'delivery' object allows arbitrary properties via propertyNames and additionalProperties, but the description adds no clarification, forcing the agent to rely solely on the schema's minimal structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '配送方法／お届け先情報更新' translates to 'Update delivery method / delivery destination information', clearly indicating the tool updates delivery-related details. It specifies the verb 'update' and the resources (delivery method and address), but does not explicitly distinguish itself from sibling tools like rms_update_shipping, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as rms_update_shipping or rms_update_sender. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the generic purpose and gives no details about side effects, permission requirements, restrictions after shipping, or what 'updating sender' actually changes. This is insufficient for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise and front-loaded. However, it is essentially a restatement of the name and provides no additional structure or elaboration. It is under-specified rather than effectively concise, so it doesn't fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the tool needs more context to be properly understood. The description does not explain what 'sender' means in this domain, what constraints exist after shipping, or what the expected response is. It is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain either parameter. 'order_number' and 'sender' are named in the schema but their meanings, formats, or constraints are not described. The nested object 'sender' is completely opaque, so the description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '送付先情報更新（発送後）' clearly states the action (update sender information) and the context (after shipping), distinguishing it from the sibling tool rms_update_sender. However, it simply translates the name/title rather than adding new explanatory detail, so it is clear but not richly descriptive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The presence of a sibling tool rms_update_sender (without 'after_shipping') suggests a timing distinction, but the description does not explicitly state when to choose one over the other or mention any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only states that sub-status is updated, but fails to mention side effects, reversibility, whether it modifies order records, or any required permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it's a fragment rather than a structured sentence. It conveys the basic purpose but lacks any additional useful structure or detail. This is under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description is not complete. It doesn't explain what order_status_list should contain, how the update behaves, or what the expected response is. The tool is unclear for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the parameter 'order_status_list' is entirely unexplained. The description does not mention the parameter at all, leaving the format, keys, or meaning of the list completely ambiguous. No compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates sub-status with examples (e.g., preparing for shipment, confirmed). This differentiates it from sibling tools like update_shipping or confirm_order, though it doesn't explicitly name them. The verb+resource structure is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. There is no mention of prerequisites, exclusions, or context such as 'for updating other fields use X'. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation (get) but does not mention response format, pagination, inclusive/exclusive boundaries, required permissions, or any side effects, leaving the agent without critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that essentially restates the title in Japanese, adding minimal information. This is under-specification rather than effective conciseness; the sentence does not earn its place by providing new insights.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking annotations and an output schema, the description alone must fully inform the agent, but it only gives a vague purpose. It does not explain result contents, behavior when one parameter is omitted, or how this tool differs from the closely-related rms_bulk_get_inventory, making the description incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not address min_quantity or max_quantity at all. Although the parameter names are self-explanatory, the description fails to clarify how the range is applied (inclusive/exclusive), defaults when omitted, or validation, so no additional meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '在庫数範囲での一括取得' (bulk get by inventory quantity range) identifies a verb and resource with a range qualifier, distinguishing it from siblings like rms_bulk_get_inventory or rms_get_inventory. However, it closely paraphrases the title and lacks explicit detail about what is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as rms_bulk_get_inventory or rms_search_products. There are no mentions of typical use cases, filtering constraints beyond quantity, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It indicates a read operation ('取得') and lists return fields, but does not disclose pagination behavior, potential large result sets, or the impact of the include_variants parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, efficiently conveying the primary purpose and key fields. However, brevity sacrifices parameter explanation, making it slightly less useful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with one parameter and no output schema, the description should at least explain include_variants and whether results are paginated. It only covers the basic listing scope, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, include_variants, has no schema description and is not mentioned in the tool description. The agent cannot infer what enabling variants does, making the parameter effectively useless without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of all products with management number, name, and price. The 'all products' scope differentiates it from sibling tools like rms_search_products or rms_get_product, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling tools (search, get, bulk get, etc.). The description implies usage for a full product listing but lacks exclusions or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions that the official request body should be passed as-is, giving a glimpse into how the tool expects input, but it says nothing about safety, side effects, return value, or any constraints. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing a single phrase with no unnecessary words. It is front-loaded with the resource ('購入商品') and includes a parenthetical instruction about the request body. While it could be more structured, it is appropriately brief for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no output schema, and a nested object parameter, the description is far too sparse to fully inform an agent. It does not explain what the tool returns, what fields the request body requires, or any contextual prerequisites. The reference to 'official request body' assumes external knowledge, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single 'body' object with no property details (0% coverage). The description adds value by specifying that the body must be the official request body for the underlying getOrderItem API, which provides some semantic context beyond the schema. However, it does not elaborate on the actual structure of that body, so it only partially compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The title states 'Get order items' and the description says '購入商品API: getOrderItem', which clearly references retrieving ordered items. However, the description is terse and does not elaborate on the scope or differentiate it from similar sibling tools like rms_search_order_items, making it only moderately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. The only usage hint is to pass the official request body as-is, which is more of a parameter instruction than a usage scenario. It does not mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates a read operation but does not explain the meaning of the required parameter, return format, pagination, or any constraints. For a get operation, this is minimal but not completely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words, and it effectively communicates the core purpose. However, it is overly terse because it omits necessary parameter and usage details, but for pure conciseness it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is inadequate. It fails to define the parameter, clarify the response, or differentiate from closely related sibling tools (e.g., rms_get_variant_inventory), leaving the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'manage_number' with zero description coverage, and the description does not mention it at all. The agent is left without any explanation of what manage_number represents or how to use it, so parameter semantics are completely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get product variant list (inventory)' clearly states a get operation for product variants with inventory data, using a specific verb and resource. It is distinct enough from siblings like rms_get_inventory or rms_get_variant_inventory, though it could be more explicit about the relationship to these tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about use cases, prerequisites, or preferred scenarios, making the selection decision ambiguous among the many inventory/product tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions `fields にクーポン要素を渡す` (pass coupon element to fields) and `XML IF`, but does not disclose whether it is a full replacement, what happens to existing data, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two clauses) with no fluff, but it is under-specified. While concise, it lacks essential content, making it less effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a nested object parameter, this description is incomplete. It does not explain the XML interface, field structure, operational context, or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with one `fields` parameter. The description adds only vague guidance (`fields` should contain a coupon element) but fails to define the element's structure or required sub-fields, which is insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states `クーポン更新` (update coupon) with a parenthetical `XML IF`, identifying the action and resource. However, it does not distinguish from sibling `rms_patch_coupon`, which also updates coupons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like `rms_patch_coupon`. The description lacks prerequisites, context, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the update action but does not explain whether the 'orderer' object is replaced entirely or merged, whether permissions are required, or what side effects may occur. This is insufficient for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that avoids verbosity and front-loads the core purpose. However, it is under-specified for the tool's complexity, but this dimension only measures conciseness and organization, which is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested 'orderer' object, no annotations, no output schema) and the large set of sibling tools, a one-line purpose statement is far from complete. It omits behavioral details, parameter semantics, usage context, and return information, leaving substantial ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not clarify either parameter. It does not explain 'order_number' as the order identifier or the structure of the 'orderer' object, which is described only as a generic object with arbitrary properties. The agent receives no meaningful guidance for constructing inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '注文者情報更新' translates to 'Update orderer information', clearly identifying the action (update) and resource (orderer info). It distinguishes from sibling update tools like rms_update_shipping or rms_update_memo by focusing specifically on the orderer, though the scope of 'orderer information' remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool over alternatives such as rms_update_shipping or rms_update_sender, nor does it mention any prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It only states the tool updates shipping information and requires basketId, but it does not reveal side effects, idempotency, permissions, or what happens to existing shipping data. This is minimal and leaves significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action. There is no verbosity or redundant words, though it could have been structured to include more essential details without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with 3 required parameters, including a nested array, and has no output schema or annotations. The description is too sparse to provide complete context for correct invocation; it lacks usage scenarios, parameter breakdown, and response expectations, making it inadequate for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no parameter meanings. It repeats that basketId is required (already in schema) and does not explain the shipping_list array structure, its items, or the relationship between order_number and basket_id. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update shipping') and the subject ('配送情報更新' = shipping information update), and specifies the core function of registering carrier and tracking number. However, it does not distinguish itself from the sibling tool rms_update_shipping_async, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives like rms_update_shipping_async or other order update tools. The only additional hint, 'basketIdが必要' (basketId required), is already declared in the input schema, so it adds no practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Delete product' without explaining side effects, such as whether the deletion is hard or soft, whether it cascades to related records, or whether permissions are required. The 'items.delete' hint adds little beyond the already-implied destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely brief, consisting of only the tool name and an API reference. While this is concise, it borders on under-specification rather than efficient communication. The core purpose is clear, but the minimal wording leaves out essential usage and parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description might seem sufficient at first glance, but it lacks context about return values, error conditions, or any behavioral caveats. Since there is no output schema and no annotations, the description should provide more guidance than just the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single parameter 'manage_number' with no description, and the schema description coverage is 0%. The tool description does not explain what 'manage_number' is or how to obtain it. The description completely fails to compensate for the missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '商品削除' which translates to 'Delete product', clearly indicating a destructive action on a product resource. The appended 'items.delete' references the underlying API endpoint, and the tool name itself is unambiguous. It distinguishes itself from siblings like rms_upsert_product and rms_patch_product, which create or update products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. There are no prerequisites, no warnings about products that may be referenced by orders or other entities, and no mention of when deletion might be inappropriate. The only context is the tool's name and description, which do not address usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of disclosing behavioral traits. It only states the action without mentioning permissions, side effects, reversibility, or whether the coupon is issued as draft or active. The behavior beyond the basic creation is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the essential verb and object, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, a one-line description is severely inadequate. It does not explain the return value, the coupon type scope, or usage context, and it leaves key behavioral aspects unexplained. Sibling tools like rms_thanks_coupon_issue further complicate, but the description does nothing to disambiguate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% coverage with descriptions for item_type, discount_type, and the two date fields, but the tool description adds no parameter semantics. Parameters like coupon_name, issue_count, discount_factor, and member_avail_max_count remain undocumented, and the description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb '発行' (issue) and resource '新規クーポン' (new coupon), clearly identifying it as a creation operation. It distinguishes from update/delete/search siblings by implying creation, but it does not differentiate from rms_thanks_coupon_issue, leaving potential ambiguity regarding coupon type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as rms_update_coupon, rms_patch_coupon, or rms_thanks_coupon_issue. There is no mention of prerequisites, conditions, or scenarios that would favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must disclose behavior; it only says 'search/list' and does not state read-only safety, pagination defaults, rate limits, or output shape. 'Issued coupons' hints at a non-mutating lookup but is not enough to fully characterize behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single short Japanese sentence that is front-loaded and free of fluff. It loses one point only because it is so minimal that it provides little beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It omits pagination semantics, return fields, filtering behavior, and distinction from other coupon tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter explanations. 'coupon_name' and 'page' are understandable from names alone, but 'hits' is ambiguous (page size vs. total hit count) and no description compensates for it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'クーポン検索（発行済みクーポンの一覧）' clearly identifies the tool as a search/list operation on coupons, with the parenthetical adding scope by restricting to already-issued coupons. This distinguishes it from sibling tools like rms_get_coupon (single retrieval) and rms_issue_coupon (creation), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over rms_get_coupon, rms_search_orders, or rms_thanks_coupon_search. The parenthetical implies it is for listing issued coupons, but there are no explicit use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that the operation is read-only, any potential side effects, auth requirements, or pagination behavior. The only behavioral hint is 'returns a list', which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words, earning high marks for succinctness. However, it is arguably too sparse to fully support the tool's complexity, so it doesn't reach a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficiently complete. It lacks essential details like search criteria, pagination, result format, and any behavioral or safety context, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters; it does not explain start_date, end_date, date_type, or progress_list. Schema coverage is only 50% (start_date and end_date are described as YYYY-MM-DD, but date_type and progress_list are not), and the description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) and resource (orders), and specifies the return type as a list of order numbers ('注文番号リストを返す'). This distinguishes it from order detail or mutation tools, though it doesn't explicitly differentiate from sibling search tools like rms_search_order_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like rms_order_detail or rms_search_order_items. It only describes what the tool does, not the context or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral traits. It reveals the async nature, which is a key behavioral trait, but it does not explain how to retrieve the async result, what side effects occur, or any error/failure behavior. The reference to the official models format is a constraint but not a full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and the async qualifier. It avoids unnecessary words. However, it is so brief that it omits crucial details, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As an async mutation tool with no output schema and no annotations, the description should explain how the async process works and how to check the result (e.g., via rms_get_shipping_async_result). It does not mention any follow-up steps, potential failure modes, or return behavior, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the only parameter 'models', and the description only says 'models は公式 IF の updateOrderShippingModels 形式' (models are in the official IF updateOrderShippingModels format). This points to external documentation but does not explain the parameter's structure, required fields, or meaning. Thus it barely compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '発送完了報告（非同期）' (shipping completion report, async), clearly indicating the tool's action and its asynchronous nature. This distinguishes it from the synchronous sibling rms_update_shipping, though it does not explicitly use the verb 'update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '非同期' (async), implying the tool is for asynchronous shipping updates, but it provides no explicit contrast with the synchronous rms_update_shipping or any alternative. It also references the official IF format but gives no further usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits, but it only says 'update order memo (store-side internal memo)'. It fails to mention whether the memo is overwritten, required permissions, idempotency, side effects, or confirmation behavior, which is especially important for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that is front-loaded with the action and resource. There is no filler or redundant repetition of the title, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has low complexity (two string parameters and no output schema), the description is still incomplete: it lacks annotations, usage context, behavioral side effects, and parameter semantics. It only covers the basic purpose, leaving an agent with too little information for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and neither parameter has a description in the schema. The description only clarifies that the memo is store-side internal, adding minimal value beyond the parameter names; it does not explain order_number format or memo constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'order memo', and adds the parenthetical 'store-side internal memo' clarifying scope. However, it does not explicitly differentiate this tool from sibling tools like rms_update_remarks, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided: the description does not say when to use this tool, when not to use it, or mention alternative tools. The context signals also offer no hints, so an agent has no basis for selecting this tool over similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it is a 'partial update' but does not clarify whether unspecified fields are preserved, whether deletions are supported, or any side effects/permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the tool's purpose and directs usage of the key parameter. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested patch_data, no output schema, and no annotations, this description is too sparse. It lacks information about return values, error conditions, prerequisites, or behavior on unspecified fields, making it insufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to patch_data by saying it contains update fields, which is helpful given 0% schema coverage. However, manage_number is left unexplained, and the description does not fully compensate for the lack of parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a partial product update via 'items.patch' and specifies that patch_data contains the update fields. It distinguishes itself from full products upsert by using 'partial update', though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools like rms_upsert_product or rms_update_price. The description only explains what to put in patch_data, not the context or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys a read-only list operation but does not mention return format, pagination, date filtering semantics, or any side effects or permissions. The added detail about shipping number registration is helpful but not sufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that immediately conveys the tool's purpose. It is front-loaded and free of unnecessary words, earning high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only list without an output schema, the description covers the basic purpose but lacks parameter explanations, usage context, and any caveats. The presence of many sibling tools increases the need for clearer placement, which the description does not provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or format of start_date and end_date. The tool has two undocumented parameters with no compensating context in the description, providing virtually no semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically identifies the tool as a list of orders awaiting shipment with no shipping number registered (発送待ち注文一覧（配送番号未登録のもの）). This clearly distinguishes it from sibling tools like rms_unconfirmed_orders and rms_search_orders, aligning with the definition of specific verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives such as rms_search_orders or rms_unconfirmed_orders. The description only states what the tool does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only restates the tool's function without revealing anything beyond the name: no mention of read-only nature, pagination, result format, rate limits, or side effects. This adds no value beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the main verb front-loaded and filter criteria in parentheses. It is efficient and logically structured, though it could benefit from a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is too thin. It fails to explain parameter semantics, return values, pagination behavior, or how it differs from similar listing tool rms_all_products. An agent cannot reliably select and invoke this tool with such limited context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 0% description coverage, and the description only clarifies one of them: genre_id ('ジャンル'). It does not explain offset (pagination), item_url, or search_type, leaving the agent to guess their purpose. This significantly under-serves the agent's need to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '商品検索' (product search), a clear verb+resource, and adds specific filter criteria (管理番号・商品名・ジャンル) that distinguish it from sibling tools like rms_get_product or rms_all_products. It lacks explicit naming of alternatives but is specific enough for basic differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the filterable fields (management number, product name, genre), suggesting it is for searching with criteria. However, it does not explicitly state when to use this tool versus alternatives (e.g., rms_get_product for a single product, rms_all_products for full list), nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a behavioral trait: the remarks are shown to the buyer, which is important context. However, with no annotations provided, the description carries the full burden, and it omits other behavioral details such as whether remarks are overwritten, length limits, or side effects. The buyer-visible note earns some credit, but the overall disclosure is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Japanese that front-loads the action and includes one useful qualifier. No redundant words or unnecessary details. It is efficient and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and any parameter explanations, the description is too sparse for an agent to fully understand the tool's behavior. It covers the basic purpose but not operational context like required order state, input formats, or expected response. This is more than a complete miss but still insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. It does not explain that order_number is the order identifier or that remarks is the text to update. The agent must rely solely on the parameter names, which offer minimal meaning. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool updates remark information (備考情報更新), with the parenthetical clarifying these are remarks displayed to the buyer (購入者に表示される備考). This is a clear verb+resource pair that distinguishes it from similar tools like rms_update_memo, which likely handles internal memos. However, it is somewhat tautological—'update remarks' followed by a definition of remarks—but the buyer-visible qualifier adds meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives. It does not mention conditions such as order status, or contrast with rms_update_memo or rms_update_sub_status. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the update uses an 'ABSOLUTE' value setting, which is a key behavioral trait. However, it does not explain side effects (e.g., overwriting existing quantities), validation rules, or any error conditions. With no annotations, the description carries the burden but only partially addresses it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. It is concise and free of fluff, though it could add valuable details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a non-trivial parameter (array of objects) and no output schema, yet the description provides minimal context. It does not explain expected input format, return values, or preconditions, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, and the description provides no information about the 'updates' parameter or its structure. The schema defines a complex array of objects, but the description does not help an agent understand how to construct the updates, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'inventory quantity', with the scope 'per variant' and 'ABSOLUTE' setting. This distinguishes it from other inventory-related siblings like rms_get_inventory or rms_upsert_variant_inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a specific use case (absolute value updates per variant) but provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or point to any sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of transparency. It only states that the price is changed and mentions sale-price handling, but it does not disclose side effects, required permissions, reversibility, or impact on other product data like inventory or variant status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that provides the core purpose and a practical use case without any filler or redundant repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema, and the description does not cover parameter details, side effects, or any prerequisites. It provides a clear overall purpose but is insufficient for an agent to confidently invoke the tool correctly in all contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify the role of 'price' as the price being changed, but it does not explain 'variant_id' or 'manage_number', nor does it clarify the expected format of the price (string vs number) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the product price and mentions the specific use case of setting/restoring sale prices. It distinguishes the tool by its focus on price, though it does not explicitly contrast with sibling tools like rms_patch_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'used when setting/restoring sale prices' gives a clear intended context, but there is no explicit guidance on when not to use it or how it differs from sibling update tools. The usage is largely implied rather than explicitly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full disclosure burden. It reveals the upsert behavior and key field but omits effects like what happens to unspecified fields, required permissions, reversibility, or return values. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core operation and key field. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an upsert with 9 parameters, no annotations, and no output schema, the description is too sparse. It fails to map fields correctly, explain required fields, or describe behavior on existing vs new records, leaving significant gaps for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies manage_number as the upsert key and references title/price/genre, but the schema has 9 parameters and the description leaves tagline, item_type, variant_id, description, item_number, and standard_price undefined. It also uses 'price' where the schema has 'standard_price', adding potential confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation clearly: '新規登録または更新（管理番号でupsert）' (create or update by management number). This distinguishes it from product read/delete/patch siblings, though it does not explicitly compare with rms_patch_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to register or update a product identified by manage_number. No explicit guidance on when to prefer this over rms_patch_product, rms_update_price, or other alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. '取得' implies a read operation, but it does not disclose response format, pagination behavior, authentication needs, or any constraints beyond the basic purpose. This is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is structurally simple with one well-documented parameter, so the description is minimally adequate. However, without annotations, an output schema, or guidance distinguishing it from sibling inventory tools, the overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema already describes item_urls as an array of manageNumber values. The description adds only the context that these URLs specify the products, which is marginal beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '指定商品の在庫情報を取得' clearly states the verb (取得/get) and resource (在庫情報/inventory info) for specified products. It is distinct from generic getters but does not differentiate among the many inventory-related siblings like rms_bulk_get_inventory or rms_get_variant_inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives such as rms_bulk_get_inventory, rms_bulk_get_inventory_range, or rms_get_variant_inventory. The description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'confirmation of processing result' which essentially restates the tool name. It does not disclose whether the operation is read-only, how to interpret the result, error conditions, or the role of the assertion_token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise and front-loaded. However, it is under-specified and does not add much beyond the tool name, making it only minimally acceptable in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and one parameter with no coverage, the description should provide substantial context. It only states the general purpose and lacks essential details about when to call, what the token is, and what the response looks like. The tool is simple but still severely under-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the assertion_token parameter at all. The agent receives no guidance on what the token is, how to obtain it, or how it relates to the async request. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: confirming the processing result of an asynchronous shipping completion report. The verb '確認' (confirm) and resource '発送完了報告（非同期）の処理結果' make it distinct from sibling tools like rms_update_shipping_async, which initiates the async operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for checking the result of an async operation. This is clear given the sibling tool rms_update_shipping_async. However, it does not explicitly state when to use it versus alternatives, but the context is understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states 'get sub-status list', implying a read-only operation but not explicitly disclosing side effects, permissions, return format, or rate limits. With zero behavioral context, the agent must guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no wasted words. It is front-loaded and easily parsed. It is slightly under-specified but efficient for a simple get-list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description states the core action but lacks context about what a 'sub-status' is, what the response contains, or when this list is relevant. It is adequate minimally but leaves gaps for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% description coverage trivially). Per the rubric, 0 params yields a baseline of 4. The description adds no parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'サブステータス一覧取得' translates to 'Get sub-status list', which clearly indicates a retrieval operation with a specific resource. It does not explicitly differentiate itself from siblings like rms_update_sub_status, but the verb 'get' versus 'update' in the sibling name provides natural distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no context about the sub-status list's role. It is a bare operation name without any usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core purpose and clarifies the status meaning, but does not mention return format, pagination, date filtering behavior, or any operational details. Minimal transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the essential purpose. Every word contributes meaning, with no fluff or redundancy. It is appropriately minimal for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is relatively simple, the description omits necessary context such as parameter semantics, what fields are returned, and how this tool differs from closely related siblings. Given no output schema and no annotations, the description is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the start_date and end_date parameters at all. An agent has no idea what these parameters do or how to use them, making this a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List of unconfirmed (awaiting order confirmation) orders' in Japanese, specifying both the action (list) and the resource (unconfirmed orders). It distinguishes this tool from siblings like rms_search_orders or rms_pending_shipping by focusing on the unconfirmed status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving unconfirmed orders, but provides no explicit guidance on when to prefer this over alternatives like rms_search_orders or rms_order_detail. No when-to-use or when-not-to-use criteria are given, leaving selection to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, nor does it describe output structure, pagination, or any side effects. The phrase only lists ranking metrics, which is insufficient for understanding the tool's behavior beyond the basic output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that conveys the core purpose without any superfluous words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description is minimal yet adequate for a simple read-only ranking tool. It explains what the ranking is based on, but it omits context such as whether the tool is read-only, the shape of the returned data, and any behavioral caveats. For a tool of this simplicity, this is on the boundary of acceptable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by specifying the ranking dimensions (quantity, sales, average unit price), which helps interpret the purpose of the parameters (e.g., top_n limits the ranking, start_date/end_date define the period). It does not directly map parameters to metrics but clarifies the overall semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '商品別ランキング（数量・売上・平均単価）' clearly identifies the resource (product ranking) and the specific metrics (quantity, sales, average unit price). It distinguishes from sibling tools like rms_daily_sales or rms_search_products by focusing on ranking. However, it lacks an explicit verb like 'get' or 'list', making it slightly less clear than a full action-oriented description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or specific use cases. It only states what the tool does, leaving the agent to infer when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only says 'update sender information' without mentioning mutations, permission requirements, idempotency, validation, or what happens if the order is already shipped. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact phrase that communicates the core purpose and timing in one line. It is front-loaded and has no unnecessary filler, though it risks being too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a nested object parameter, no output schema, and no annotations, a one-line description is not enough. It lacks field-level details for 'sender', usage semantics, and interaction with shipping state, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'sender' nested object structure or the format of 'order_number'. The parameter names give some hint, but the description adds no value beyond the names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (update sender information) and the timing scope (before shipping), which clearly distinguishes it from the sibling tool rms_update_sender_after_shipping. The title reinforces both the resource and the pre-shipment constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The '(before shipping)' qualifier implies this tool should be used prior to shipment, but the description does not explicitly state when to use it instead of rms_update_sender_after_shipping or rms_update_delivery. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the summary components but does not reveal whether the tool is read-only, how daily aggregation works, what date range behavior applies, or what the response structure looks like. This is a significant gap for a tool that likely returns a report.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase that conveys the essential purpose without unnecessary words. It is front-loaded and every element adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple report tool with two parameters and no output schema, the description adequately states the core functionality and components. However, it lacks details about the response format, aggregation level (e.g., per-day vs. total), and any filtering behavior, which would be helpful given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the schema with format and defaults, so schema coverage is 100%. The tool description adds context about the summary contents but does not provide additional parameter-specific semantics beyond what the schema already offers, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (daily sales summary) and specifies its contents (count, tax, coupon, shipping), making it easy to understand what the tool does. It is specific enough to be distinguished from sibling tools, but it lacks an explicit verb such as 'retrieve' or 'list', relying on the title for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the name and description: if you need a daily sales summary, use this tool. However, there is no explicit guidance on when to use it versus alternatives, nor any exclusions for cases where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It states the tool returns 'full detail JSON', indicating a read operation. However, it does not mention edge cases, return format specifics, or limitations. Given the simplicity of a read-only detail fetch, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, front-loaded with the key action and target. No wasted words, and it is appropriately sized for a tool that takes one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one input parameter and no output schema. The description states the purpose but lacks detail on the response structure and edge cases. Given the simplicity, it is minimally complete, but more detail about the 'full details' would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage). The description clarifies that the parameter is the order number, adding meaning beyond the schema property name. However, it does not explain that the parameter accepts an array of order numbers or any format constraints, leaving the schema to convey that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '注文番号指定で全詳細JSON' clearly indicates the tool retrieves full order details for specified order numbers. It effectively distinguishes itself from siblings like rms_search_orders (search) and rms_get_order_items (items only) by emphasizing 'full detail' and 'order number'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you have order numbers and need full details. However, it does not explicitly contrast with alternatives or state when not to use it. The context of sibling tools suggests it is for direct order-number lookup, but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only states 'Order cancellation (before shipping)' and does not mention effects on order status, payment, inventory, permissions, or reversibility. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no redundant words or filler. It is front-loaded and economically written, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature, lack of annotations, and absence of an output schema, the description is too sparse. It fails to explain prerequisites, consequences, or how to use cancel_reason, making it incomplete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics, but the schema already describes cancel_reason (50% coverage) and order_number is self-explanatory by name. The schema provides sufficient meaning for both parameters, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '注文キャンセル（発送前）' explicitly states the action (cancel) and resource (order) with a scope qualifier (before shipping), clearly distinguishing it from the sibling tool rms_cancel_order_after_shipping. This meets the 'specific verb+resource+scope' criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'before shipping' provides clear context for when to use this tool, implicitly excluding shipped orders. However, it does not explicitly name the alternative for after-shipping cancellations (though the sibling name does), so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavioral effect (status change) and bulk capability, but lacks details on idempotency, error handling, permissions, or reversibility. This is a minimum viable disclosure but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the action and state transition. No wasted words; it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential usage context (state transition). However, it omits potential side effects, prerequisites, or behavior on already-confirmed orders, and it doesn't differentiate from overlapping sibling tools like rms_update_sub_status. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, but it only states 'バルク対応' (bulk support), which merely echoes the array type already in the schema. It does not explain what constitutes an order number, format constraints, or semantics beyond bulk, leaving the parameter underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '受注確認' (order confirmation) with a specific state transition from '注文確認待ち' (waiting for order confirmation) to '楽天処理中' (Rakuten processing). This distinguishes it from sibling tools like rms_cancel_order or rms_update_sub_status by specifying the exact workflow step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (when orders are in the waiting-for-confirmation state and need to proceed to processing) and mentions bulk support. However, it does not explicitly name alternative tools or state when not to use it, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a non-mutating diagnostic check, and the wording 'can start' and 'credentials are present' accurately conveys the scope. However, it does not describe the output format or what happens if the check fails, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all necessary information with no redundancy or filler. Every word contributes to understanding the tool's purpose, making it optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, zero parameters, and lack of an output schema, the description covers the essential aspects for invocation: what the tool checks and why. It would be slightly stronger if it hinted at the return value, but the description is complete enough for an agent to select and call this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 is appropriate because the empty schema fully describes the interface and the description appropriately focuses on behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks server startup and credential presence, using a specific verb ('check') and resource ('MCP server', 'RMS credentials'). This fully distinguishes it from the functional sibling tools like rms_product_ranking or rms_order_detail, which perform domain operations rather than health diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (verifying the server is operational and credentials exist), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any preconditions or follow-up actions. It gives enough context for a health check but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
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/moneyan9/rakuten-rms-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server