Loading ToolBench
A plant shop MCP server with product catalog, shopping cart, checkout, and payment processing via Gr4vy
Plantly has 9 tools with complete input schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (list_products, create_purchase, generate_token). Descriptions are present but often verbose and include UI-specific instructions that don't belong in tool docs. Parameters have types and descriptions, but lack constraints (enums, ranges, patterns). Output schemas are not documented. Error handling is minimal, no recovery guidance or categorization. Security is reasonable (OAuth, no secrets in params), but audit logging is absent. Composition is reasonable: tools chain logically (generate_token → verify_token → create_purchase), but some tools conflate concerns (process_payment does too much).
Create a Gr4vy buyer and return the buyer ID.
Create a transaction via Gr4vy using a verified payment token.
Generate a Gr4vy Embed token for client-side checkout.
Generate a one-time payment token for a card and trigger mock 2FA. Returns a token ID and a mock 2FA code (in production, this would be sent via SMS/email — here we return it directly for demo purposes).
Return cards for a user with sensitive fields stripped.
List available Plantly products and show the interactive catalog. The UI widget handles all display — do NOT repeat product names, prices, or descriptions in your response. Just present the widget silently.
Descriptions contain UI/widget instructions ('The UI widget handles all display, do NOT repeat...') that belong in agent prompts, not tool definitions. This pollutes the tool contract and wastes tokens.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., what does generate_token return? token_id? 2fa_code? both?). Breaks tool chaining.
process_payment conflates multiple concerns: email validation, card lookup, payment processing, and order creation. Should split into separate tools (validate_email, charge_card, create_order) so agents can compose them.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
Process payment in a single step (used by checkout widget).
Show the shopping cart with the given items. The UI widget handles all display — do NOT repeat item names, quantities, or totals in your response. Just present the widget silently.
Verify the 2FA code for a payment token.
No enum constraints on string parameters. 'currency' accepts any string (should be ISO 4217 enum: USD, EUR, GBP, etc.). 'category' in list_products has no enum despite mentioning 'Top Rated, Essentials, Accessories'.
Error handling is absent. No recovery guidance, no categorization (retryable vs fatal), no actionable error messages. If verify_token fails, the LLM has no guidance on what to do next.