Loading ToolBench
MCP server for Mpampa Cereals e-commerce platform enabling product browsing and order placement with payment processing
This MCP server has 4 tools with schemas visible and descriptions present, but suffers from significant quality gaps: (1) descriptions are often too long and procedurally instructive rather than declarative; (2) schemas are Zod objects (not JSON Schema) without inline parameter descriptions visible in registration; (3) error handling is minimal; (4) no input validation guidance; (5) naming follows verb_noun convention but lacks clarity around dependencies. The tools cover a simple e-commerce workflow (get products, place order, verify OTP), but the tool composition doesn't enforce clear data flow or idempotency. Overall, this is a fair-to-poor community implementation with moderate foundational issues.
Fetch the information for a particular product. If the name is made up of one or more words, break it down to smaller letters and put hyphens in between the words
Get all the products from Mpampa Cereals for the user to select
Place an order for the user based on the information they give you; e.g. the product and the quantity they want. If they don't provide all the necessary details, prompt them to add the remaining details needed to place the order before doing so. Make The default paymentStatus and orderStatus pending. Ignore the fields marked as optional
Verify the OTP provided by the user after initiating the charge, and complete the order placement if verification is successful.
get_products has no input schema (empty object {}). This is technically valid for a read-only discovery tool, but it provides no guidance on pagination, filtering, or limits. Tool may return unbounded result set.
place_order and verify_otp_and_complete_order descriptions are procedurally instructive ('If they don't provide all the necessary details, prompt them...') rather than declarative. Descriptions should state WHAT the tool does, not HOW an LLM should use it. The description for place_order (119 chars with instructions) violates the 10-1024 char guideline by being too prescriptive.
get_one_product description includes instruction 'If the name is made up of one or more words, break it down to smaller letters and put hyphens in between the words.' This is usage guidance, not a description of what the tool does. It should state: 'Retrieve detailed information for a specific product by ID.' Instructions belong in system prompts, not tool descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
place_order schema is complex with nested object (items array with nested properties, shippingAddress object) but parameter descriptions are embedded in Zod definitions, not visible in the tool registration call. LLMs cannot see Zod .describe() chains, only the inputSchema passed to registerTool(). Parameter descriptions for nested fields (fullName, phone, address, email in shippingAddress) are missing from the schema visible to LLMs.
verify_otp_and_complete_order has a long, compound name suggesting it does two operations (verify OTP AND complete order). While the implementation actually does both, the naming violates the pattern that tools should have single, clear responsibilities. Better split: verify_otp (returns confirmation) → complete_order (accepts confirmation). Current design forces LLMs to invoke a single opaque two-step operation.
place_order throws 'Failed to initiate payment' if initiatePayment fails, and 'No transaction reference received' if response is missing. Error messages do not guide recovery. They should say: 'Payment initiation failed. Common causes: invalid email, network timeout, or service unavailable. Try again, or use a different network provider.' Current errors give LLM nothing to act on.
verify_otp_and_complete_order throws 'OTP verification failed. Please check the code and try again.' if submitOTP fails. No context on rate limits, timeouts, or whether the OTP has expired. Error handling is minimal.
place_order calls initiatePayment (external service) without explicit timeout. If the payment gateway is slow or hanging, the agent will block indefinitely. No timeout handling visible in code.
place_order accepts optional 'transactionReference' and 'deliveryCost' and 'discount' parameters, but the function description does not explain when these are used, whether they override automatic calculations, or what happens if they conflict with computed values. Undocumented parameter relationships.
place_order defaults network to 'mtn' without explanation. This is a reasonable default, but the description should state: 'Mobile network provider (optional, default: mtn). Accepted values: mtn, vodafone, airtel, etc.' Current schema has no enum constraint and no list of valid values.
place_order returns a structured response with transactionReference and message, which is good. However, the response structure is not documented in the tool definition. LLMs have no formal schema for what fields to expect, forcing them to infer from JSON output.
The workflow requires place_order → user receives OTP → verify_otp_and_complete_order. The tool composition is correct, but there's no explicit idempotency guarantee. If an agent retries place_order with the same input twice, does it create two payment charges? No documentation of idempotency or retry safety.