Let an AI agent work with your practice data

If you run a practice rather than write code

You do not need this page to use AI in HyperCRM. The assistant built into the product is on both plans, needs no setup, and is the one most practices want. This page is for connecting your own AI app — Claude or ChatGPT, say — to your practice's data, so you can ask it things in the app you already use.

What that means in practice. Any member can connect their own app, and it acts with exactly their role's permissions: a receptionist's connection sees what a receptionist sees. Asking it about a patient sends that patient's details to whichever AI company you connected, under your own agreement with them, so it is your practice's decision to make and to tell your team about. These calls spend no credits. To see or remove a connection, go to Settings, then Account, then Connected apps.

Which plan this needs

The REST API and the MCP server are included on the Complete plan and are not available on Essential. The pricing page lists every band. An OAuth client is not created in settings: it registers itself the first time it connects, and an owner on Complete approves it. Settings is where you see what is connected and disconnect it.

What it is

The MCP server speaks JSON-RPC 2.0 over a single HTTP endpoint, following the same streamable-http transport pattern used by other MCP servers. An MCP client calls initialize, lists the available tools with tools/list, and invokes one with tools/call — no custom protocol to learn beyond MCP itself.

Signing in an agent

Connecting is a standards-based OAuth 2.1 flow: the client registers itself automatically (no manual API key to generate), opens HyperCRM's normal sign-in and a plain-language consent screen — "<client name> wants to access your HyperCRM data as <your email>" — and, once approved, receives a short-lived access token plus a refresh token. A raw Firebase ID token still works too, for setups that predate the OAuth flow. Every tool call is scoped strictly to the signed-in user's own practice; nothing in the request can override that.

Approving a connection asks three things of the person doing it: the practice is on Complete, their own email address is verified, and they signed in within the last ten minutes — a second factor presented this morning is not evidence that anyone is at the keyboard now. An approval lasts 90 days. After that the app asks again, however often it has refreshed in between.

What the tools do today

75 tools cover patients and their notes, files, billing and invoices; the appointment calendar and chair availability; the service catalogue, chairs and tags; intake forms and their responses; staff and invitations; dashboard KPIs, revenue and acquisition reporting, the audit log and search across the practice; and the practice website with its blog. 47 are read-only. The rest are grouped so that creating, updating and deleting one kind of record is a single tool with an explicit action, and every tool tells the client up front whether it deletes data or reaches outside HyperCRM.

Where the boundaries are

A few things are deliberately left out rather than half-supported. Uploading a file is a browser-to-storage transfer that never passes through the server, so an agent cannot do it — it can read, download and delete files, but you upload them yourself. The public booking widget, the passkey enrolment ceremonies and the OAuth endpoints an agent uses to sign in are all absent by design. CSV export stays a REST API feature; MCP tools always return structured JSON.

Scope, and what is not finished

No tool can be pointed at another practice: the practice comes from your token, never from a tool argument. Two things are genuinely unfinished: no MCP resources or prompts are exposed yet, and the server has not been through a broad real-world shakedown across every client. The full reference is at MCP server, and every one of the 75 tools is listed with its arguments and permissions at MCP tools.