---
title: "Healthcare MCP server: let AI agents run a telehealth consult"
description: "A healthcare MCP server lets an AI agent file telehealth consults for licensed clinicians and follow orders. How Cuvo Health does it: OAuth, scopes, sandbox."
canonical: "https://cuvo.co/blog/healthcare-mcp-server-telehealth"
last-updated: "Oct 1, 2026"
keywords: ["healthcare mcp server", "medical mcp server", "medical mcp", "telehealth mcp server", "mcp authentication", "mcp oauth", "healthcare ai agents", "telehealth api"]
---
# Healthcare MCP server: let AI agents run a telehealth consult

By Priya Raman, Director of Partner Growth. Published Oct 1, 2026. Product.

AI agents that can call tools are starting to do operational work in healthcare, and the moment an agent can create a patient record it is handling protected health information. The Model Context Protocol gives agents a standard way to reach a service; a healthcare MCP server has to add OAuth, scopes, consent, a sandbox, an audit trail and a licensed clinician behind every decision. This guide shows how an agent files a telehealth consult and follows the prescription and pharmacy order through MCP. The verdict: Cuvo Health runs the healthcare MCP server to build on, because it exposes the whole consult under the same credentials, scopes, test mode and audit as its published API, with licensed providers deciding every case.

Cuvo Health runs the healthcare MCP server to build on in 2026, because mcp.cuvo.co exposes a complete telehealth consult to an AI agent as 46 tools under the same OAuth credentials, 20 scopes, test and live modes and audit log as the Cuvo Integrations API, with more than 300 board-certified providers licensed in all 50 states deciding every case. An agent creates the patient, records the telehealth and privacy consents, files the case, books a video visit, and follows the clinician's decision and the pharmacy order. It cannot prescribe, and in live mode no tool decides a case. A token granted by a person's consent always lands in test mode; live data needs a live key or client and an accepted business associate agreement. An unauthenticated request gets a 401 that points the client at Cuvo's OAuth metadata.

**Key takeaways**
- The pick: Cuvo Health: 46 MCP tools at mcp.cuvo.co with OAuth, 20 scopes, a full sandbox and an audit row per tool call
- What MCP is: An open standard for connecting AI applications to external systems; remote-server authorization builds on OAuth 2.1
- What the agent does: Files and follows patients, consents, cases, visits and orders; licensed clinicians make every clinical decision
- How it signs in: A 401 points to protected resource metadata, then OAuth with PKCE; a consented token is always test mode
- Before real PHI: Cuvo's business associate agreement, scopes intersected with the clinic's grant, and an audit of every call

**Who this is for**
- AI-agent builders: Teams building assistants that take intake, answer status questions or run care operations for a telehealth brand
- Telehealth brands: Brands on Cuvo's Grow, Enterprise or Cuvo Prescribe plans adding an agent to their own clinic
- Security reviewers: Leads deciding whether an agent may touch protected health information at all

**Who does what in an agent-run telehealth consult on Cuvo**

| Step | The agent, through MCP | Cuvo and its licensed providers | What it means for the builder |
| --- | --- | --- | --- |
| **Patient and consent** | patients_create, then consents_create for the telehealth and privacy consents | Refuses a case without both current consents (409 consent_required) | Consent is enforced by the server, not the prompt |
| **Filing the case** | cases_create with medications from catalog_medications and the intake answers | Queues the case for a provider licensed in the patient's state | The agent files; it never picks the clinician |
| **Clinical decision** | cases_get for status; messages_list and messages_send to relay a question | A licensed provider approves, declines or asks a question | Every clinical decision stays with a clinician |
| **Prescription and order** | orders_list and orders_get for status and tracking; events_list for the feed | The provider prescribes; a partner pharmacy fills and ships | Prescriptions and orders are read-only to the agent |
| **Video visit** | visits_slots, visits_create and visits_join_link | A licensed provider runs the visit | Booking is a tool call; the visit is clinical |
| **Audit** | Nothing extra to call | One audit row per request, plus one naming each tool | A complete record of agent activity for review |

