Loading ToolBench
Multi-service MCP server suite for Azure Blob Storage, Cosmos DB, and SQL Server data access with product search and document management capabilities
Server has 16 tools across Python and C# implementations with basic schemas and descriptions. However, critical gaps undermine quality: (1) Descriptions are minimal (10-50 chars), well below the 194-char baseline for A+ tools. (2) Parameter descriptions exist but lack actionable constraints (no enums, ranges, or format guidance). (3) Output schemas are not documented, LLMs cannot predict response structure for chaining. (4) No error handling guidance; tools will fail silently. (5) Naming is inconsistent: Python uses snake_case (list_documents, read_document) while C# uses PascalCase (ListDocuments, ReadDocument), forcing LLMs to learn two conventions. (6) No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. (7) SQL tools (query_data, QueryData) accept free-form SQL with no injection guards documented. This is a functional but immature implementation.
Download one blob document as a base64 payload with metadata.
Download filtered product documents as a JSON file payload (base64).
Find products by optional text/category/price filters.
Get one product by id.
List documents in the Azure Blob container.
List columns for a table so agents can build safe filters.
List user tables for a schema.
Run a read-only SQL query and return rows as JSON-like objects.
Inconsistent naming convention across implementations: Python uses snake_case (list_documents, read_document) while C# uses PascalCase (ListDocuments, ReadDocument). LLMs must learn two naming patterns for the same logical tools, increasing confusion and tool selection errors.
Descriptions are critically short (10-50 chars, well below 194-char baseline). Examples: 'List documents in the Azure Blob container.' (47 chars) lacks context on when to use it vs DownloadDocument. 'Run a read-only SQL query and return rows as JSON objects.' (59 chars) omits injection safeguards or query format constraints. LLMs cannot distinguish similar tools or understand prerequisites.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Query any table with optional equality filters. Use ListTableColumns first to discover valid columns.
Read one blob document; returns text if UTF-8 decodable, otherwise base64 content.
Find products by optional text/category/price filters.
Get one product by id.
List documents in the Azure Blob container.
List user tables for a schema.
Run a read-only SQL query and return rows as JSON objects.
Read one blob document; returns text if decodable, else base64 content.
Output schemas are not documented. Tools return structured objects (e.g., ReadDocument returns {blob_name, content_type, encoding, truncated, content, size_bytes}) but LLMs have no schema to predict response fields for chaining. This forces agents to guess field names and risks broken downstream calls.
SQL tools (query_data, QueryData) accept free-form SQL with no documented injection safeguards. Description states 'Read-only SQL query (SELECT/CTE)' but does not explain validation, parameterization, or what happens if an LLM passes UPDATE/DELETE. No error guidance if malicious SQL is detected.
No tool annotations despite all 16 tools being read-only. Missing readOnlyHint metadata prevents clients from optimizing caching, retry logic, and safety checks. Agents cannot distinguish safe tools from destructive ones without explicit hints.