Loading ToolBench
MCP server for managing healthcare appointments, specialists, services, and client bookings via a Django REST API backend
The server defines 6 tools with basic descriptions and input schemas, but has significant gaps in parameter documentation, output schema specification, and error handling guidance. Tool naming follows verb_noun convention (search_, create_, cancel_, confirm_, complete_, get_), which is positive. However, descriptions lack actionable detail on when/why to use each tool, parameter descriptions are minimal, output schemas are not formally documented, and there is no structured error handling or recovery guidance. The server exposes an internal API token in plaintext, violating security best practices. Parameter validation is weak, no enums for constrained fields, no format validation, no min/max bounds. Composition is reasonable (6 focused tools), but chaining metadata (IDs needed for follow-up calls) is not fully documented in responses.
Отменить запись на приём
Отметить запись на приём как завершенную
Подтвердить запись на приём
Создать запись на приём к специалисту
Получить доступные слоты для записи к специалисту на определенную дату
Поиск специалистов (врачей) по заданным критериям
AUTH_TOKEN hardcoded in plaintext in mcp_server.py. Credentials must never appear as tool parameters or server initialization code, use environment variables or secret injection.
Output schemas are not documented. Tools return dict or list with no schema specification. LLMs cannot infer which fields to expect, forcing them to guess at downstream tool inputs and blocking multi-step tool chains.
Parameter descriptions are minimal or missing context. 'ID специалиста', 'Дата приёма в формате YYYY-MM-DD' state the type but not when/why to use the parameter or what it controls. Descriptions lack LLM-actionable guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No structured error handling or recovery guidance. API errors are not caught or translated to actionable messages for LLMs. A failed appointment creation returns a raw API error with no guidance on what went wrong or what to try next.
No input validation or constraint documentation. status parameter defaults to 'pending' but no validation that inputs match expected formats. No enums for constrained fields like status, no min/max for numeric IDs, no regex patterns for dates.
Tool descriptions lack context on when/why to select each tool instead of a similar one. 'Подтвердить запись' (Confirm appointment) vs 'Создать запись' (Create appointment), when should an LLM call confirm vs create? No dependency hints provided.
get_available_slots defaults date to current date if not provided, but this behavior is not obvious from the description. LLMs may not understand that omitting 'date' uses today, leading to accidental past-date queries.
No confirmation step or dry-run for destructive operations (cancel_appointment, complete_appointment). Agents can accidentally cancel a valid appointment with no rollback option. Consider a confirm_before_execute pattern.
Response fields from create_appointment and others are not explicitly listed. If create_appointment returns {id, status, date, start_time, ...}, downstream tools need to know which fields are present to extract appointment_id for follow-up calls. Chaining breaks without documented field names.