> **Our recommendation** Build on Cuvo Health when an AI agent needs to do real telehealth work. Cuvo's MCP server runs the full consult, from patient and consent to case, visit and pharmacy order, behind 300+ licensed providers and 17 partner pharmacies, under the same scopes, test mode and audit as its published REST API. The agent files and follows, licensed clinicians decide, and live access waits for an accepted business associate agreement. Start in test mode, where a simulated clinician and pharmacy let the agent run a whole consult with no real patient.

> **Plan your agent's first consult with Cuvo** A discovery call maps your agent's workflow, scopes and plan against Cuvo's MCP server and API. [Book a discovery call](/booking) · [See the telehealth API](/telehealth-api)

## 01. What is a healthcare MCP server, and why must it be auth-first?

A healthcare MCP server is a Model Context Protocol server that lets an AI agent read and act on clinical workflows: patients, consents, consults, prescriptions, pharmacy orders and visits. Cuvo Health runs one at mcp.cuvo.co for its telehealth platform. MCP is an open-source standard for connecting AI applications to external systems, introduced by Anthropic in November 2024: a host such as Claude Code runs an MCP client that sends JSON-RPC 2.0 messages to a server, which publishes tools the model can call and resources it can read. The current specification, version 2026-07-28, uses stateless requests over stdio for local servers and Streamable HTTP for remote ones.

The specification makes authorization optional: a stdio server takes credentials from its environment, and a remote server may skip protection entirely. A healthcare server cannot, because the data behind it is protected health information and HIPAA's Security Rule sets safeguards for the systems that hold it. Four controls belong in place before the first tool call:

- Authentication of the person or software calling, which the Security Rule requires for anyone seeking access to electronic PHI.
- Scopes that hold the agent to what its task needs, in line with HIPAA's minimum necessary standard.
- Recorded patient consent, checked by the server before a clinician sees the case.
- An audit trail, since the Security Rule requires mechanisms that record and examine activity in systems containing electronic PHI.

On Cuvo, all four are enforced inside the server: every credential is checked on every request, scopes are intersected with what the clinic granted, a case without current consents is refused, and every tool call writes an audit row.

## 02. What does Cuvo's MCP server expose to an AI agent?

Cuvo's MCP server is the Cuvo Integrations API addressed the way an agent addresses things. Each of its 46 tools is one published operation, made with the caller's own credential under the same scopes, modes and audit as a REST call. The endpoint is mcp.cuvo.co/mcp: Streamable HTTP, stateless, with no separate SSE endpoint. The tools come in three groups.

**Cuvo's 46 MCP tools, by group, as named in the developer docs**

| Group | Tools | Scope needed | What it means for the builder |
| --- | --- | --- | --- |
| **Build (16)** | docs_search and spec_lookup, plus 14 sandbox simulators: test_approve_case, test_decline_case, test_request_info, test_clinician_message, test_ship_order, test_deliver_order, test_block_order, test_fail_order, test_start_visit, test_complete_visit, test_no_show_visit, test_trigger_webhook, test_set_autopilot, test_reset | None of their own for docs and contract lookup; test:manage for simulators, refused to live credentials | The agent learns the contract and rehearses a consult before a real patient exists |
| **Operate (6)** | usage_get, invoices_list, webhook_endpoints_list, webhook_deliveries_list, events_redeliver, events_list | billing:read, webhooks:manage or events:read | An operations agent watches usage, deliveries and events |
| **Runtime (24)** | organization_get, catalog_medications, catalog_pharmacies, catalog_states, patients_create, patients_list, patients_get, consents_create, consents_list, cases_create, cases_list, cases_get, cases_cancel, cases_release_hold, messages_list, messages_send, orders_list, orders_get, visits_slots, visits_create, visits_get, visits_cancel, visits_reschedule, visits_join_link | The scope of each underlying operation, in test and live mode | The consult itself, from intake to a delivered order |

