Loading ToolBench
Production-ready Medical MCP toolkit with HTTP API + SSE/STDIO, optional Postgres backend.
Medical-MCP toolkit has 12 tools with reasonable naming conventions (all verb-prefixed: get*, calc*, search*, triage*, schedule*). However, critical gaps exist in schema documentation, parameter descriptions, and output structure definition. Tools are READ_ONLY or WRITE risk-classified, which is good for security classification, but implementation details for input validation, error handling, and output schemas are not visible in the provided source. Schema definitions for tools appear incomplete, while parameter types are declared (string, integer, number, array, object), there is no visible documentation of OUTPUT schemas or field definitions that downstream tools might depend on. Several tools (especially clinical decision tools like triageSymptoms, getDrugInteractions, getDrugContraindications) lack depth in parameter constraints (e.g., no enum for 'sex', no format spec for 'datetime_iso'). Tool descriptions are present but generic, they state WHAT but lack WHEN and WHY context. No visible evidence of error handling patterns, recovery guidance, or field naming consistency across tool chains.
Calculate clinical scores including BMI, BSA, creatinine clearance, and eGFR
Suggest alternative drugs for a given drug
Identify contraindications for a drug based on patient medical profile and allergies
Retrieve detailed drug information including indications, dosage, and adverse effects
Check for drug-drug interactions between a list of drugs
Retrieve patient demographics (ID, name, age, sex)
Output schemas not documented. Tools return data but the shape, field names, and structure are not declared. Downstream tools (e.g., getDrugContraindications consuming medical profile from getPatientMedicalProfile) cannot reliably chain without inference.
Parameter constraints missing or underspecified. Sex parameter accepts 'string' with no enum constraint (should be 'male'|'female'|'other' or similar). datetime_iso format is described as 'ISO 8601' but not validated. Serum_creatinine_mg_dl lacks min/max bounds.
Tool descriptions are generic and lack WHEN/WHY guidance. Example: 'Retrieve patient demographics' does not explain when to call this instead of getPatient360, or whether it includes current medications. Descriptions are typically 40-100 chars, below the baseline 194 for A+ tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Retrieve comprehensive patient view including demographics, vitals, and medical profile
Retrieve patient medical profile including conditions, allergies, and current medications
Retrieve patient vital signs (heart rate, blood pressure, respiratory rate, temperature, SpO2)
Schedule a medical appointment for a patient
Search medical knowledge base for clinical guidelines and evidence-based information
Perform AI-assisted clinical triage based on patient symptoms, age, and sex to determine acuity level and recommended next steps
No visible error handling patterns or recovery guidance. Tools declare READ_ONLY or WRITE risk but do not document error conditions (patient not found, invalid drug name, appointment conflict). LLMs have no guidance on what to do if a call fails.
No pagination or result limits declared. searchMedicalKB accepts 'limit' parameter but no documented max or default. Large result sets will inflate token usage and degrade LLM reasoning.
Tool composition unclear. getPatient vs getPatient360: overlapping scope. triageSymptoms and searchMedicalKB both provide clinical guidance but parameters and use cases not distinguished. Risk of LLM selecting wrong tool.
getDrugContraindications accepts 'profile' as free-form object with no documented structure. Should specify required fields (allergies, conditions, age, sex, current_medications) or reference getPatientMedicalProfile output schema.