Loading ToolBench
MCP server for querying and updating a PostgreSQL database with student academic information
This server has 2 tools with reasonable naming but significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool names follow verb_noun convention appropriately (search_database, update_person), but parameter descriptions are present but sparse. Critically, output schemas are not documented, LLMs must infer the structure of returned data. Error handling exists but lacks actionable recovery guidance. The server is functional but falls short of production-grade quality.
Search the student academic database by name, email, or major. Returns student ID, GPA, major, and enrollment details
Updates specific fields for a person record based on their unique email address.
Output schemas not documented. Both tools return text-formatted responses, but the LLM has no declared structure. LLMs must infer field names and types from free-text output, risking parsing errors and wasted tokens.
Destructive operations (update_person) lack confirmation step or dry-run support. Agents can accidentally overwrite person records without safeguards. No explicit statement that this tool mutates state.
Error handling provides generic messages without recovery guidance. 'Database error: <message>' or 'No person found' tells the LLM what went wrong but not what to try next. Missing pattern:recovery-guide.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No pagination metadata returned by search_database. Tool caps results at LIMIT 5 but does not return total count, next_cursor, or has_more flag. Agents cannot determine if results are complete or partial.
Parameter descriptions are present but lack actionable constraints. 'The search term' does not specify max length, character restrictions, or multi-word behavior. GPA constraint (0.00 - 4.00) is in description but not enforced in schema type hints.
Tool names lack specificity about resource type. 'search_database' could apply to any database; 'search_academic_database' or 'search_students' is clearer. 'update_person' does not indicate this updates academic records specifically.
search_database returns unstructured text (ID: X | Email: Y | Salary: Z | GPA: W). Salary field is mentioned in the description as part of returned data but not listed in the tool description. Free-text response requires the LLM to parse and extract, wasting tokens and risking parse errors.
update_person does not document failure modes. If the UPDATE fails (e.g., unique constraint, invalid GPA range), the error message is generic. No guidance on whether to retry, adjust input, or check prerequisites.