Loading ToolBench
This server exhibits severe quality deficiencies across all definition quality dimensions. All three tools (get_students, get_courses, get_tables) lack any descriptions whatsoever, violating the foundational pattern:tool-description requirement. Input schemas are empty objects with no parameter definitions, type information, or constraints. Output schemas are completely undocumented, callers cannot know what fields to expect from the SQLite results. Error handling is absent; failures (database connection errors, missing tables, etc.) will surface as unhandled exceptions rather than actionable recovery guidance. No input validation, no pagination support despite returning potentially large result sets, no field documentation. The tools are minimal stubs that expose raw SQLite query results without any abstraction, normalization, or LLM-friendly transformation. Database file path is hardcoded to a Windows-specific absolute path (H:\MCP-Servers\adv-university.db), making the server non-portable and exposing internal infrastructure details.
All tools lack descriptions entirely. Per pattern:tool-description, every tool must have a non-empty description explaining WHAT it does, WHEN to use it, and any prerequisites. LLMs cannot determine when or why to select tools without descriptions.
All tools define empty input schemas (Input: {}). Per pattern:constrained-input, even parameterless tools should have explicit, documented schemas. Tools returning potentially large result sets must accept pagination parameters (limit, offset/cursor) to prevent context window exhaustion.
No output schemas documented for any tool. Per pattern:tool and pattern:response-shaper, LLMs need to know what fields to expect (column names, data types, structure) to plan downstream operations and extract relevant data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
No error handling or recovery guidance. Database connection failures, missing tables, SQL errors, or constraint violations will surface as unhandled exceptions. Per pattern:recovery-guide, error responses must tell the LLM what to do next with actionable guidance.
Raw SQLite result tuples returned without normalization or field mapping. Callers receive tuple-of-tuples with no context about column names, types, or meaning. Per pattern:response-shaper and mxe:strip-api-responses, responses should be structured objects with typed, self-documenting fields.
Hardcoded absolute Windows file path (H:\MCP-Servers\adv-university.db) in source code. Per pattern:secret-injection and security best practices, configuration should come from environment variables or config files, not hardcoded paths. This breaks portability and exposes internal infrastructure.
No pagination support despite tools returning potentially unbounded result sets. Per pattern:paginated-result, tools must accept limit/offset parameters and return total counts or cursors. Returning all rows can exhaust context windows and degrade LLM reasoning.
No input validation. Tools accept no parameters but lack defensive checks for database availability, table existence, or schema assumptions. Per review:param-validation-rules, tools should validate early and return clear error messages.