Loading ToolBench
A comprehensive FHIR-compliant server that provides a robust set of tools for securely managing and accessing healthcare data. It supports a wide range of FHIR resources, enabling seamless interaction with patient information, clinical records, and administrative data.
Single tool with acceptable naming but significant documentation gaps. The tool 'get_document_content' follows verb_noun convention, has a parameter schema with types, but lacks parameter descriptions and output schema documentation. Description is present (221 chars, within acceptable range) but does not explain return structure or when to use extraction mode. No error handling guidance. The tool interface is narrow (only 1 tool) and lacks composition patterns. Code shows FHIR integration attempt but incomplete implementation (Dockerfile references PyPDF2 but main tool code is cut off at _format_organization function; incomplete return statement 'return for' indicates source truncation). Cannot verify full implementation quality from provided excerpt.
Get the content of a PDF document from a DocumentReference resource. This tool retrieves a specified DocumentReference, extracts the PDF content from it, and optionally converts the PDF content to plain text. Args: document_reference_id: The ID of the DocumentReference resource. extract_text: If True, extracts and returns the text content from the PDF. If False (default), returns the base64-encoded PDF content. Returns: A dictionary containing the document content. If 'extract_text' is True, the dictionary will have a 'text_content' key. Otherwise, it will have a 'pdf_content_base64' key.
Input schema parameters lack descriptions. The 'document_reference_id' and 'extract_text' parameters have no explanatory text beyond the type definition. LLMs cannot determine semantic meaning from names alone, 'extract_text' needs context on what 'text' means (plain ASCII? markdown? with/without formatting?).
Output schema is completely undocumented. The docstring mentions 'text_content' and 'pdf_content_base64' keys but does not specify the overall structure, field types, or error response format. LLMs cannot plan downstream operations without knowing return shape.
No error handling guidance. Tool description does not explain what happens if document_reference_id is invalid, FHIR server is unreachable, PDF extraction fails, or authentication fails. No recovery hints for the agent.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
FHIR_AUTH_TOKEN is exposed as an environment variable in server initialization. If this token is ever included in error messages, logs, or debug output, it could leak into agent traces. No evidence of secret masking in responses.
Incomplete source code provided. The fhir_mcp_server.py file ends abruptly mid-function ('return for' is a syntax error). Cannot verify actual tool implementation, error handling, or validation logic. Full assessment is impossible.
Single tool server lacks composition. A FHIR server should offer a family of related tools (search_patients, get_patient, search_document_references, get_document_content, etc.) to enable multi-step agent workflows. Current server does not provide the discovery/query tools needed to find document_reference_id values in the first place.
extract_text parameter defaults to false but description does not explain why an agent would choose one mode over the other. No guidance on use cases (e.g., 'use extract_text=true for text search, false to preserve PDF formatting').