Healthcare MCP Server: How AI Agents Use Telehealth

A healthcare MCP server is a Model Context Protocol server that lets an AI agent (Claude, ChatGPT, a coding assistant, an in-house agent) read a telehealth platform's information and, with explicit human consent, take a narrow set of actions, through a standard JSON-RPC interface instead of scraping pages or hand-writing API clients. The safe design splits tools into two classes: read tools that return public or authorized data, and consent-gated action tools that do something on a person's behalf and require that person's approval each time. An agent should never make a clinical decision, write a prescription, or touch protected health information without authentication, a business associate agreement and an audit trail. MyOrbitHealth publishes a free, no-auth MCP server at myorbithealth.com/mcp with 21 tools (19 read, 2 consent-gated action tools) that covers the company's platform, fee model, compliance, state rules, cost estimates, comparisons and articles, alongside an OpenAPI 3.1 agent API, an npm CLI, llms.txt and markdown mirrors. Cuvo Health publishes a 9-tool site MCP and a separate 46-tool developer MCP behind OAuth 2.1 for sandbox and live clinic operations. This post explains the protocol, the safety boundaries, both servers and how to think about agent-ready infrastructure. This is general information, not legal advice.

Key takeaways

• Model Context Protocol is an open standard, using JSON-RPC 2.0, for connecting LLM applications to external tools, resources and prompts; its specification makes user consent and tool safety first-class principles.
• A healthcare MCP server should separate read tools from consent-gated action tools, keep PHI behind authentication and a BAA, and leave every clinical decision to a licensed provider.
• MyOrbitHealth's public MCP server at myorbithealth.com/mcp exposes 21 tools (19 read, 2 consent-gated action tools), needs no auth, and is one layer of a free agent surface that also includes an OpenAPI 3.1 agent API, the npx myorbithealth CLI, llms.txt and markdown mirrors of every page.
• As of October 2026, per its public docs, Cuvo publishes a 9-tool site MCP with no auth and a 46-tool developer MCP behind OAuth 2.1 with scopes, included on its Grow plan and above.
• Agent-ready infrastructure means the agent can discover, read and recommend a platform on its own, while clinical operations stay behind an authenticated product API with human clinicians in the loop.

Who this is for

• Developers building AI agents or assistants that need to research, compare or interact with telehealth platforms.
• Founders and operators who want their brand discoverable and accurately described by ChatGPT, Claude and other assistants.
• Engineering and security leads evaluating whether any agent should be allowed near a clinical workflow, and under what controls.
• Product teams deciding between MCP, a REST API and an SDK for an integration.

What is the Model Context Protocol?

MCP is an open protocol, introduced by Anthropic in November 2024 and now maintained at modelcontextprotocol.io, that standardizes how LLM applications connect to external data and tools. The specification describes three roles: hosts (the LLM application, such as Claude Code or a chat client), clients (connectors inside the host) and servers (services that provide context and capabilities). Messages are JSON-RPC 2.0. A server can offer tools (functions the model can call), resources (data the model or user can read) and prompts (templated workflows); a client can offer elicitation, where the server asks the user for more information.

Two things about the spec matter for healthcare. First, it is explicit that hosts must obtain user consent before invoking any tool and before exposing user data to a server, and that tool descriptions and annotations should be treated as untrusted unless the server is trusted. Second, it defines tool annotations such as a read-only hint and a destructive hint so a client can decide when to ask the human first. The protocol cannot enforce these principles itself; implementors are expected to. That is the whole design problem for a healthcare MCP server: the protocol gives you the vocabulary, and you have to build the controls.

Transports matter too. The current spec supports stdio for local servers and Streamable HTTP for remote ones, and the authorization section describes an OAuth 2.1-based flow for HTTP servers that need to identify the caller. A public, read-mostly server can run without auth; a server that touches patient data cannot.

What can a healthcare MCP server safely do?

Draw the line by what the tool returns and what it changes.

Three boundaries follow.

PHI stays behind auth and a BAA. HIPAA does not certify protocols. It applies to covered entities and business associates handling protected health information, and the Security Rule's technical safeguards at 45 CFR 164.312 (access control, audit controls, integrity, transmission security) apply to any system that stores or moves PHI, MCP server included. A server that exposes PHI must authenticate every caller, scope what each credential can see, log every call, and sit under a business associate agreement with the covered entity. A public no-auth server must never return PHI, which is the simplest way to be safe: do not put PHI behind it at all.

Agents do not make clinical decisions. Federal law at 21 U.S.C. 353(b) permits dispensing a prescription drug only on the prescription of a licensed practitioner, and controlled substances add DEA's EPCS rules at 21 CFR Part 1311 with prescriber identity proofing and two-factor signing. An agent can file an intake, answer a question about state rules, or surface a case to a clinician. It cannot approve a case or sign a prescription, and a well-designed server has no live tool that would let it.

Actions require fresh consent. An action tool should be annotated as non-read-only so the host asks the person before calling it, and the server should treat each call as requiring explicit consent rather than relying on a blanket grant. Requesting a callback is low stakes; booking a clinical visit on someone's behalf is not, and both should ask.

