MCP 2.0 Server for Veradigm FHIR and Unity API integration with AI voice agents
Scoring was not performed
Output schemas are not explicitly documented. Tools declare return types in comments and code but not in formal JSON Schema. LLMs cannot plan downstream calls or extract fields confidently without documented output structures.
No error recovery guidance. ErrorHandler.createValidationError() and ErrorHandler.handleUnknownError() are called but no return messages guide LLMs on next steps (e.g., 'Try search_patient() with partial name' when patient not found).
No tool annotations. Tools lack readOnlyHint (all are read-except-create_appointment), destructiveHint (create_appointment modifies state), or idempotentHint. Agents cannot distinguish safe-to-retry from irreversible operations without explicit hints.
Parameter descriptions lack domain context and usage guidance. 'FHIR Patient resource ID' does not tell LLMs how to obtain the ID (via search_patient first) or whether human-friendly names are accepted. Descriptions should state dependencies and accepted identifier types.
No batch operation variants. Search tools (search_patient, search_providers, search_locations) accept single calls only. Agents iterating over results to fetch details will make N+1 calls. Batch variants (e.g., get_details_batch) would reduce latency and token count.
Search tools do not guide when to call discovery vs detail tools. E.g., search_patient returns patient summaries but tool description does not explain that get_patient_details should be called next for full records. Agents waste reasoning cycles deciding which tool to invoke.
Overlapping tools create selection ambiguity. Both get_medication_requests and get_patient_medications exist; descriptions do not explain the distinction (request status enum vs statement history). LLMs will guess and potentially call both, wasting tokens.
Transport unknown in submission metadata. Code references Express.js server (package.json, Dockerfile) but transport mechanism not declared. Assume HTTP Streamable but cannot confirm SSE vs. WebSocket vs. STDIO from provided source. This blocks protocol readiness scoring.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 13 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | 0.5.0+ | v1 |