Loading ToolBench
ShasthoMCP defines 16 tools for a Bangladeshi doctor directory with consistent verb-noun naming (search_, find_, get_, list_). All tools have descriptions and input schemas are present for parameterized tools. However, there are systematic quality gaps: (1) Output schemas are not documented anywhere in the code, responses are converted to text via `{ type: 'text', text: c.text }` without specifying what fields agents should expect, violating the pattern:tool and pattern:response-shaper requirements. (2) Parameter descriptions are present but generic, many lack specificity about constraints, formats, or valid ranges (e.g., 'limit' has no min/max bounds specified; 'query' has no length or character restrictions). (3) Error handling is absent, no evidence of try-catch, validation, or recovery guidance in the handlers. (4) Several tools accept user-facing strings (specialty, division, hospital_name) but no guidance on case sensitivity, partial match behavior, or what happens if a value does not match. (5) The tool set shows redundancy: find_doctors_by_specialty, find_doctors_by_location, find_doctors_by_hospital, find_doctors_available_today, find_doctors_by_symptoms, find_doctors_by_fee, find_doctors_by_insurance, and get_top_rated_doctors all search for doctors with different filters, composition could be improved with a single parameterized search tool. Overall naming is solid (verb-noun convention), descriptions exist, but schema rigor, output documentation, and error handling are weak.
Find doctors who are available today (based on current day of week).
Find doctors within a specific consultation fee range.
Find all doctors who practice at a specific hospital or clinic.
Find doctors who accept a specific health insurance provider.
Find doctors available in a specific division or district of Bangladesh.
Find doctors by their medical specialty (e.g., Cardiology, Neurology, Gynecology). Optionally filter by division.
Find doctors based on symptoms or health conditions. Describe your symptoms and get matched with appropriate specialists. Works with both English and Bengali.
Output schemas are completely undocumented. All tools return responses converted to text via `{ type: 'text', text: c.text }` with no schema documentation for what fields the LLM should expect. This violates pattern:response-shaper and pattern:tool requirements. LLMs cannot plan downstream calls or extract structured data without knowing the response structure.
Parameter constraints are missing or incomplete. Parameters like 'limit' and 'offset' lack min/max bounds (rubric baseline: numeric params must have ranges). 'query', 'specialty', 'division', 'hospital_name' lack guidance on case sensitivity, partial match behavior, max length, or what to do if no match exists.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Find hospitals with 24/7 emergency services. Use this for urgent medical needs or to find nearby emergency facilities.
Get the complete weekly chamber schedule for a specific doctor, including all hospitals and timings.
Get complete details of a doctor including their chamber schedules, qualifications, insurance networks, and contact information.
Get the top-rated doctors in a specific specialty, optionally filtered by division.
List all divisions and districts of Bangladesh covered in the directory.
List hospitals and clinics. Can filter by division and type.
List all health insurance providers supported in the directory.
List all available medical specialties in the directory.
Search doctors by name (English or Bengali). Use this to find a specific doctor.
No error handling or validation visible in handlers. The codebase references `handleToolCall()` in src/tools/handlers.js but that file is not shown. No try-catch, validation, or recovery guidance is evident. Agents have no way to know which errors are retryable or how to self-correct.
Tool set shows significant redundancy and poor composition. Eight tools search for doctors with different filters (find_doctors_by_specialty, find_doctors_by_location, find_doctors_by_hospital, find_doctors_available_today, find_doctors_by_symptoms, find_doctors_by_fee, find_doctors_by_insurance, get_top_rated_doctors). This violates pattern:tool (each tool should do one thing) and wastes LLM reasoning cycles deciding between similar tools. A single parameterized search_doctors_advanced() with optional filters would reduce cognitive load and improve composability.
No documentation of return type structures. Even the discovery tools (list_specialties, list_divisions, list_hospitals, list_insurance_providers) do not specify what fields they return (e.g., does list_specialties return [{ name, id, count }] or just [name] strings?). Agents cannot chain results without guessing the structure.
Parameter descriptions lack depth and actionable guidance. For example, find_doctors_by_symptoms accepts 'symptoms' as a free-form string but does not specify if it supports Bengali, what happens if a symptom does not match known conditions, or how specialty matching works internally. Pattern:tool-description requires WHAT, WHEN, and prerequisites.
Result limits are mentioned in some descriptions but not enforced or documented consistently. search_doctors says 'max: 100' but many other tools silently cap at 20 with no explanation of why or what happens if the LLM requests more.
No pagination documentation in API responses. Tools accept 'limit' and 'offset' (e.g., search_doctors) but do not specify whether results include a total_count or next_cursor for the agent to know if more results exist. Pattern:paginated-result requires explicit pagination support.