Loading ToolBench
MCP server for managing FHIR Condition resources with thread-safe ingestion, live querying, and user correction workflow
This server demonstrates solid fundamentals with three well-structured tools covering a medical records domain. All tools have clear descriptions and proper input schemas with type definitions. However, there are notable gaps in parameter descriptions, output schema documentation, and error handling guidance. The naming is action-oriented and appropriate. Parameter descriptions vary in quality, some are detailed while others are minimal. Output structures are documented in docstrings but not formally in the schema. The server would benefit from more complete parameter documentation and explicit error handling patterns.
Retract all conditions matching a concept from the live store. Use this when the user says they do not have a condition, or that a record was entered in error.
Search the live conditions store. Designed for RAG use: returns immediately with the best available data, even if background ingestion is still running. Check `partial` in the response to know whether all data has been loaded.
Return ingestion progress and data quality summary.
Parameter descriptions lack actionable constraint details. Parameters like 'text', 'concept', 'limit', and 'active_only' have basic descriptions but omit specifics about ranges, formats, or validation rules that would guide LLM usage.
Output schemas are documented in docstrings (Return sections) but not formally specified in the MCP tool registration. The tool responses include complex nested structures (e.g., ingestion_log array with multiple fields) that are not schema-validated.
Error handling is absent. There is no guidance on what errors might occur (e.g., invalid concept format, retraction failures, ingestion timeouts) or what the LLM should do if a tool call fails. Errors are not categorized as retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
store_status() has an empty input schema (properties: {}). While this is technically valid for zero-parameter tools, the description is vague ('Return ingestion progress and data quality summary') and does not explain when or why to call it relative to other tools.
Parameter 'limit' in query_conditions lacks specified bounds. The description says 'default 20' but does not state minimum/maximum values, allowing LLMs to potentially pass absurd values.
Parameter 'concept' in correct_condition accepts 'Name or code' but does not formally define valid code formats (SNOMED vs ICD-10) or parsing precedence. The examples in the description should be replaced with enum-like constraints or explicit format rules.