What can you do with this server?

A read-only MCP server connecting AI clients to Practice Fusion EHR via FHIR R4. Every tool call is audit-logged with PHI-redacted parameters. No writes, scheduling, or patient creation. Patient & Provider Lookup * Search patients by name, date of birth, gender, or identifier (MRN) * Get a single patient's demographics by FHIR Patient ID * Search practitioners/providers by name or identifier (e.g. NPI) Clinical Data * Conditions/diagnoses — problem list with clinical status * Medications — medication requests and their statuses * Lab results — observations with values, units, and dates * Vitals — vital-sign observations (blood pressure, heart rate, temperature, etc.) * Allergies — substance, status, and criticality * Immunizations — vaccine records with dates and statuses Records & Administrative * Appointments — filter by patient, status, and date range * Encounters — clinical visit records with class, type, and status * Documents — reference metadata (notes, summaries, attachments) without downloading binary content * Insurance coverage — payer, subscriber ID, period, and relationship Summary * Patient summary — a pre-visit $everything-equivalent with per-type counts and a bounded sample of raw FHIR resources

How do I use practice-fusion-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@practice-fusion-mcp Search for patients named Sarah Johnson" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

practice-fusion-mcp

by CDVolvik

Overview Schema Related Servers Score Discussions

TypeScript

Remote

practice-fusion-mcp

npm Glama score License: MIT Node MCP FHIR R4 Access

An open-source, FHIR-first, read-only Model Context Protocol server for Practice Fusion. Connect Claude (Desktop / Code), Cursor, or any MCP client to a Practice Fusion EHR to search patients and providers and review appointments, conditions, medications, labs, vitals, allergies, immunizations, encounters, documents, procedures, diagnostic reports, care plans, and goals — running on Practice Fusion's free Open FHIR account.

Read-only by design. Audit-logged. No write access, no scheduling, no patient creation.

Related MCP server: FHIR Careplan

Architecture

flowchart LR
    C["MCP client<br/>Claude Desktop / Code · Cursor"] -- stdio --> S

    subgraph S["practice-fusion-mcp"]
      direction TB
      T["18 read tools<br/>patients · providers · appointments<br/>conditions · meds · labs · vitals<br/>allergies · immunizations · encounters<br/>documents · coverage · procedures · reports<br/>care plans · goals · everything"]
      A["Audit logger<br/>stderr + optional file<br/>free text redacted"]
      F["FHIR client<br/>Bundle unwrap · shapers<br/>pagination · sanitized errors"]
      TP["SMART backend-services<br/>TokenProvider<br/>signed JWT assertion · token cache"]
      T -. audited .-> A
      T --> F
      F --> TP
    end

    TP -- "OAuth2 client-credentials" --> AUTH["PF token endpoint"]
    F -- "read-only FHIR R4" --> PF["Practice Fusion<br/>Open FHIR API"]
    AUTH -- access token --> F

Every tool call flows through the audit logger; the FHIR client only ever holds a short-lived token minted from a signed JWT assertion (SMART backend-services), and long free-text parameters are redacted before anything is logged.

Tools