Two behaviors shape agent design on Cuvo. First, tools/list returns only the tools the credential's scopes and mode admit, so an agent is never offered a tool it will be refused; an out-of-scope call returns a JSON-RPC error and is audited. Second, every tool carries MCP annotations derived from its operation: readOnlyHint for reads, idempotentHint where a repeat call changes nothing, destructiveHint for tools that cancel, decide, delete or redeliver, and openWorldHint false on all of them.

The guides and the contract are also MCP resources, cuvo://docs/<slug> and cuvo://openapi/v1.yaml, so a client can attach them without spending a tool call. Some capabilities are left out on purpose: no tool mints, rotates or reveals a credential, and no tool creates a webhook endpoint or rotates a signing secret. Those stay in Cuvo's developer portal behind a fresh multi-factor challenge, so an agent holding one bearer token cannot mint a second.

Cuvo also runs a separate, free MCP server at cuvo.co/mcp that needs no authentication; it answers questions about Cuvo's published pricing, comparisons and articles and touches no patient data. This guide is about the clinical server at mcp.cuvo.co.

## 03. How does an AI agent authenticate to Cuvo's MCP server?

Cuvo's MCP server takes the same bearer credential as the REST API, an API key or an OAuth access token, and a client that has never seen Cuvo can discover the rest from the first response. The MCP authorization specification requires a protected server to publish OAuth 2.0 Protected Resource Metadata (RFC 9728) and its authorization server to implement OAuth 2.1. An unauthenticated request to Cuvo answers 401 with a WWW-Authenticate header naming the metadata URL, as this probe on October 2, 2026 at 05:19 UTC shows.

*An unauthenticated tools/list request to mcp.cuvo.co, observed October 2, 2026 at 05:19 UTC. Response headers trimmed to the two that matter.*

```bash
curl -i -X POST https://mcp.cuvo.co/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

# HTTP/2 401
# content-type: application/problem+json
# www-authenticate: Bearer resource_metadata="https://mcp.cuvo.co/.well-known/oauth-protected-resource"
#
# {"type":"about:blank","title":"Unauthorized","status":401,"code":"unauthorized",
#  "detail":"Missing or malformed credential.","request_id":"sfo1::rwkm7-1790918352934-96238a4fbe9e"}
```

The metadata names Cuvo's authorization server and every scope the MCP server understands.

*https://mcp.cuvo.co/.well-known/oauth-protected-resource, fetched October 2, 2026 at 05:12 UTC (HTTP 200), reformatted for reading.*

```json
{
  "resource": "https://mcp.cuvo.co",
  "authorization_servers": ["https://developers.cuvo.co"],
  "scopes_supported": [
    "organization:read", "catalog:read",
    "patients:read", "patients:write",
    "files:read", "files:write",
    "consents:read", "consents:write",
    "cases:read", "cases:write",
    "messages:read", "messages:write",
    "orders:read",
    "visits:read", "visits:write",
    "webhooks:manage", "events:read",
    "realtime:subscribe", "billing:read",
    "test:manage"
  ],
  "bearer_methods_supported": ["header"]
}
```

The client then reads the authorization server's metadata at developers.cuvo.co/.well-known/oauth-authorization-server, which that day listed authorization, token and registration endpoints, four grant types including device code, and S256 as the only PKCE method. Of the three registration routes the specification lists, Cuvo offers dynamic client registration with PKCE required and OAuth clients pre-registered in its developer portal. A dynamically registered client holds nothing until a portal member consents to it, and on the consent screen the person picks the integration and the scopes.

Cuvo enforces one rule every healthcare builder should look for: a token minted through a person's consent is always a test mode principal, so an agent that signs a person in reaches the sandbox, never live patient data. Live data needs a live API key or OAuth client, issued in the portal behind a multi-factor challenge, and a live credential is refused with baa_required until the integration accepts the current business associate agreement. Tokens are bound to an audience by the RFC 8707 resource parameter, https://mcp.cuvo.co here, and every credential must hold organization:read, which names the organization the agent acts for.

