Loading ToolBench
An MCP server exposing a policy-gated agentic commerce rail on Razorpay test mode. Allows external MCP-speaking agents to browse a catalogue, build a cart, and pay while respecting spend mandates and audit trails.
Kurta Company MCP server demonstrates solid domain-specific design with clear, action-oriented tool names and comprehensive parameter schemas. All 10 tools have descriptions and input schemas with proper types. However, descriptions are inconsistent in depth, some are excellent (shop_check_spend_policy at ~180 chars with clear decision outcomes), others are minimal (shop_get_cart at ~40 chars). Parameter descriptions vary: shop_search_catalog is well-annotated, but shop_suggest_addons and shop_check_payment_status lack parameter detail. Output schemas are not explicitly documented in the source. Error handling is present but generic, tools return {ok: false, error_code, message} without recovery guidance. Tool composition is excellent: clear separation of concerns (search, add, remove, suggest, policy, approval, payment, audit), proper sequencing (policy before payment), and idempotent reads. No security issues detected, no secrets in parameters, audit trail present. Naming follows verb_noun convention consistently (shop_* prefix). Missing: output schema documentation, richer error messages with actionable next steps, and parameter constraints (e.g., qty 1-5 is in code but not in schema enum).
Add a product to the cart by its catalogue id. Adding does not spend anything; payment is gated separately.
Check whether the outstanding payment has been completed. Never claim an order succeeded without calling this.
Evaluate the current cart against the account holder's spend mandate. Read-only — nothing is charged. ALWAYS call this before attempting payment. Returns 'allow', 'confirm_required' or 'deny' with plain-English reasons you should relay verbatim.
Create a real Razorpay payment link for the current cart. Refuses unless the spend mandate allows it, or the human has approved this exact cart. Never call this without checking the policy first.
The merchant's tamper-evident log of every action taken on this account, including your own, with the reasoning behind each decision.
Output schemas not documented. Tools return structured objects (e.g., cartSnapshot with items, count, total_inr) but LLMs cannot see the response structure to plan downstream calls or extract fields efficiently.
Minimal descriptions on read-only tools. shop_get_cart (40 chars), shop_check_payment_status (50 chars), and shop_remove_from_cart (50 chars) lack context for when/why to call them. Baseline for A+ tools is 50-200 chars with WHAT, WHEN, and prerequisites.
Error responses are generic. Tools return {ok: false, error_code, message} without recovery guidance. E.g., 'NOT_FOUND' for a missing product should suggest 'Try shop_search_catalog() with a broader query.' Agents need actionable next steps.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2025-06-18+ | v2 |
The current cart contents and total.
Remove a product from the cart.
Ask the human to approve this exact cart. Only call this after shop_check_spend_policy returns 'confirm_required'. Approval buttons appear in the account holder's chat; you must stop and wait for their answer.
Search Kurta Company's catalogue. Returns real products with real prices and stock. Use this before recommending or adding anything.
Complementary items for what is already in the cart, plus a dearer alternative where one exists. Suggestions only — nothing is added.
Parameter constraints not in schema. shop_add_to_cart qty is constrained to 1-5 in code (minimum: 1, maximum: 5) but not visible in the input_schema shown. Enums and ranges must be in the schema, not just descriptions.
shop_get_audit_trail limit parameter lacks range documentation. Description says '1-100, default 20' but schema does not enforce minimum/maximum. LLMs may pass invalid values.