All tools are namespaced with a practicefusion_ prefix (so they don't collide when loaded alongside other MCP servers), carry a readOnlyHint annotation, and return a typed outputSchema / structuredContent. List tools accept an optional limit (default 50, max 200) and report count and has_more.

Patients & providers

Tool	What it does
`practicefusion_search_patients`	Find patients by name / birthdate / gender / identifier
`practicefusion_get_patient`	One patient's demographics by id
`practicefusion_search_practitioners`	Find providers by name / identifier

Clinical

Tool	What it does
`practicefusion_get_conditions`	A patient's problems / diagnoses
`practicefusion_get_medications`	A patient's medication requests
`practicefusion_get_lab_results`	A patient's laboratory observations
`practicefusion_get_vitals`	A patient's vital-sign observations
`practicefusion_get_allergies`	A patient's allergies & intolerances
`practicefusion_get_immunizations`	A patient's immunizations

Records

Tool	What it does
`practicefusion_get_appointments`	Appointments by patient / status / date
`practicefusion_get_encounters`	A patient's clinical encounters (visits)
`practicefusion_get_documents`	A patient's document references (note metadata)
`practicefusion_get_coverage`	A patient's insurance Coverage (status, payer, period)

Summary

Tool	What it does
`practicefusion_get_everything`	Pre-visit summary for a single patient — per-type counts plus a bounded sample of raw resources (FHIR `$everything` with a per-type-search fallback)

Procedures & care planning

Tool	What it does
`practicefusion_get_procedures`	A patient's procedures
`practicefusion_get_diagnostic_reports`	A patient's diagnostic (lab / imaging) reports
`practicefusion_get_care_plans`	A patient's care plans
`practicefusion_get_goals`	A patient's care goals

Prompts & resources

Beyond tools, the server exposes the other two MCP primitives.

Prompts — ready-made templates a client can surface:

Prompt	Args	What it does
`pre_visit_summary`	`patientId`	Guides the assistant to assemble a one-minute pre-visit summary from the read tools
`medication_review`	`patientId`	Reviews a patient's medications against their problems and allergies (decision support, not prescribing)

Resources — readable by URI:

Resource	URI	What it returns
Patient summary	`practicefusion://patient/{patientId}/summary`	Every resource linked to a patient (FHIR `$everything`), as JSON

Resource reads are audit-logged like tool calls.

Example

Ask an MCP client a question and it composes the tools:

You: What are Ana Rivera's active medications?

// 1. resolve the patient
practicefusion_search_patients { "name": "Ana Rivera" }
// → { "results": [{ "id": "abc123", "name": "Ana Rivera", "birthDate": "1984-02-11" }], "count": 1, "has_more": false }

// 2. read her medications
practicefusion_get_medications { "patientId": "abc123" }
// → { "results": [
//      { "medication": "Lisinopril 10 mg", "status": "active" },
//      { "medication": "Atorvastatin 20 mg", "status": "active" }
//    ], "count": 2, "has_more": false }

Assistant: Ana Rivera has 2 active medications: Lisinopril 10 mg and Atorvastatin 20 mg.

Because every tool returns structuredContent, the client gets typed objects — not just text — so it can chain calls reliably.

Demo mode

You can run everything above with no Practice Fusion account. Demo mode serves in-memory synthetic fixtures — no credentials, no network, no PHI — and the example query returns exactly what's shown.

One command, nothing to clone:

npx -y practice-fusion-mcp --demo

Or from a clone:

pnpm install
pnpm dev --demo

Or point an MCP client at it with the --demo flag (or set PF_DEMO=1 in its env):

{
  "mcpServers": {
    "practice-fusion-demo": {
      "command": "npx",
      "args": ["-y", "practice-fusion-mcp", "--demo"]
    }
  }
}

The fixtures cover two patients across every resource type — conditions, medications, labs, vitals, allergies, immunizations, appointments, encounters, documents, and coverage — so each tool returns something. It's the quickest way to see the tools before wiring real credentials.

Setup

Register a free Practice Fusion Open FHIR developer account and create a System / backend-services app. Note your FHIR base URL, token URL, client id, and register your app's public key.
Provide the environment variables below. In production, use your MCP client's env block (shown in step 3). For local development, copy .env.example to .env — pnpm dev loads it automatically.
Add to your MCP client config, e.g. Claude Desktop:

{
  "mcpServers": {
    "practice-fusion": {
      "command": "npx",
      "args": ["-y", "practice-fusion-mcp"],
      "env": {
        "PF_FHIR_BASE_URL": "https://fhir.practicefusion.com/r4",
        "PF_TOKEN_URL": "https://auth.practicefusion.com/token",
        "PF_CLIENT_ID": "your-client-id",
        "PF_PRIVATE_KEY": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----"
      }
    }
  }
}

Environment variables

Var	Required	Default	Notes
`PF_FHIR_BASE_URL`	yes	—	FHIR R4 base URL
`PF_TOKEN_URL`	yes	—	OAuth2 token endpoint
`PF_CLIENT_ID`	yes	—	Backend-services client id
`PF_PRIVATE_KEY`	yes	—	PKCS8 PEM private key (matches the registered public key)
`PF_SCOPES`	no	`system/*.read`	Requested scopes
`PF_TOKEN_ALG`	no	`RS384`	JWT signing alg
`PF_AUDIT_LOG`	no	—	Optional file path for audit records (always also written to stderr)
`PF_AUDIT_LOG_FORMAT`	no	`text`	Audit log file format: `text` (multi-line, human-readable) or `ndjson` (one JSON object per line, SIEM-friendly). stderr always uses `text`.
`PF_RETRY_MAX_ATTEMPTS`	no	`4`	Total attempts for transient FHIR responses (429/502/503/504). 1 = no retry.
`PF_RETRY_BASE_MS`	no	`500`	Initial backoff in ms. Doubles each attempt (500 → 1000 → 2000 …) up to `PF_RETRY_CAP_MS`.
`PF_RETRY_CAP_MS`	no	`8000`	Maximum backoff between retries. `Retry-After` from the server is always honored.

MCP clients

The server speaks the Model Context Protocol over stdio, so it works in any MCP client that supports a local command + args + env config. Pick your client:

Client	Tested	Setup
Claude Desktop	✅	`docs/clients/claude-desktop.md`
Claude Code	✅	`docs/clients/claude-code.md`
Cursor	✅	`docs/clients/cursor.md`
VS Code + GitHub Copilot (Agent mode)	✅	`docs/clients/vscode-copilot.md`
OpenCode	✅	below — Other clients
Codex CLI	✅	below — Other clients
Cline / Roo Cline	✅	below — Other clients
Windsurf	✅	below — Other clients
Continue.dev	✅	below — Other clients
T3 code	—	GUI wrapper — install the MCP server in the underlying agent (Codex, Claude, Cursor, or OpenCode); the configs above apply
R21 Hermes Agent (R21-internal)	✅	below — R21 fleet
R21 OpenClaw host (R21-internal)	—	host (not a client) — install the MCP server in whichever agent runs on the machine (Claude Code / OpenCode / Codex CLI); the configs above apply

The same PF_* environment variables apply everywhere. The package is published on npm, so every config uses the same command: npx / args: ["-y", "practice-fusion-mcp"] pair; only the file location and JSON key (mcpServers vs servers vs mcp etc.) differ.

Other clients (one-liner configs)

All five use the same { command, args, env } shape. Only the config file location and JSON key differ.

OpenCode — global ~/.config/opencode/config.json or per-project opencode.json:

{
  "mcp": {
    "practice-fusion": {
      "type": "local",
      "command": ["npx", "-y", "practice-fusion-mcp"],
      "environment": {
        "PF_FHIR_BASE_URL": "https://fhir.practicefusion.com/r4",
        "PF_TOKEN_URL": "https://auth.practicefusion.com/token",
        "PF_CLIENT_ID": "your-client-id",
        "PF_PRIVATE_KEY": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----"
      }
    }
  }
}

Codex CLI — ~/.codex/config.toml:

[mcp_servers.practice-fusion]
command = "npx"
args = ["-y", "practice-fusion-mcp"]

[mcp_servers.practice-fusion.env]
PF_FHIR_BASE_URL = "https://fhir.practicefusion.com/r4"
PF_TOKEN_URL = "https://auth.practicefusion.com/token"
PF_CLIENT_ID = "your-client-id"
PF_PRIVATE_KEY = """-----BEGIN PRIVATE KEY-----
...your key...
-----END PRIVATE KEY-----"""

Cline / Roo Cline — Cline MCP settings panel, or .cline/mcp_settings.json directly (same shape as Claude Desktop — see Setup).

Windsurf — ~/.codeium/windsurf/mcp_config.json (same shape as Claude Desktop).

Continue.dev — ~/.continue/config.json under the mcpServers key (same shape as Claude Desktop).

Models

practice-fusion-mcp is model-agnostic — it doesn't care which LLM sits behind the client. Use Anthropic Claude (in any of the above clients), OpenAI GPT (Codex, Cursor, Continue), Google Gemini (Continue, Cline), local Ollama models, or NVIDIA Nemotron served via NIM inside any of the clients that accept a custom OpenAI-compatible endpoint (most do). The model you pick only changes answer quality, not which tools the server exposes.

R21 fleet

The maintainer (R21 Digital) runs practice-fusion-mcp across two R21-internal surfaces:

Hermes Agent — R21's multi-agent orchestration. Wire the MCP server into the Hermes sub-agent that handles healthcare/EHR work; the npx -y practice-fusion-mcp invocation is wrapped in a Make.com scenario or a Hermes tool spec. The deployer-friendly error banner (see Troubleshooting) plays well with Hermes' tool-call surfaces.
OpenClaw — one of the R21 fleet machines. OpenClaw is a host, not a client — the right setup is whichever agent runs there (typically Claude Code or OpenCode on the R21 fleet). Use the per-client config above for whichever agent you launch the MCP from.

For deeper R21-internal deployment notes (Make.com scenarios, Hermes sub-agent patterns, fleet-wide credential rotation), see the R21-internal docs/clients/hermes.md and docs/clients/openclaw.md (R21 Digital workspace, not this public repo).

Troubleshooting

If the server fails to start, the boot path prints a deployer-friendly error instead of a raw Zod dump. Each line names the env var and the fix:

practicefusion-mcp: configuration error
  ✗ PF_CLIENT_ID: required env var is missing
      Set it in your MCP client config or .env, e.g. the client_id from your SMART backend-services app
  ✗ PF_PRIVATE_KEY: required env var is missing
      Key must start with -----BEGIN PRIVATE KEY----- and be PKCS8 format
  ✗ PF_FHIR_BASE_URL: Invalid URL
      Must be a URL, e.g. https://fhir.practicefusion.com/r4
  … and 2 more (set PF_VERBOSE=1 for full output)

Values are never echoed — only the env var name. Set PF_VERBOSE=1 in your MCP client config to get the raw Zod issue tree when the friendly output isn't enough. The server exits 1 on any configuration error so the host can surface it.

Security & HIPAA

This server handles Protected Health Information. You, the deployer, are the covered entity or business associate: you are responsible for your own Business Associate Agreement (BAA) with Veradigm/Practice Fusion and for running this in a HIPAA-appropriate environment. Every tool call is audit-logged (stderr, plus optional file) with long free-text parameters redacted. Tokens and keys are never logged. This project ships code, not a hosted data service. See SECURITY.md for details. Not legal advice.

Known limits

No writes. No scheduling, no charting, no patient creation. That is the boundary, not a roadmap item.
The audit log contains patient identifiers. Redaction is by length: free-text parameters over 64 characters become [redacted:N], shorter structured values — a name, a birthdate — are written as sent. That is deliberate; an audit trail that cannot say who was accessed is no use for an accounting of disclosures. Treat the log as PHI and store it accordingly. See ADR 0005.
Shaped summaries drop fields. Each shaper keeps what the task needs. practicefusion_get_everything is the escape hatch when that is not enough.
One tenant per process. A single credential set and a single TokenProvider. Serving several practices means running several processes.
Most paths are covered against mocks. The unit suite runs with no credentials; live coverage against a real tenant is bounded by partner-account approval.

How it differs from the alternative

The other way to reach a Practice Fusion EHR is the proprietary Unity APIs. The official Practice Fusion Integrator tier is built on them and needs a Veradigm partnership; community MCP servers built on the same APIs have shown up in the directories too, and they tend to be read-write — creating patients, booking appointments, editing insurance.

This server takes the FHIR route instead. It runs on Practice Fusion's free Open FHIR account with no partnership, and it is read-only and audit-logged on purpose: a deliberately small risk surface for putting an EHR behind an LLM. If you need to write data or manage scheduling, a proprietary-API server will fit you better; if you want EHR reads you can reason about, this is the one.

If you arrived here looking for "any Practice Fusion MCP" and now want the wider FHIR / EHR / healthcare MCP landscape:

wso2/fhir-mcp-server — generic FHIR R4 MCP server, language-agnostic, MIT.
the-momentum/fhir-mcp-server — FHIR MCP server for medical data standards.
erikhoward/azure-fhir-mcp-server — FHIR R4 against Azure Health Data Services (similar shape, Microsoft stack).
jcafazzo/fhir-mcp — enhanced FHIR MCP with data-quality assessment and broader clinical coverage.
DhairyaShah981/fhir-mcp — clinical-data bridge with reversible keyed de-identification and CDS Hooks.

Glama's MCP directory lists all of these plus ~62k others. This server is on Glama as practice-fusion-mcp.

Development

pnpm install
pnpm test          # unit tests (mocked FHIR — no credentials needed)
pnpm typecheck     # tsc --noEmit
pnpm lint          # eslint
pnpm format        # prettier --write
pnpm build         # bundle to dist/

CI (GitHub Actions) runs Prettier, ESLint, typecheck, tests, and build on Node 22 and 24. See CONTRIBUTING.md to add a tool, and docs/adr for the architecture decisions behind the design.

Available Tools

7 tools

practicefusion_get_allergiesGet allergiesA

Read-onlyIdempotent

List a patient's allergies and intolerances from Practice Fusion. Returns shaped allergy summaries (substance, status, criticality). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default 50, max 200)
`patientId`	Yes	FHIR Patient resource id (from practicefusion_search_patients)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned
`results`	Yes
`has_more`	Yes	True if more results were available beyond `limit`

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds 'Read-only' which aligns with annotations, and mentions return format but does not disclose additional behavioral traits such as pagination or error handling. No contradictions found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no unnecessary words. It front-loads the action and resource, then briefly states return fields and nature. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters (1 required), an output schema (not shown but present), and comprehensive annotations, the description adequately covers what the tool does. It mentions return fields, which compensates for the lack of output schema details in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptions for both parameters (limit, patientId). The description does not add any parameter-specific meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and resource 'a patient's allergies and intolerances from Practice Fusion'. It specifies the return format 'shaped allergy summaries (substance, status, criticality)' and marks it as 'Read-only', distinguishing it from sibling tools that list other clinical data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving allergy data but does not explicitly state when to use this tool over alternatives like practicefusion_get_conditions or practicefusion_get_medications. No guidance on prerequisites or context is provided beyond patientId requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

practicefusion_get_appointmentsGet appointmentsA

Read-onlyIdempotent

List Practice Fusion appointments, optionally filtered by patient, status, and date. Dates use FHIR prefixes, e.g. ge2026-07-01 (on/after) or le2026-07-31 (on/before). Returns shaped appointment summaries. Read-only.

ParametersJSON Schema

Name	Required	Description
`date`	No	FHIR date filter, e.g. ge2026-07-01 or le2026-07-31
`limit`	No	Maximum number of results to return (default 50, max 200)
`status`	No	Appointment status, e.g. booked, arrived, fulfilled, noshow, cancelled
`patientId`	No	FHIR Patient resource id

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned
`results`	Yes
`has_more`	Yes	True if more results were available beyond `limit`

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint; description adds FHIR date prefix format and return type ('shaped appointment summaries'), enhancing transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Rich annotations and output schema complement the description; complete for a read-only list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters; description adds FHIR date prefix example and 'shaped' return, but marginal beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List Practice Fusion appointments' with optional filters, distinguishing it from sibling tools like practicefusion_get_conditions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for listing appointments with filters; no explicit when-not or alternatives, but context signals and sibling names provide enough differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

practicefusion_get_conditionsGet conditionsA

Read-onlyIdempotent

List a patient's conditions / problems (diagnoses) from Practice Fusion. Returns shaped condition summaries. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default 50, max 200)
`patientId`	Yes	FHIR Patient resource id (from practicefusion_search_patients)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned
`results`	Yes
`has_more`	Yes	True if more results were available beyond `limit`

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Returns shaped condition summaries', which is useful but not critical. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, 16 words, front-loaded with purpose. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be described. Input schema fully covers parameters. Annotations cover safety. Description is complete for a read-only list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with full descriptions. The description does not add parameter details, but the schema is sufficient. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List', the resource 'conditions / problems (diagnoses)', and the scope 'patient's'. It distinguishes from sibling tools by specifying the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use (list patient conditions) and mentions 'Read-only' for safety, but does not explicitly mention when not to use or alternative tools. Sibling context provides implicit differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

practicefusion_get_immunizationsGet immunizationsA

Read-onlyIdempotent

List a patient's immunizations (vaccines) from Practice Fusion. Returns shaped immunization summaries (vaccine, status, date). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default 50, max 200)
`patientId`	Yes	FHIR Patient resource id (from practicefusion_search_patients)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned
`results`	Yes
`has_more`	Yes	True if more results were available beyond `limit`

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by stating that it returns 'shaped immunization summaries (vaccine, status, date)', clarifying the output structure. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, no fluff. The key information is front-loaded: action, resource, output type, and read-only nature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple output, annotations, and presence of an output schema, the description is fairly complete. It specifies the return fields (vaccine, status, date) and notes read-only behavior, which is sufficient for a list endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described. The description adds no extra parameter details beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List a patient's immunizations (vaccines) from Practice Fusion' with a specific verb ('List') and resource ('immunizations'). This distinguishes it from sibling tools like practicefusion_get_medications or practicefusion_get_conditions, which return different data types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., other get_* tools for different FHIR resources). It does not mention which patient ID to use or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