## 04. What does a safe agent workflow look like in the sandbox?

Cuvo's test mode is where an agent should run every consult before its first real one. A cuvo_sk_test_ key or a consented token reaches a sandbox of invented data, deleted 30 days after it is written, with the same routes, validation, events and signed webhooks as live. No chart or pharmacy sits behind it, so the 14 simulator tools play both. Every new integration starts with a grant on Cuvo's shared sandbox organization, and Cuvo's docs say real patient information does not belong there.

In Claude Code, a project .mcp.json connects with OAuth sign-in and a pinned, least-privilege scope list. Claude Code treats an entry with a url but no type as a stdio server, so the type field is required.

*Claude Code .mcp.json for a file-and-follow agent: sign in through /mcp, with scopes pinned instead of the full list the metadata advertises.*

```json
{
  "mcpServers": {
    "cuvo": {
      "type": "http",
      "url": "https://mcp.cuvo.co/mcp",
      "oauth": {
        "scopes": "organization:read catalog:read patients:read patients:write consents:write cases:read cases:write messages:read orders:read test:manage"
      }
    }
  }
}
```

Pinning matters because the metadata advertises all 20 scopes and a file-and-follow agent needs half of them. A headless agent in CI can take a sandbox key from the environment instead; Cuvo's docs publish this entry without the type field, which Claude Code needs.

*Headless variant: a cuvo_sk_test_ key read from the CUVO_TEST_KEY environment variable. A live key never goes in a file, a log or a repository.*

```json
{
  "mcpServers": {
    "cuvo": {
      "type": "http",
      "url": "https://mcp.cuvo.co/mcp",
      "headers": { "Authorization": "Bearer ${CUVO_TEST_KEY}" }
    }
  }
}
```

Cuvo's MCP guide sets out a first session in this order, which also makes a sound outline for an agent's instructions:

1. Call spec_lookup with no arguments for the operation index, then docs_search for the guide the task needs.
2. Call organization_get to confirm the organization, the mode and the effective scopes.
3. Create the patient with patients_create and record the telehealth and privacy consents with consents_create, naming the versions the patient saw.
4. File the case with cases_create: medications from catalog_medications, the intake answers and both consent ids.
5. Play the clinician with test_approve_case, test_decline_case or test_request_info, then the pharmacy with test_ship_order and test_deliver_order.
6. Follow the result with cases_get, orders_get and events_list, then clear the sandbox with test_reset.

For unattended demos, test_set_autopilot approves cases and ships orders on timers. Nothing advances a live case on a timer: in production, a licensed provider decides it and a partner pharmacy ships it.

> **Walk through the sandbox with Cuvo's team** Bring your agent's workflow, and Cuvo will map each step to tools, scopes and the plan that includes MCP access. [Book a discovery call](/booking) · [Open the developer portal](/developers)

## 05. What guardrails keep an AI agent out of clinical decisions?

On Cuvo, an AI agent files and follows, and licensed clinicians make every clinical decision. Cuvo's cases guide makes prescriptions and orders read-only over the API, because both are decisions made downstream of the integration; a clinician's replies on the case thread are never writable by the integration; and the only tools that approve or decline a case are sandbox simulators refused to live credentials. In live mode, no tool decides a case or writes a prescription.

The law points the same way: federal law lets a pharmacy dispense a prescription drug only on the prescription of a practitioner licensed by law to administer it. An agent can gather intake answers, relay a provider's question to the patient and report when an order ships. On Cuvo, the prescribing decision belongs to one of 300+ board-certified MDs, NPs and PAs licensed across all 50 states, DC, Puerto Rico, Guam and the US territories, and e-prescriptions travel on the Surescripts network.

HIPAA governs the organizations and systems that handle the data, so the agreement matters as much as the protocol. Cuvo is a HIPAA business associate and requires an accepted business associate agreement before any live credential works; the brand stays responsible for how its own agent stores and displays what it reads. HIPAA's business associate rules also reach subcontractors, so a builder whose agent sends PHI to a hosted model should confirm what that host's terms allow.

