Loading ToolBench
MCP server exposing a clinical decision support pipeline as tools and resources. Enables MCP-compatible clients (Claude Desktop, VS Code Copilot, etc.) to invoke clinical analysis directly. Supports both blocking and async submit/poll patterns for patient case analysis.
Four tools with complete schemas and descriptions. Naming follows verb_noun pattern (analyze_, submit_, check_, get_). Descriptions are detailed (100-250 chars) and explain WHEN to use each tool. However, parameter descriptions lack specificity on constraints (e.g., minimum patient_text length stated as '10 characters' but not enforced in schema). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent: no guidance on retryability, timeouts, or recovery paths. Tool composition is sound (blocking vs async patterns clearly separated), but missing pagination/limits on list operations and no tool annotations (readOnlyHint, destructiveHint).
Run the full CDS pipeline on a patient case and return the complete report. This is a BLOCKING call — it runs all 6 pipeline steps sequentially and returns the final Clinical Decision Support report. Typical runtime is 30-90 seconds depending on endpoint load. Use this when you want to wait for the complete result in a single call. For long cases, consider using submit_case + check_case_status instead.
Check the progress of a previously submitted case. Returns the current pipeline status including which step is running, how many steps are complete, and elapsed time. Call this periodically (every 5-10 seconds) after submit_case until status is 'completed'.
Retrieve the final CDS report for a completed case. Call this after check_case_status shows status 'completed'. If the pipeline is still running, returns the current progress instead.
Submit a patient case for asynchronous analysis. Returns immediately with a case_id — use check_case_status to poll progress and get_case_result to retrieve the final report. Use this pattern instead of analyze_patient_case when you want to show the user progress updates as each step completes, you're worried about timeout on the blocking call, or you want to submit multiple cases in quick succession.
Output schemas not documented. LLMs cannot predict CDSReport structure, pagination fields, or error response format. Forces agents to guess field names and risk extraction failures.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot determine which tools are safe to retry or have side effects. submit_case is WRITE but unmarked; analyze_patient_case is READ_ONLY but unmarked.
No error handling guidance. Descriptions mention '30-90 seconds' and 'timeout' but no tool documents what happens on timeout, network failure, or invalid case_id. No recovery hints (e.g., 'retry after 5 seconds' or 'case expired after 10 minutes').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Parameter constraints not enforced in schema. 'patient_text' requires 'minimum 10 characters' per description but JSON Schema has no minLength. 'format' enum in get_case_result ('report' vs 'cds_hooks') not declared as enum in schema.
No pagination or result limits documented. If guidelines list returns 62 items, no indication of max results, pagination tokens, or offset/limit parameters. Large unstructured responses risk context window exhaustion.