Loading ToolBench
Client for driving e-commerce dynamic repricing calculations based on inventory velocity and competitive data. Supports a mock mode for local testing.
This MCP server exposes two tools with basic schemas and descriptions, but has critical gaps in parameter documentation, error handling, and output schema specification. The tools are functional but lack the rigor required for production-grade agent integration. Naming is acceptable (verb-first: calculate_, build_), but parameter descriptions are sparse, output schemas are undocumented, and error handling is minimal. The implementation appears to be a Python client wrapper (repricer.py) without explicit MCP server registration visible in the source, tool definitions are inferred from the class methods rather than formally registered with the MCP framework.
Builds a standard Shopify Admin REST API PUT payload draft to update variant pricing.
Calculates the recommended price adjustment based on competitive and velocity heuristics.
Tool definitions are inferred from class methods, not explicitly registered with MCP framework. No visible MCP server instantiation, tool registration, or protocol handlers in provided source.
Output schemas are completely undocumented. calculate_new_price returns a dict with keys 'recommended_price', 'repricing_reason', 'price_delta', but these are never formally specified. build_shopify_payload returns a nested Shopify API structure but the schema is not declared. LLMs cannot plan downstream operations or extract fields reliably without documented return types.
Parameter descriptions are minimal or missing context. 'competitor_prices' is described as 'List of competitor pricing data with source, price, and in_stock status' but does not explain the expected structure, required fields, or how the algorithm uses them. 'inventory' likewise lacks detail about required keys (stock_level, daily_sales_velocity) and their type/range. No parameter validation constraints (min/max, enums, patterns) documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
No error handling or recovery guidance. If competitor_prices is empty, the algorithm raises no explicit error, it silently assumes 'out of stock' and raises price by 15%. If inventory lacks required keys, a KeyError occurs with no user-actionable message. No error responses document failure modes or suggest mitigation steps.
Parameter type hints are incomplete. competitor_prices is typed as List[Dict[str, Any]], which is vague, the agent cannot know what keys are expected (source, price, in_stock). inventory is Dict[str, Any], again losing structure. No enum constraints; no min/max bounds on numeric fields (current_price, competitor prices, inventory levels could be negative or zero).
build_shopify_payload accepts variant_id as a string in 'gid://shopify/ProductVariant/12345' format but performs string manipulation (replace) without validation. No error if variant_id is malformed. The payload is a raw dict without schema documentation, LLMs cannot know if 'price' should be a string, float, or Decimal, or what other fields Shopify expects.
No idempotency or confirmation pattern. calculate_new_price is deterministic given the same inputs, but build_shopify_payload is a write operation (builds an API payload to update variant pricing) with no dry-run, confirmation step, or undo tool. Agents could accidentally apply multiple price updates.