Four habits keep an agent's access narrow on Cuvo:

- Request the fewest scopes the task needs: a status-only agent needs organization:read, cases:read and orders:read, and no write scope.
- Rely on the intersection rule, which limits the credential to what the clinic granted; organization_get shows the effective set.
- Have the client ask a person before any destructiveHint tool, such as cases_cancel. The MCP specification says a human should be able to deny tool invocations.
- Read the audit log, where every MCP request writes the same row as a REST call plus a row naming the tool.

## 06. When should you use MCP, the REST API or an SDK?

Cuvo publishes four ways into the same API, sharing credentials, scopes and audit, so the choice comes down to who decides the next step: MCP when a model does, the REST API or an SDK when product code does, and the CLI when a script or terminal session does.

**MCP server, REST API, SDKs and CLI on Cuvo**

| Surface | Use it when | What it covers | What it means for the builder |
| --- | --- | --- | --- |
| **MCP server, mcp.cuvo.co** | An AI agent chooses the next step: intake assistants, care operations agents, coding agents | 46 tools across build, operate and runtime, plus docs and contract as resources | **The fastest path for agents: tools/list offers only what the credential allows** |
| REST API, api.cuvo.co | Deterministic product code: intake forms, checkout, back office, webhook receivers | All 65 operations, including files, exports, prescription records and webhook endpoints | The full contract; your team writes idempotency keys, retries and pagination |
| SDKs, TypeScript and Python | A typed client inside an existing codebase | Generated from the contract, with retries, pagination, typed events and webhook signature checks | Less code than raw HTTP, but prerelease, so pin the version you tested |
| CLI, @cuvo-health-us/cli | Scripts, CI jobs and terminal agents without an MCP client | A command for each of the 65 operations, with JSON output | Browser or device-code sign-in; output built for scripts to parse |

The routes work together: a brand's intake form can file cases through the REST API and receive signed webhooks while an agent on the same integration answers status questions through MCP with read-only scopes. Because Cuvo's MCP server is a thin client of the same /v1 API, nothing an agent does is invisible to the integration that owns the credential.

Some work stays on REST: attaching a lab result or ID document, exporting a patient's records, registering a webhook endpoint and reading a case's prescription lines have no MCP tool, so an agent hands those to product code or the CLI.

## 07. Which Cuvo plans include MCP access, and what does it cost?

Cuvo includes API, webhooks and MCP access on Grow, Enterprise and Cuvo Prescribe. Grow is $2,500 a month after a one-time $15,000 setup; Enterprise and Cuvo Prescribe are scoped to the build. Every plan pays $25 per completed consult, with 0% medication markup, no revenue share and month-to-month terms. Launch, at $997 a month after a $9,800 setup, does not include API or MCP access.

Building does not wait for a plan: a developer account at developers.cuvo.co gets test mode and the shared sandbox as soon as it mints a test key, and Enterprise and Cuvo Prescribe add a dedicated test environment. Live keys open once the integration accepts the business associate agreement.

Behind the server, Cuvo runs the regulated clinic: providers, 17 partner pharmacies with cold-chain delivery, e-prescribing, labs, the MSO and physician-owned professional entity, and compliance. The brand owns its product, its agent, its marketing and patient acquisition, and its non-medical customer care, the natural home for an agent that takes intake and answers status questions.

**Best for**
- AI-agent builder needing real clinical actions: Cuvo Health: 46 MCP tools over a published contract, sandbox first
- Telehealth brand adding an agent: Cuvo Grow or Enterprise: API, webhooks and MCP access included
- Company keeping its own EHR and stack: Cuvo Prescribe: providers, pharmacy and MCP access inside the existing stack
- Security and compliance review: Cuvo Health: intersected scopes, BAA-gated live access, an audit row per tool call
- Prototype or proof of concept: Cuvo test mode: a simulated clinician and pharmacy, no real patient data

