Model Context Protocol (MCP) tool server for the commerce orchestrator, providing tools for shopping cart management, checkout, order processing, and payment operations
Commerce Orchestrator MCP exposes 14 well-structured commerce tools with complete JSON schemas and clear naming conventions. All tools follow verb_noun patterns (create_cart, add_item, get_cart, etc.). Schemas are present and properly typed for all tools. However, parameter descriptions are sparse or missing entirely, most parameters lack explanatory text beyond their names. Tool descriptions are present but brief (10 - 50 chars), falling below the 50 - 200 char LLM-optimized baseline. Error handling guidance is absent; tools do not indicate recovery paths or categorize failures. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification (READ_ONLY, WRITE, IRREVERSIBLE). Output schemas are not documented. Composition is sound, tools chain logically (create_cart → add_item → get_cart → start_checkout → execute_checkout), but missing parameter descriptions and output documentation limit LLM reasoning quality.
Add an item to a cart
Apply a discount or promo code
Capture an authorized payment
Create a new shopping cart
Execute checkout for a cart
Get current cart state
Retrieve an order by ID
Parameter descriptions missing or trivial. Most parameters (merchant_id, cart_id, item_id, quantity, etc.) lack explanatory text. LLMs cannot infer parameter meaning from names alone, a 'code' parameter could be promo code, error code, or status code.
Tool descriptions are too brief (10 - 50 chars). Baseline for LLM-optimized descriptions is 50 - 200 chars. Current descriptions lack context on WHEN to use each tool, prerequisites, and what it returns. Example: 'Create a new shopping cart' does not explain when to call it vs other tools or what fields the response contains.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
List orders for a tenant
Refund a captured payment
Remove an item from a cart
Quote shipping or pickup options for a cart, and optionally select one. Omit selected_option_id to see the quotes before committing.
Mark cart as checkout-ready
Update item quantity in a cart
Void an authorized payment
No tool annotations despite clear risk stratification. Tools marked IRREVERSIBLE (execute_checkout, capture_payment) and WRITE (add_item, remove_item) lack destructiveHint and idempotentHint annotations. LLMs cannot distinguish safe-to-retry operations from irreversible ones without explicit hints.
Output schemas not documented. No specification of what fields get_cart, execute_checkout, get_order, or list_orders return. LLMs cannot plan downstream tool calls or extract required IDs (e.g., order_id for get_order) without knowing response structure.
No error handling guidance. Tools do not indicate what errors are retryable, user-fixable, or fatal. No recovery paths provided. Example: if execute_checkout fails with 'insufficient inventory', should the agent retry, ask the user, or call a different tool?