Loading ToolBench
MCP server for querying verified producers from Supabase database by various criteria (Aadhaar, name, FSSAI, PIN)
This server exhibits mediocre definition quality with a mix of acceptable naming and schema presence, offset by weak descriptions and no output schema documentation. All 5 tools are explicitly registered in mcp_server.py with names, descriptions, and input schemas. However, descriptions are consistently generic (all under 100 chars, most around 50 chars), leaving LLMs without actionable context for tool selection. Parameter descriptions exist but are minimal ('The Aadhaar number of the producer'). No tool includes output schema documentation, error recovery guidance, or constraints on valid inputs. Tools lack annotations (readOnlyHint, destructiveHint, idempotentHint) despite being read-only queries. The server does not implement pagination, result limits, or structured error responses, all tools return raw JSON strings wrapped in TextContent, forcing LLMs to parse unstructured text. Baseline production tools average 194 chars in description; these average ~60 chars. This server lands firmly in the C/D range (poor/fair): definitions are present but underspecified.
Get all verified producers
Get verified producer information by FSSAI license number
Get verified producer information by PIN
Get verified producer information by Aadhaar number
Search for verified producers by name
All tool descriptions are under 100 characters and lack LLM-optimized context. Descriptions like 'Get verified producer information by Aadhaar number' do not explain WHEN to use this tool vs. others, what fields are returned, or what data model expectations exist. Production baseline is 194 chars; these average ~60 chars.
No output schema is documented for any tool. LLMs cannot determine what fields to expect from responses, making it impossible to plan downstream tool calls or extract required data for chaining. Tools return raw JSON strings, forcing LLMs to parse unstructured text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
No pagination, result limits, or count fields implemented. get_all_verified_producers has no limit parameter and returns all records as a JSON string; this will exhaust context windows and degrade LLM reasoning if result sets are large. Production baseline enforces 20-50 item limits and offers pagination.
Error handling returns generic exception messages ('Error: {str(e)}') with no recovery guidance. LLMs cannot determine if an error is retryable, user-fixable, or fatal. Missing error classification and actionable suggestions.
Parameter descriptions are minimal (10-20 chars). 'The Aadhaar number of the producer' leaves LLMs without format guidance, length constraints, or usage context. Production baseline is 72 chars per parameter. No parameter describes expected format, validation rules, or error handling.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only queries. Annotations guide agent reasoning about side effects and retry safety. All 5 tools should be marked as read-only and idempotent.
Tools return unstructured JSON wrapped in TextContent; LLMs must parse raw JSON strings instead of receiving structured, typed responses. Production tools return proper response objects with documented schema. This increases token cost and parsing errors.
get_all_verified_producers accepts no parameters and will return all producers as a single JSON string. For large datasets, this explodes context window. No field for total count, next_cursor, or pagination support.