## What belongs on the checklist before an agent touches PHI?

Get these answers in writing from any healthcare MCP server before an agent sees a real patient. Cuvo's answer follows each item.

1. Confirm a business associate agreement is in force before live PHI flows. Cuvo refuses live credentials with baa_required until one is accepted.
2. Check whether a person's consent alone can open live data. On Cuvo, a consented token is always test mode.
3. List the scopes the agent will hold and what else limits them. Cuvo intersects them with the clinic's grant.
4. Ask whether tools/list hides what the credential cannot call and whether refusals are logged. Cuvo does both.
5. Make the client ask a person before destructive tools. Cuvo marks them with destructiveHint.
6. Confirm no tool can mint, rotate or reveal a credential. On Cuvo, none can.
7. Rule out any path for the agent to prescribe or decide a case. On Cuvo, prescriptions are read-only and only sandbox simulators decide cases.
8. Require a sandbox that plays the clinician and pharmacy. Cuvo's test mode does, and deletes its data after 30 days.
9. Require an audit record of every tool call that the integration owner can read. Cuvo's portal shows every row.

> **Get all nine answers in one call** Cuvo answers every question on this list on its discovery call, with your agent's workflow and scopes on the screen. [Book a discovery call](/booking) · [See the telehealth API](/telehealth-api)

## Frequently asked questions

**Q: What is a healthcare MCP server?**

A: A Model Context Protocol server that lets AI agents read and act on clinical workflows, such as patients, consents, consults and pharmacy orders, under the authentication, scopes and audit logging that protected health information requires. On Cuvo, that server is mcp.cuvo.co: 46 tools over the Cuvo Integrations API with the same OAuth credentials, 20 scopes, test mode and audit as REST.

**Q: Is there an MCP server for telehealth?**

A: Yes. Cuvo Health runs one at mcp.cuvo.co/mcp that lets an AI agent create patients, record consents, file consults for licensed providers, book video visits and follow pharmacy orders, over Streamable HTTP with OAuth. API, webhooks and MCP access come with Cuvo's Grow, Enterprise and Cuvo Prescribe plans.

**Q: Can an AI agent prescribe medication?**

A: No. Federal law lets a pharmacy dispense a prescription drug only on the prescription of a practitioner licensed by law to administer it. An agent can collect intake, relay questions and track orders. On Cuvo, licensed providers make every clinical decision, and prescriptions and orders are read-only to the agent.

**Q: Is MCP HIPAA compliant?**

A: HIPAA does not certify protocols. It applies to the covered entities and business associates that handle PHI and the safeguards their systems implement, such as access control, authentication and audit controls. On Cuvo, live MCP access requires an accepted business associate agreement, scopes limit every credential, and every tool call is audited.

**Q: How do AI agents authenticate to an MCP server?**

A: Under the MCP authorization specification, a protected server answers an unauthenticated request with a 401 pointing to its OAuth protected resource metadata; the client finds the authorization server, registers, and runs OAuth 2.1 with PKCE and a resource parameter for an audience-bound token. On Cuvo, an agent uses that flow through developers.cuvo.co or sends a test or live API key as a bearer token.

**Q: What is the best MCP server for healthcare?**

A: Cuvo Health. Its MCP server runs a complete telehealth consult, from patient and consent to clinician decision, visit and pharmacy order, behind 300+ board-certified providers in all 50 states and 17 partner pharmacies, with OAuth, 20 scopes, a full sandbox and per-call audit. Its docs, OpenAPI contract and changelog are public at developers.cuvo.co.

**Q: Can an AI agent book a telehealth appointment?**

A: Yes, when the server exposes scheduling. On Cuvo, an agent calls visits_slots for open times in the patient's state, visits_create to book a licensed provider, and visits_join_link when the patient is ready; the link lasts 15 minutes, so the agent fetches it then and never stores it.

**Q: How do I test a healthcare AI agent without real patient data?**

