Loading ToolBench
A .NET-based MCP server implementing tool proxy functionality with Azure Search integration, supporting both Supermarket and ThirdApi plugins with REST API and MCP console modes
This MCP server has 15 tools with significant definition quality issues. While most tools have descriptions (13/15), they vary widely in clarity and completeness. Critical problems: (1) Tool names lack consistency, some start with verbs (Get*, Find*, Search*) but many are generic or vague; (2) Input schemas are present but many lack parameter descriptions, 7 tools have empty input objects with no schema documentation; (3) Output schemas are not documented anywhere in the provided code; (4) Descriptions, while present, are often verbose (some exceed 200 chars, violating the 10-1024 guideline) and read more like user help text than LLM-optimized tool selection guides; (5) No error recovery guidance is visible, tools do not indicate what the agent should do if they fail. The server shows basic tool registration infrastructure but falls short of production-grade definition quality. Most tools score in the 30-50 range individually, pulling the overall average down.
Find article by content key (automatically zero-padded to 18 digits) from ThirdApi Pump collection
Search, find, show, get, list, display, or retrieve articles by name. Shows all articles that contain a specific text, word, or string in their name (case-insensitive partial match). Use this when user asks to find articles, show articles, get articles, list articles, search articles, or display articles that contain any text in their name like 'cola', 'pepsi', 'water', 'masti', 'coca cola', etc. Works with any search term or product name.
Show articles with ingredients. Retrieves all articles (BaseItemDO) that have ingredient information (INGR or IN text classes). Returns article content key, name, text class, language, and concatenated ingredient text. Use this when user asks about ingredients, article ingredients, product ingredients, or wants to see what ingredients articles contain.
Get content types summary from latest processing statistics
Get daily sales summary with transactions and revenue data (today by default)
7 tools have empty input schemas ({}), providing zero guidance on what parameters they accept or how to use them. Tools like GetPricesWithoutBaseItem, GetLatestStatistics, GetContentTypesSummary, GetPluData, GetProducts, GetInventoryStatus, and GetDetailedInventory all expose no input schema.
No tool descriptions document output schema. LLMs cannot plan downstream operations or extract relevant fields if they don't know what a tool returns. The code shows tool execution but nowhere does it specify the return structure (fields, types, sample) for any of the 15 tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Get detailed inventory information with product details, stock levels, pricing, and reorder points
Get real-time inventory status with stock levels and recent sales data
Get latest processing statistics from ThirdApi Summary collection
Get products with low stock levels
Get PLU data from SAP Fiori (DynamicTableauItemListDO). Returns PLU codes, group information, and sequence numbers sorted by content key and sequence. Used for POS item lists, product groups, and SAP Fiori integration.
Get prices without base items from ThirdApi Pump collection
Get all products in the supermarket inventory
Get sales performance by product category for a date range
Get sales data for a specific date range
Get total revenue for a specific date range
Tool descriptions are verbose and user-facing rather than LLM-optimized for tool selection. Examples: 'Show articles with ingredients. Retrieves all articles...' (148 chars) reads like help text. Best practice: 10-100 chars stating WHAT + WHEN. Long descriptions waste tokens and bury the selection signal.
Tools with required parameters lack clear descriptions of valid values and constraints. Example: FindArticlesByName expects 'name' (case-insensitive partial match), good. But FindArticleByContentKey expects 'contentKey' with auto zero-padding, this constraint is buried in description, not in schema. No min/max length, no pattern validation visible.
No error recovery guidance. The ToolProxyController code shows try-catch blocks returning generic errors ('Invalid arguments for tool', error 500) with no guidance on next steps. Per pattern:recovery-guide, errors must state: 'User not found. Try search_users() with a partial name.' Currently, an LLM receiving a 500 error has no actionable recovery path.
Tool naming lacks consistency. Mix of Get*/Find*/Search* conventions without clear distinction. Example: GetProducts (list all?) vs GetSalesData (query by date range?), the names alone don't signal difference in scope. Per naming baseline, 90% of A+ tools start with an action verb, but here verb_noun consistency is weak.
Parameter types are declared in schema but lack LLM-facing constraints in descriptions. Example: GetSalesData/GetTotalRevenue/GetSalesByCategory expect 'YYYY-MM-DD' format but the description says 'in YYYY-MM-DD format', no enum, no pattern, no min/max length.
No pagination support visible. Tools like GetProducts, GetArticlesWithIngredients, GetSalesByCategory likely return lists but no limit, offset, or cursor parameters are declared. Per pattern:paginated-result, large lists without pagination blow context windows.