Hospital Data MCP Server
# Hospital Data MCP Server
A repo to manage an MCP server to enable access to the data set providing hospital data
The data is entirely made up and bears no linkage and or repsentation to any person.
### Running: SSE
Need two terminal:
>#### Terminal 1
> 1. ```uv run -m wxo_bootcamp_mcp_server.app_sse``` : Run the SSE server
>#### Terminal 2
> 1. ```npx @modelcontextprotocol/inspector``` : Run the inspector for testing
### Running: STDIO
#### Terminal
1. ```npx @modelcontextprotocol/inspector``` : Run the inspector for testing
2. Use the following setup:
- Transport Type: ```STDIO```
- Command: ```uv run -m wxo_bootcamp_mcp_server.app_stdio```
- Arguments: ```--no-banner```
### Podman
You can do this for _Terminal 1_
1. from root
2. podman build .
3. podman run -p 8080:8080 [Container ID]
4. npx @modelcontextprotocol/inspector
5. https://localhost:8080/sse
# Deploy to a TechZone zone Code Engine
Pre Reqs:
> - You will need to build the image locally
> - You will need a cloud account with a container registry you can write too
> - Install ibmcloud cli (https://cloud.ibm.com/docs/containers?topic=containers-cli-install)
> - Run the following commands:
> - ibmcloud plugin install container-registry -r 'IBM Cloud'
> - ibmcloud plugin install ce
## Use an external IBM Cloud Container Registry
### Account A (The one with the Container Registry)
- $ibmcloud login -a https://cloud.ibm.com --sso
- Choose the account with the Container
- $ibmcloud target -r [region]
- $ibmcloud target -g [group_name]
- $ibmcloud cr login
- $ibmcloud cr namespace-add [NAMESPACE]
- $podman tag wxo-bootcamp-mcp-sever us.icr.io/[NAMESPACE]/[IMAGE_NAME]:[TAG]
- $podman push us.icr.io/[NAMESPACE]/[IMAGE_NAME]:[TAG]
- $ibmcloud iam service-id-create [SERVICE_ID_NAME] --description "Service ID for cross-account Container Registry access"
- $ibmcloud iam service-policy-create [SERVICE_ID_NAME] --roles Reader --service-name container-registry
- $ibmcloud iam service-api-key-create [API_KEY_NAME] [SERVICE_ID_NAME] --description "API key for cross-account registry access" --file api-key.json
- To view the API Key and get [API_KEY_VALUE]
- $cat api-jey.json
### Account B (The techzone one with the Code Engine)
- $ibmcloud login -a https://cloud.ibm.com --sso
- Choose the account with the Techzone Account
- $ibmcloud ce login
- $ibmcloud ce project select -n [PROJECT NAME]
- The project name is visible in the Code Engine page
- $ibmcloud ce registry create --name [REGISTRY_SECRET_NAME] --server us.icr.io --username iamapikey --password [API_KEY_VALUE]
- $ibmcloud ce application create --name [APP_NAME] --image us.icr.io/[NAMESPACE]/[IMAGE_NAME]:[TAG] --registry-secret [REGISTRY_SECRET_NAME]
## Use everything on the Techzone instance
- $ibmcloud login -a https://cloud.ibm.com --sso
- Choose the account with the Techzone Account
- $ibmcloud target -g [RESOURCE_GROUP]
- Get the Resource GRoup from the Resource List
- $ibmcloud cr login
- $podman tag wxo-bootcamp-mcp-sever us.icr.io/[NAMESPACE]/[IMAGE_NAME]:[TAG]
- The [NAMESPACE] is the only one available when you look at Container Registry in the techzone instance. You do not need to create one
- $podman push us.icr.io/[NAMESPACE]/[IMAGE_NAME]:[TAG]
- $ibmcloud iam api-key-create [API_KEY_NAME] --d "Tech Zone Code Engine registry access"
- $ibmcloud ce project select -n [PROJECT NAME]
- $ibmcloud ce registry create -name [REGISTRY_SECRET_NAME] --server us.icr.io --username iamapikey --password [API_KEY_VALUE]
- THE [API_KEY_VALUE] will be available from the previous command
- $ibmcloud ce application create --name [APP_NAME] --image us.icr.io/[NAME_SPACE]/[IMAGE_NAME]:[TAG] --registry-secret [REGISTRY_SECRET_NAME]
# Test using MCP Inspector
- $npx @modelcontextprotocol/inspector
- Use the URL for the application (from Code Endgine) and append /sse as the URL
- https://[APP_NAME].[IBM_CLOUD_URL_PART]/sse
# To run using personal access token from GitHUb, for wxo
uvx --from git+https://YOUR_TOKEN@github.ibm.com/Benjamin-Janes/wxo-bootcamp-mcp-server.git wxo-bootcamp-data-server-stdioTDQS
Scored across 8 tools
Most tools target distinct data types (drug info, vital signs, patient info, medical info). The only overlap is wxoGetPatient360, which explicitly aggregates the individual patient-related getters, but its purpose as a composite view is clear from the description.
All tools follow the exact same 'wxoGet' + PascalCase noun pattern, creating a predictable and uniform naming convention. The minor typo in 'DrugInterations' does not affect the consistent structure.
With 8 tools, the server is well-scoped for a hospital data access API. The number is within the ideal 3-15 range and each tool serves a clear query purpose.
The tool set covers core patient, medical, vital signs, and drug-related queries, but lacks search/list operations (e.g., find patients, search drugs) and any write capabilities. While likely read-only, the absence of basic lookup endpoints creates notable gaps for general hospital data exploration.