Loading ToolBench
An MCP server that provides tools to list and retrieve products from a PostgreSQL-backed product catalog database
The Product Catalog MCP Server presents a minimal implementation with two tools. Both tools have basic descriptions but lack parameter documentation, output schema documentation, and any error handling guidance. The tools themselves are well-named (list_products, get_product) and follow verb_noun convention, but the implementation is incomplete against production baselines. No pagination is implemented despite list_products potentially returning unbounded results. Error handling in get_product returns a dict with an 'error' key rather than a structured error response that would guide the LLM. The schema score is penalized because while parameter types are present in the function signature, there is NO explicit output schema documentation in the source code, only inferred dict returns. Parameter descriptions are completely absent. This server would not pass code review for a production agent toolkit.
Retrieve a single product by its ID
List all products from the database
No output schema documentation. Tools return dicts but there is no documented field structure, types, or return value contract visible in source code. LLMs cannot infer what fields to expect or plan downstream operations.
Parameter 'product_id' in get_product has a type (integer) in the schema but NO description explaining what it is, what range is valid, or how to obtain it. Pattern requires 100% of A+ tools to have parameter descriptions.
list_products lacks pagination (no limit, offset, or page parameters) and no result count cap. Returning all products without pagination will exceed context windows for large catalogs. Baseline pattern requires paginated-result with limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 6 | - | v1 |
Error handling in get_product returns dict with 'error' key instead of structured error response that guides LLM recovery. Pattern requires error responses to tell the agent what to do next (e.g. 'Product not found. Verify the product_id or call list_products() to see available products.').
Tool descriptions are minimal (under 100 chars) and lack context about WHEN to use each tool or what to do with results. Pattern requires descriptions to answer: What does it do? When should the LLM call it? What does it return?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While these tools are read-only, declaring them explicitly via annotations helps LLMs reason about safety and retry strategies per current MCP spec.