Loading ToolBench
A comprehensive FastAPI microservice for health-related operations with MCP (Model Context Protocol) integration for appointments, medical records, patients, doctors, and other healthcare features
The server defines 7 tools with reasonable descriptions and schemas, but has several systematic gaps that reduce production readiness. Tool naming follows verb_noun conventions (create_appointment, get_appointments, delete_appointment, etc.), which is good. Descriptions exist for all tools and are generally in the 50-100 character range, meeting the baseline. However, parameter descriptions lack detail about constraints, valid ranges, and format requirements. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear READ vs WRITE vs DESTRUCTIVE risk classifications. Error handling is basic, most tools rely on HTTP exceptions but lack recovery guidance. The update_appointment tool accepts many optional parameters without documenting mutual exclusivity or dependencies. Security considerations (password handling, patient data access control) are not exposed in tool descriptions. Output schemas are implicit in Pydantic models but not explicitly documented in MCP tool definitions.
Create a new appointment with patient and doctor verification
Delete an appointment by ID
Retrieve a specific appointment by ID
Retrieve a list of all appointments with pagination support
Authenticate user and return JWT access token
Register a new user with email and username
Update an existing appointment with partial or full data
Missing tool annotations despite clear risk classifications. The 'delete_appointment' tool is marked DESTRUCTIVE but lacks destructiveHint annotation; 'create_appointment' and 'register' lack idempotentHint flags; read-only tools lack readOnlyHint. Per Arcade pattern spec, tool annotations enable agents to reason about irreversibility and side effects.
Parameter descriptions lack constraint details. 'duration_minutes' (create_appointment) does not specify valid range (e.g., 15-480). 'reason' maxLength=500 is in schema but not in description text. 'limit' in get_appointments defaults to 100 but no documentation warns about context window impact.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Error handling does not guide recovery. Code throws HTTP 404 'Patient not found' or 'Appointment not found' without suggestions. Per pattern recovery-guide, errors should state: 'Appointment not found. Call get_appointments() to list available appointments.' No error codes or categorization (retryable vs user-fixable) are documented.
Password handling exposed as plain parameter in 'register' and 'login' tools. While typical for HTTP APIs, tool descriptions should note that passwords must be sent over HTTPS and should never appear in logs or debug output. Per pattern secret-injection, credentials should not be traced.
Missing permissions documentation. Tools query patient_id and doctor_id but do not declare permissions (e.g., 'read:patient_data', 'write:appointment'). Per pattern scope-declaration, each tool should state required permissions for least-privilege agent configuration.
Output schema not explicitly documented. Tools return Pydantic models (AppointmentResponse, etc.) but MCP tool definitions do not include explicit return type schemas. LLMs cannot plan downstream tool calls without knowing what fields are available.
Idempotency not addressed. 'create_appointment' does not prevent duplicate appointments if called twice with identical parameters. Per pattern idempotent-operation, agents retry on failures, non-idempotent tools risk duplicate side effects (double bookings).
No dry-run or confirmation pattern for destructive operations. 'delete_appointment' has no --dry-run flag or confirmation step. Per pattern confirmation-request, irreversible operations should support a safety checkpoint to prevent catastrophic agent errors.
Pagination 'limit' default of 100 may exceed reasonable LLM context. Per mxe:enforce-result-limits, even if the API allows 100+, results should cap at 20-50 for optimal agent reasoning. No mention of result count or next_cursor in get_appointments description.