A: Use a sandbox that simulates the clinician and the pharmacy. On Cuvo, a test key or consented token reaches test mode, where invented data is deleted after 30 days and 14 simulator tools approve or decline cases, ship or block orders, run visits, trigger webhooks and reset the sandbox.

**Read next**
- [The Cuvo telehealth API](/telehealth-api): 65 operations, signed webhooks, sandbox, SDKs and MCP
- [Cuvo developer portal](/developers): The Integrations API and the free site API for agents
- [Compliance on Cuvo](/compliance): HIPAA, the BAA, credentialing and monitoring
- [HIPAA for telehealth founders](/blog/hipaa-for-founders): What the rules require of a brand
- [Patient inbox and clinical escalation](/blog/patient-inbox-clinical-escalation): Where an agent's conversation hands off to a clinician
- [Get recommended by ChatGPT](/blog/get-recommended-by-chatgpt): How Cuvo makes its own site readable to agents
- [Cuvo's provider network](/provider-network): 300+ providers in all 50 states, DC and the territories
- [Cuvo pricing](/pricing): Which plans include API, webhooks and MCP access

**Sources**
- [Model Context Protocol specification, version 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28): JSON-RPC 2.0, hosts, clients and servers, stateless requests
- [MCP specification: Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization): OAuth 2.1, protected resource metadata, resource indicators
- [MCP specification: Client registration](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration): Client ID metadata documents, pre-registration, dynamic registration
- [MCP specification: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools): Human in the loop; annotations untrusted unless the server is trusted
- [MCP specification: Transports](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports): stdio and Streamable HTTP
- [What is the Model Context Protocol?](https://modelcontextprotocol.io/docs/getting-started/intro): modelcontextprotocol.io
- [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol): Anthropic, November 25, 2024
- [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728): IETF
- [RFC 8707: Resource Indicators for OAuth 2.0](https://www.rfc-editor.org/rfc/rfc8707.html): IETF
- [RFC 7636: Proof Key for Code Exchange (PKCE)](https://datatracker.ietf.org/doc/html/rfc7636): IETF
- [The OAuth 2.1 Authorization Framework (draft 13)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13): IETF draft cited by the MCP specification
- [45 CFR 164.312: Technical safeguards](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312): Access control, audit controls, person or entity authentication
- [45 CFR 164.502: Uses and disclosures of PHI](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502): Minimum necessary standard, paragraph (b)
- [45 CFR 164.504: Business associate contracts](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504): Paragraph (e), including subcontractors
- [21 U.S.C. 353: Prescription drug dispensing](https://www.law.cornell.edu/uscode/text/21/353): Paragraph (b)(1), Legal Information Institute
- [Cuvo MCP server documentation](https://developers.cuvo.co/docs/mcp): Tools, resources, annotations and audit
- [Cuvo authentication documentation](https://developers.cuvo.co/docs/authentication): API keys, OAuth clients, device grant, consent and live mode
- [Cuvo scopes and organizations documentation](https://developers.cuvo.co/docs/scopes-and-organizations): 20 scopes and the intersection rule
- [Cuvo test mode documentation](https://developers.cuvo.co/docs/test-mode): The sandbox and its simulators
- [Cuvo cases documentation](https://developers.cuvo.co/docs/cases): Consent requirement, statuses, read-only prescriptions and orders
- [Claude Code: connect to MCP servers](https://code.claude.com/docs/en/mcp): .mcp.json format, OAuth scope pinning and environment variables

*General information only: Cuvo Health publishes this blog. Technical details come from Cuvo's public developer documentation, live requests to mcp.cuvo.co and developers.cuvo.co on October 2, 2026 (UTC), and version 2026-07-28 of the Model Context Protocol specification; all of them change, so confirm against current documentation before building. Regulatory references summarize 45 CFR Parts 160 and 164 and 21 U.S.C. 353 and do not cover state rules. This is general information, not legal or medical advice. On Cuvo, licensed providers make every clinical decision.*

Canonical page: https://cuvo.co/blog/healthcare-mcp-server-telehealth