Myatriumhealth MCP

What myatriumhealth-mcp MCP server does

The myatriumhealth-mcp MCP server exposes MyAtriumHealth records through MCP. It is designed for the patient's own signed-in account and can also open proxy patients available to that login. Read operations cover allergies, health issues, immunizations, medications, laboratory and imaging results, appointments, past visits, goals, health-summary information, insurance, care-team providers, billing accounts, and Message Center content.

Responses identify the active patient alongside the returned data. The connector can list available patients, report the patient currently selected in the portal, and change that selection. Changing the active patient affects which chart later readers access; it does not write a clinical record.

How it works

myatriumhealth-mcp supports two authentication paths. In the default browser-bridge mode, the server does not receive or store the browser's session cookie. Requests are relayed through the user's signed-in MyAtriumHealth tab using the ContextMint Bridge extension and fetchproxy bridge. The initial health check provides a pair code for approving the connection in the extension.

Bridge-less mode uses MAH_USERNAME and MAH_PASSWORD to sign in from the server. If the portal requests verification, mah_sign_in reports the available channels, mah_send_verification_code asks MyAtriumHealth to send a code, and mah_verify_code submits the code supplied by the account holder. The server stores session state in a protected device file and reuses it across restarts. A later expiry requires another verification code rather than a new MCP connection.

The portal uses both modern JSON and legacy form-based request patterns. The server handles those portal APIs behind its MCP tools. It does not bypass multi-factor authentication.

Setup and configuration

Install the server as an MCP process with:

{
  "mcpServers": {
    "myatriumhealth": {
      "command": "npx",
      "args": ["-y", "@chrischall/myatriumhealth-mcp"]
    }
  }
}

For browser mode, install ContextMint Bridge in Chrome, sign in to my.atriumhealth.org, start the server, and call mah_healthcheck. Approve the displayed pair code in the extension. Safari support is not described as currently available.

For server-side authentication, set both MAH_USERNAME and MAH_PASSWORD; setting only one falls back to bridge mode. Credentials may also be loaded from the configured dotenv path, ~/.myatriumhealth-mcp/.env, or the working directory's .env, in that order. MAH_DEVICE_FILE controls the persisted session file, which should be treated as a credential because it contains the live cookie jar.

Tools and capabilities

• Read allergies, conditions, immunizations, medications, test results, goals, visits, health summaries, insurance, care-team data, and billing accounts.
• List Message Center folders and conversations, including conversation IDs needed for replies.
• Reply to a Message Center conversation as the active patient. Replies are irreversible and require confirmation or a preview-and-token flow, depending on client support and configuration.
• Check bridge, credential, and session health; inspect authentication status; sign in and complete verification.
• List accessible patients, inspect the confirmed patient context, and set the active patient.

MAH_READ_ONLY=true disables message replies while leaving the tool available. Confirmation behavior can be adjusted with the MCP_CONFIRM_* settings.

Limitations and notes

The project handles personal health information and is maintained with an explicit use-at-your-own-discretion warning. Browser mode avoids storing portal credentials, while bridge-less mode stores the username/password outside the server's described session mechanism and persists session state on disk.

mah_reply_message sends a provider-visible message and cannot undo it. Patient switching is persistent and browser mode also changes the selected patient in the connected tab. Session lifetime is controlled by the portal; an observed idle period of 219 minutes required fresh verification, but that measurement does not establish an absolute timeout. The stored device token is not used to bypass verification.