Loading ToolBench
A Spring Boot-based MCP (Model Context Protocol) server and client demonstrating hospital appointment management with doctor and patient data integration
The server defines 2 tools with explicit schemas and descriptions, but quality is inconsistent. Both tools have action-verb names (create_, delete_) and non-empty descriptions. However, descriptions are terse (32-58 chars, below the 50-200 char optimum for LLM selection), parameter descriptions are minimal or missing intent/context, and critical metadata is absent. The schema structure is present (type declarations visible for input parameters), but lacks output schema documentation. Error handling guidance is not visible. No evidence of security patterns (permission gating, audit logging, secret injection). No input validation constraints (e.g., enums for status fields, limits on numeric ranges). Overall, definitions are functional but underscore the gap between 'exists' and 'production-grade.'
Creates an appointment based on the given doctor id, patient id and date/time of the appointment.
Deletes an appointment based on the given appointment id.
Descriptions are below LLM-optimized length. 'Creates an appointment...' (32 chars) and 'Deletes an appointment...' (32 chars) lack context on WHEN to call these tools, WHAT happens on success, and any prerequisites or side effects. LLMs rely on 50 - 200 char descriptions to decide tool selection.
Parameter descriptions are missing or insufficient. 'doctorId', 'patientId', 'appointmentTime', 'appointmentId' have brief type notes but no context on format, range, constraints, or what happens if invalid. E.g., appointmentTime says 'time and date...in format YYYY-MM-DDThh:mm' but no description of timezone, whether past appointments are allowed, or behavior on scheduling conflict.
No output schema documentation. Neither tool documents what fields are returned on success (e.g., appointment_id, confirmation_code, created_at). Without output specs, LLMs cannot plan downstream calls or extract confirmation data. This blocks tool chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
No error handling guidance. No visibility into how the server responds to conflicts (double-booking), invalid IDs, timezone issues, or permission failures. LLMs have no recovery path if a call fails.
Destructive tool (delete_appointment) lacks confirmation or dry-run capability. Agents make mistakes, a confirmation-before-execute pattern would prevent accidental appointment deletions.
No input validation hints. Parameters accept raw values without visible constraints (enums, min/max, regex). E.g., doctorId and patientId are long integers with no indication of valid range or what happens if they reference non-existent entities.
Missing dependency hints. No guidance on whether agents must call a discovery tool (e.g., list_doctors, list_patients) before invoking create_appointment. This forces extra round-trips if IDs are not already known.
No tool composition hints. The server provides only create and delete, no list, search, or update tools. This limits agent autonomy and forces reliance on external systems to discover appointments or make changes.