Loading ToolBench
Healthcare-focused MCP server providing FDA drug information including shortages, recalls, labels, and adverse events
The server provides 8 well-named FDA drug information tools with reasonable descriptions and structured input schemas. All tools follow verb_noun naming conventions (search_*, get_*, analyze_*, batch_*) which is excellent. However, there are significant gaps: (1) No output schemas are documented, callers don't know what fields to expect, only that results exist. (2) Parameter descriptions lack detail on constraints, ranges, and formats. (3) Error handling guidance is absent, tools return mock data with generic messages like 'No X found for Y' but don't explain what to do if real queries fail. (4) No indication of idempotency, destructiveness, or confirmation patterns. (5) The 'identifier_type' enum in tools 5 and 6 contains four redundant values (openfda.generic_name, generic_name, etc.) without explanation of which to prefer. This is mid-tier work, names and basic schema structure are solid, but production readiness requires documented outputs, better parameter guidance, and error recovery paths.
Analyze FDA drug shortage patterns over time. Use when asked about 'shortage trends', 'historical patterns', 'shortage analysis over time', or 'trends for [drug]'.
Analyze multiple drugs in a single request (shortages and labels). Use when asked to compare multiple medications or analyze a drug list.
Get FDA prescribing information and drug labeling. Use when asked about 'prescribing info', 'FDA label', 'dosage forms', 'indications', or 'how is [drug] prescribed'.
Get combined medication overview (label + shortage status only). Use when asked for 'complete information', 'full profile', or 'everything about [drug]' but NOT for side effects or adverse events.
Search FDA adverse events and side effects. Use when asked about 'side effects', 'adverse events', 'reactions', 'safety concerns', or 'what are the side effects of [drug]'.
No output schemas documented for any tool. Callers cannot infer response structure, field types, or available data. This forces LLMs to guess and makes chaining between tools error-prone.
Parameter 'identifier_type' in tools 5 and 6 has four redundant enum values ('openfda.generic_name', 'generic_name', 'openfda.brand_name', 'brand_name') with no explanation of the difference or which to prefer. This violates constrained-input guidance and confuses LLMs.
No error handling or recovery guidance. Tools return mock messages like 'No X found for Y' but provide no next steps (e.g., 'Try with brand name', 'Check spelling'). LLMs have no guidance on how to handle failures.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Search FDA drug recalls and safety alerts. Use when asked about 'recalls', 'safety alerts', 'withdrawn drugs', or 'has [drug] been recalled'.
Search current FDA drug shortages. Use when asked about drug availability, shortages, supply issues, or 'is [drug] in shortage'.
Search serious adverse events only (death, hospitalization, disability). Use when asked about 'serious side effects', 'dangerous reactions', 'fatal events', or 'hospitalizations from [drug]'.
No pagination documented for any search/list tool. Tools accept 'limit' but lack next_cursor, page, or offset parameters. Large result sets risk context window exhaustion.
No idempotency, destructiveness, or confirmation annotations. Tool descriptions don't indicate whether calls can be safely retried or if side effects exist. For FDA data this may be read-only, but should be explicit.
Parameter descriptions lack actionable constraints. E.g., 'drug_name' description doesn't specify: Is it case-sensitive? Partial match or exact? Accepts brand names or generic names only? These details force LLMs to guess.