practicefusion_get_lab_resultsGet lab resultsA

Read-onlyIdempotent

List a patient's laboratory observations (lab results) from Practice Fusion. Returns shaped observation summaries with values and dates. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default 50, max 200)
`patientId`	Yes	FHIR Patient resource id (from practicefusion_search_patients)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned
`results`	Yes
`has_more`	Yes	True if more results were available beyond `limit`

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that it returns 'shaped observation summaries with values and dates', providing behavioral context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose, second adds return format and read-only note. No wasted words, front-loaded with key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with 2 parameters and an output schema (flagged as present). Description mentions return format ('shaped observation summaries with values and dates'), but could clarify relationship to FHIR Observation resource. Otherwise complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters having descriptions. The tool description does not add further parameter details beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool lists a patient's lab results from Practice Fusion, with explicit verb 'List' and resource 'laboratory observations (lab results)'. The sibling tools are for different FHIR resources (appointments, conditions, etc.), so this description effectively distinguishes it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for retrieving lab results but provides no explicit guidance on when to use versus alternatives (sibling tools are for different resources, so context suggests appropriate use). No when-not-to-use or prerequisite information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

practicefusion_get_medicationsGet medicationsA

Read-onlyIdempotent

List a patient's medication requests from Practice Fusion. Returns shaped medication summaries. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default 50, max 200)
`patientId`	Yes	FHIR Patient resource id (from practicefusion_search_patients)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned
`results`	Yes
`has_more`	Yes	True if more results were available beyond `limit`

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly, idempotent, openWorld. Description adds that it returns 'shaped medication summaries', providing extra behavioral context beyond annotations. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences, front-loaded with purpose, no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple list tool with output schema and rich annotations. Could clarify what 'shaped' means, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions (100% coverage). Description only adds 'patient's' context but no new semantics beyond schema. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'list', resource 'medication requests', and scope 'a patient's'. Differentiates from sibling tools which cover different clinical data types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage from context ('from Practice Fusion'), but no explicit guidance on when to use vs alternatives or when not to use. Lacks exclusions or alternative tool mentions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

