Loading ToolBench
MCP server for Al Salam Hospital providing doctor search, biography lookup, appointment scheduling, and patient verification functionality
This server has significant definition quality gaps. Of the 6 tools, 5 have reasonable descriptions (50 - 90 chars each), but critical issues emerge in schema completeness, parameter constraints, output documentation, and error handling. Most tools lack enum constraints for free-form string parameters, have minimal error recovery guidance, and omit output schemas entirely. The tool naming is adequate (verb_noun style), but several parameters accept loosely-typed inputs (e.g., branchId, clinicId as bare strings with no format guidance). The server prioritizes basic API pass-through over LLM-optimized tool design, responses are raw JSON dumps from the backend, not structured for agent consumption. Per-tool analysis reveals: search_individual and get_doctor_bio have decent descriptions but no output schema documentation; get_doc_next_availble_slot has a confusing parameter name (typo: 'availble' not 'available') and loose scheduling logic; check_patient_whatsapp and generate_otp lack comprehensive error handling; select_doctor_from_list is the most complex but also the most error-prone, relying on agents to pass entire search result arrays without pagination or result limits. No tool declares required permissions, implements idempotency hints, or provides recovery guidance for common failures.
Check if a patient exists and has multiple profiles by mobile number
Generate OTP for existing patient verification
Get the next available slot for a doctor
Get detailed biography and specialization information for a specific doctor. Use this ONLY when the user explicitly asks for more information about a doctor after searching.
Search for a doctor by name or specialty
Select a specific doctor from multiple search results and get their available days
Tool naming contains typo: 'get_doc_next_availble_slot' should be 'get_doc_next_available_slot'. Typos in tool names degrade discoverability and confuse LLM parsing.
No output schemas documented for any tool. All tools return raw JSON from the backend API without stating field names, types, or required fields. LLMs cannot reliably extract data or plan downstream calls without knowing response structure.
Parameters accept unconstrained strings where enums are needed. Examples: lang parameter in search_individual accepts 'A' (default) and others but no explicit enum; scheduleDaysOnly accepts '0' or '1' as strings without enum constraint; mobileAppWhatsapp accepts '2' and others as strings with no specification of valid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
select_doctor_from_list expects agents to pass entire search result arrays as parameters. No pagination support, no limit on result size. Agents could inadvertently pass hundreds of doctors, bloating the request and wasting tokens. Risk of timeout or request rejection.
Error handling is minimal. All tools catch exceptions and return 'Error: <message>' in plain text. No error classification (retryable vs user-fixable vs fatal), no recovery guidance, no actionable hints. Agents cannot distinguish transient failures from real problems.
Parameter descriptions lack format constraints and examples. branchId, clinicId, docId, hospitalId are bare strings with no guidance on format (numeric vs alphanumeric? length?). webFromDate is described as 'DD/MM/YYYY format' in text but no regex or formal constraint in schema.
No tool declares permissions or security scope (e.g., 'read:doctor', 'write:appointment'). Unclear which tools are read-only vs write, or what authority is required. Risk flag is present (READ_ONLY, WRITE) in metadata but not exposed to LLM as annotations.
generate_otp is marked WRITE but lacks confirmation/dry-run pattern. Agents could accidentally trigger OTP generation on wrong phone numbers. No idempotency guarantee, calling twice generates two OTPs, potentially confusing users or locking them out.
select_doctor_from_list relies on 1-based indexing and validates bounds at runtime, returning a JSON error. Should validate index type in schema and provide structured error responses. Current error message is helpful but inconsistent with other error handling patterns.