The HIPAA guide for founders covers the obligations behind the first boundary; the telehealth EHR post describes the audit trail that satisfies the third.

What does MyOrbitHealth's public MCP server expose?

MyOrbitHealth's agent layer is separate from its product API and is free with no auth. Per /developers as of October 2026:

• Endpoint: https://myorbithealth.com/mcp, Streamable HTTP, JSON-RPC 2.0, stateless, POST only, JSON responses.
• Tools: 21 in total, 19 read and 2 consent-gated action tools.
• Read tools cover the company overview, platform, fee model and pricing model, compliance, provider network, labs, the LegitScript process, solutions by vertical, state rules, a startup cost estimator, comparisons against other vendors, articles, site search and booking information. Tool names published on the developers page include get_overview, get_platform, get_fee_model, get_compliance, get_provider_network, get_state_rules, estimate_startup_costs, list_comparisons, get_comparison, list_articles, get_article and search_site.
• Action tools are request_demo and request_callback. Both require explicit user consent before they run, and neither touches a patient record.
• Errors follow standard JSON-RPC error objects on MCP, and RFC 9457 problem+json on the REST surface.

Connecting from Claude Code is one command:

claude mcp add --transport http myorbithealth https://myorbithealth.com/mcp

Other MCP-capable clients point at the same URL with the HTTP transport. Because there is no auth, there is no OAuth dance and no key to leak; because there is no PHI, there is nothing to protect beyond ordinary rate limiting.

The same information is reachable through three other agent-friendly surfaces:

• An agent REST API with an OpenAPI 3.1 contract at /openapi.json, with /ask for natural-language queries, /api/articles and /api/comparisons (paginated) and /api/health. Errors are RFC 9457 problem+json.
• An npm CLI: npx myorbithealth --help, with subcommands documented on the developers page for state rules, cost estimates and comparisons (for example npx myorbithealth state TX and npx myorbithealth compare myorbit-vs-qualiphy).
• Crawler and discovery files: /llms.txt and /llms-full.txt, a .md mirror of every page by appending .md to the URL, an RSS feed at /feed.xml, and .well-known discovery files including an MCP server card and an API catalog.

An illustrative example of the agent API (no auth required):

# Example: ask the agent API a question
curl "https://myorbithealth.com/ask?query=does+the+platform+include+EPCS"

# Example: read the OpenAPI 3.1 contract
curl https://myorbithealth.com/openapi.json

What this server does not do, as of October 2026: it does not expose patients, appointments, prescriptions or any other PHI, and it does not wrap the product API. Clinical operations for a brand go through the product REST API at api.myorbithealth.com/v1 with bearer-token auth, environment-scoped test and live keys, HMAC-SHA256 signed webhooks and a React SDK, documented at /api-docs. MyOrbitHealth does not currently publish an authenticated MCP server over that product API, and we are not going to imply one exists.

How does Cuvo's MCP differ?

As of October 2026, per developers.cuvo.co and cuvo.co, Cuvo runs two MCP servers.

• Site MCP at cuvo.co/mcp: 9 tools, no auth, covering pricing, comparisons and articles. Cuvo also publishes A2A and ACP surfaces for its site agent layer.
• Developer MCP at mcp.cuvo.co/mcp: 46 tools behind OAuth 2.1 with PKCE, 20 scopes and audience-bound tokens, grouped into build tools (docs and contract lookup plus 14 sandbox simulators that play the clinician and pharmacy), operate tools (usage, invoices, webhooks, events) and runtime tools (organization, catalog, patients, consents, cases, messages, orders, visits). Per its docs, prescriptions and orders are read-only, a token minted through a person's consent is always a test-mode principal, live credentials refuse until a BAA is accepted, and tools/list only shows tools the credential's scopes allow. API, webhooks and MCP are included on Grow ($15,000 setup plus $2,500 per month) and above, not on Launch.

The honest summary: the two public servers do the same job and MyOrbitHealth's exposes more read tools; Cuvo additionally publishes an authenticated clinic-operations MCP that MyOrbitHealth does not offer today. Whether that matters depends on whether you want an agent operating a clinic, which the next section is about. The MyOrbitHealth vs Cuvo page covers the commercial comparison.

Should an AI agent operate a telehealth clinic?

Separate three jobs an agent might do.

Research and recommend. Compare platforms, check whether a vertical is allowed in a state, estimate startup costs, read a compliance posture. This is what public MCP servers, llms.txt and markdown mirrors are for, it involves no PHI, and it is where most agent traffic to a telehealth vendor actually comes from today. Our get recommended by ChatGPT post explains why making this layer excellent is a growth decision as well as a developer one.

Build and test an integration. A coding agent reading an OpenAPI contract, generating a client, and running against a sandbox. MyOrbitHealth's product API is documented at /api-docs and sandbox keys are provisioned within a day; Cuvo's developer MCP adds docs lookup and sandbox simulators behind OAuth. Either way the agent is working with test data, and the useful question is how good the documentation and the sandbox are. The 9-platform API comparison scores that.