practicefusion_get_vitalsGet vital signsA

Read-onlyIdempotent

List a patient's vital-sign observations (blood pressure, heart rate, temperature, etc.) from Practice Fusion. Returns shaped observation summaries with values and dates. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return (default 50, max 200)
`patientId`	Yes	FHIR Patient resource id (from practicefusion_search_patients)

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned
`results`	Yes
`has_more`	Yes	True if more results were available beyond `limit`

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds that it returns 'shaped observation summaries with values and dates,' which provides some behavioral context without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the main purpose, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with full annotations and an output schema, the description is sufficient. It could be slightly more precise about the return format but is generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with clear descriptions for both patientId and limit parameters. The tool description does not add additional parameter meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists a patient's vital sign observations, specifying the verb 'list' and resource. It also distinguishes from sibling tools like conditions or medications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates it is read-only and returns observations, but does not explicitly state when to use this tool versus alternatives like lab results or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool retrieves a distinct clinical data type (appointments, conditions, medications, lab results, vitals, allergies, immunizations) with no overlap in purpose.

Naming Consistency5/5

All tools follow the exact pattern 'practicefusion_get_<resource>' using consistent snake_case and verb-noun structure.

Tool Count5/5

7 tools is well-scoped for a read-only EHR data retrieval server, covering the most common clinical data categories without unnecessary bloat.

