MCP server for processing checkout operations with cart items, payment methods, and shipping addresses. Implements the Agentic Checkout Protocol (ACP) v1.0.
This server has severe deficiencies in tool definition quality. The single tool 'execute_skill_action' exists but lacks proper MCP protocol integration, has minimal descriptions, and critically, no evidence of actual MCP tool registration in the source code. The mcp_server.py file shows only a stub that prints a hardcoded JSON response, there is no actual tool registration, no input schema validation, no output schema documentation, and no error handling beyond basic input checks in the client code. The code does not implement the MCP server protocol; it merely prints JSON to stdout without establishing a stateless request/response loop. Parameter descriptions in the schema are present but generic (e.g., 'List of items in the shopping cart, each with name, price, and quantity' lacks format constraints, validation rules, or LLM guidance). No parameters have min/max bounds, no enums are declared, and no actionable error messages guide recovery.
Execute checkout skill action for processing e-commerce transactions
Tool is not properly registered with MCP server. The mcp_server.py file contains only a stub that prints hardcoded JSON; there is no actual MCP protocol handler, request dispatcher, or tool invocation logic.
No input schema validation or parameter constraints. Parameters lack enums, min/max bounds, regex patterns, or format descriptions. For example, 'payment_method' is an object with no field-level schema; 'shipping_tier' accepts any string and defaults to 'standard' but does not declare valid values (standard|express|free).
No output schema documented. The client.py checkout() method returns a dict with order_id, total_usd, status, and receipt, but the tool definition provides no specification of the return type, field names, or structure. LLMs cannot infer what fields to expect or how to chain downstream operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
Error handling does not guide LLM recovery. The client returns bare status strings like 'FAILED: Empty cart' or 'FAILED: No payment method'. These do not indicate whether the error is retryable, what the LLM should do next, or what corrected input would succeed. No error classification (retryable, user-fixable, fatal) is present.
Tool description is generic and lacks actionable detail. 'Execute checkout skill action for processing e-commerce transactions' does not explain WHEN to call it, what prerequisites are needed (populated cart?), what happens to payment state, or whether the operation is idempotent or destructive. The description is 69 characters, below the 10 - 1024 character baseline and lacks guidance for LLM selection.
Parameter descriptions lack constraint information. E.g., 'Payment details including type, last4 digits, and shipping tier' does not specify which fields are required, what format 'type' accepts, whether 'last4' must be a 4-digit string, or what happens if 'shipping_tier' is invalid. LLMs cannot validate input without explicit constraints in the description.
No pagination or limits on cart items. If an LLM attempts to check out a cart with 10,000 items, the tool silently processes all of them. No 'max_items' constraint, no 'limit' parameter, and no guidance on result size bounds prevent context explosion.
No idempotency guarantee or request deduplication. The tool generates a new order_id on every call (using time.time() + hashlib.md5), so retrying with identical parameters creates a new order. For an irreversible financial operation, this is dangerous, agents should be able to safely retry without side effects.
No dry-run or confirmation step for destructive operation. Checkout is a write operation that consumes payment and generates an order. There is no 'dry_run' parameter, no 'confirm_before_execute' pattern, and no way for the LLM to preview the result (total, tax, shipping) before committing.