Operate in production. An agent creating real patients, filing real cases, booking real visits. This is technically possible over an authenticated MCP or REST API, and it is where the controls in the previous section become mandatory: BAA in force, scoped credentials, per-call audit, read-only prescriptions and orders, no clinical decisions, fresh consent on every action, and a human clinician on the other end of every case. If a vendor's live surface lets an agent approve a case, that is a defect, not a feature.

Most brands should put real engineering into the first two and be deliberately conservative about the third. A deterministic REST integration with signed webhooks is easier to audit than an agent choosing its next tool call, which is why the telemedicine app development guide recommends building the app and the event handlers and letting the clinical layer run on a documented product API.

MCP, REST API or SDK: which should you use?

Rule of thumb: agents read through MCP, products write through the REST API, front ends embed through the SDK.

How should a brand think about agent-ready infrastructure?

Six properties, in rough order of how much they matter to a brand that is not building agents itself.

1. Discoverability. llms.txt, markdown mirrors, an RSS feed and .well-known files let assistants read the vendor accurately. If the vendor is legible to agents, the brands built on it inherit that legibility in any content the platform publishes about them.
2. A public read surface with no PHI. A no-auth MCP server and agent API that answer factual questions from the source rather than from a model's memory.
3. Consent-gated actions, kept narrow. Request a demo, request a callback. Nothing that commits a patient to anything.
4. A documented product API for the real work. Bearer tokens, test and live keys, signed webhooks, a stated rate-limit contract and a versioning policy. This is the surface your engineers and their coding agents will spend time on.
5. A hard wall around clinical decisions. No agent tool, public or authenticated, that approves a case or signs a prescription.
6. Audit everywhere PHI is touched. OrbitOS keeps a full HIPAA audit trail on the clinical side; your own systems need the same for the PHI they hold.

MyOrbitHealth's agent layer covers the first three today and its product API covers the fourth; the fifth and sixth are structural, because the platform does not practice medicine and clinical work runs through 2,400+ board-certified providers in OrbitOS. The developers page is the current source of truth for the agent surface.

Frequently asked questions

What is a healthcare MCP server?

A Model Context Protocol server that lets AI agents read information from, and in narrow consent-gated cases act on, a healthcare system through a standard JSON-RPC interface. A safe one keeps PHI behind authentication and a BAA, logs every call, and never lets an agent make a clinical decision.

Is there an MCP server for telehealth?

Yes. MyOrbitHealth publishes a free, no-auth MCP server at myorbithealth.com/mcp with 21 tools (19 read, 2 consent-gated action tools) covering its platform, fee model, compliance, state rules, cost estimates, comparisons and articles. As of October 2026 Cuvo publishes a 9-tool site MCP and a 46-tool developer MCP behind OAuth 2.1 on its Grow plan and above.

Can an AI agent prescribe medication?

No. Federal law allows a prescription drug to be dispensed only on the prescription of a licensed practitioner, and controlled substances require DEA-compliant identity proofing and two-factor signing by the prescriber. An agent can collect intake or surface a case, but a licensed provider makes every clinical decision.

Is MCP HIPAA compliant?

HIPAA does not certify protocols. It applies to covered entities and business associates that handle PHI, so an MCP server that exposes PHI must authenticate callers, scope access, keep audit logs and operate under a business associate agreement. A public server that returns no PHI, such as MyOrbitHealth's, sits outside that boundary by design.

How do I connect Claude Code to MyOrbitHealth's MCP server?

Run claude mcp add --transport http myorbithealth https://myorbithealth.com/mcp. No API key or OAuth flow is required because the server exposes only public information and two consent-gated action tools.

What is the difference between MyOrbitHealth's MCP server and Cuvo's?

MyOrbitHealth's is a single public server with 21 read and consent-gated tools over company and platform information, with no PHI and no auth. Cuvo runs a 9-tool public site server plus a separate 46-tool developer server behind OAuth 2.1 that reaches sandbox and, under a BAA, live clinic operations; the developer server requires its Grow plan or above.

Can an AI agent book a telehealth appointment?

On a server that exposes an authenticated visit-booking tool, yes, and that tool should require fresh user consent on each call. MyOrbitHealth's public MCP server does not book visits; its two action tools request a demo or a callback, and appointments for patients are created through the authenticated product API.

Should I use MCP or the REST API for my integration?

Use MCP when an agent needs to discover and read without credentials, and the product REST API when your backend runs the integration deterministically with patient data. On MyOrbitHealth that means the public MCP server and agent API for research and the bearer-token API at api.myorbithealth.com/v1 with signed webhooks for the clinic.

Sources

• Model Context Protocol specification
• Anthropic: Introducing the Model Context Protocol
• MyOrbitHealth developers page
• MyOrbitHealth API docs
• Cuvo developer documentation
• 45 CFR 164.312, technical safeguards (eCFR)
• 21 CFR Part 1311, requirements for electronic orders and prescriptions (eCFR)
• RFC 9457: Problem Details for HTTP APIs

Point your agent at the platform, then talk to a human

Connect Claude Code or any MCP client to myorbithealth.com/mcp, read the developers page for the agent API and CLI, and let the agent do the research. When you are ready for the clinic itself, book a demo to walk through the product API, signed webhooks and React SDK with the team.