Completeness3/5

While the covered resources are appropriate, the server lacks a patient search or listing tool, creating a dependency on external patient IDs that may hinder agent workflows.

Maintenance

ActivityActive

ResponsivenessWithin a week

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
com.medplum
Securely access and manage FHIR healthcare data stored in Medplum.
Biology & Medicine Databases
22,650
vital A
io.usefulapi
Read wearables and lab health data — sleep, activity, workouts, timeseries, lab tests and orders.
Health & Wellness Biology & Medicine Fitness Tracking
212
metriport A
io.usefulapi
Read and write patients, facilities, medical documents, and consolidated FHIR records in Metriport.
Biology & Medicine Data Platforms
122
healthie A
io.usefulapi
Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.
Biology & Medicine Calendar Management
162

Related MCP Servers

Smart EHR MCP Server
Health & Wellness Databases
jmandel
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that connects AI tools to Electronic Health Records using SMART on FHIR, allowing secure searching, querying, and analysis of patient data from compatible EHRs.
Updated a year ago (2025-08-15 04:26 UTC)
85
MIT
FHIR Careplan
Databases Health & Wellness Search
Kushagra-Dutta
F
license
Not graded
quality
C
maintenance
A comprehensive Model Context Protocol server that provides universal access to multiple FHIR servers with AI-powered clinical analysis capabilities for healthcare data integration and patient care planning.
Updated a year ago (2025-07-24 09:59 UTC)
3
FHIR MCP Server
Biology & Medicine RAG Systems
the-momentum
A
license
A
quality
D
maintenance
Enables LLM-based agents to interact with FHIR healthcare data through natural language prompts, providing full CRUD operations on FHIR resources, document processing, and semantic search capabilities.
Updated 10 months ago (2025-10-23 13:06 UTC)
13
98
MIT
FHIR MCP Server
Biology & Medicine Databases Search
sumithasb
-
license
Not graded
quality
Not graded
maintenance
Enables seamless integration with FHIR APIs for healthcare applications, allowing users to search, retrieve, create, update, and analyze clinical information through natural language interactions. Supports SMART-on-FHIR authentication and works with various healthcare systems like EPIC and HAPI FHIR servers.
Updated a year ago (2025-09-06 06:08 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CDVolvik/practice-fusion-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

practice-fusion-mcp

Contents

Architecture

Tools

Prompts & resources

Example

Demo mode

Setup

Environment variables

MCP clients

Other clients (one-liner configs)

Models

R21 fleet

Troubleshooting

Security & HIPAA

Known limits

How it differs from the alternative

Related MCP servers

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API