The Coralia MCP Connector: Connecting ChatGPT or Claude to Coralia
Reviewed 2026-08-31 · 14 min read · Coralia Compliance Guides
Coralia publishes a remote Model Context Protocol (MCP) endpoint at https://coralia.app/api/mcp. Version 2 is implemented behind a fail-closed deployment approval: it is not enabled for PHI-capable use until the exact private workspace, retention controls, complete data path, and business associate agreement have been approved. When enabled, v2 replaces seven narrow permissions with two understandable capability families: coralia.context for live, role-authorized Coralia context, and coralia.prepare for reversible preparation that a clinician explicitly requests. Its surface has seventeen tools. Six form a rich context layer for resolving the exact session, understanding a shift, reading one session's current state, reading Sentinel status, listing the caseload that needs attention, and reading one client's case context. Five focused tools read pending documentation, measured session facts, child progress, progress reports, and work still owed. One reads the clinician's supervision standing and what the people they are responsible for still owe, and one is a live directory of what this exact connection can currently ask. Two tools write drafts under a unique operation ID and durable receipt: one saves a narrative into an empty session note, and one saves drafted prose into still-empty, named progress-report sections. One records a request that asks a person in Coralia to act — it decides nothing. One more confirms whether a write this assistant made actually landed, without returning what it said. External submit has been removed: the connector never signs, clocks, approves, attests, or files clinical documentation. Because first name plus exact agency-local date and time can identify a child and visit, this is a PHI-capable connection intended only for a private or workspace-managed AI environment whose contract, retention controls, and business associate agreement cover the full data path.
Version 2 asks for two capability families
The consent screen presents one clear connection decision with two plain-language families. coralia.context lets the assistant read and analyze the Coralia work the clinician's current role can already access, including exact local service identity, measured clinical data, documentation state, work queues, and Sentinel guidance. coralia.prepare lets the assistant prepare reversible work when explicitly asked, beginning with saving a draft into an empty session note.
A scope is only a ceiling. Every call still rechecks the stored connection, approved client, agency switch, active membership, active clinician profile, current Coralia role, tenant, caseload, and object access. The assistant cannot select another agency or widen the user's Coralia permissions.
Connections created before v2 keep the original OAuth grant as an immutable record; Coralia never rewrites history as though the clinician accepted different text. Once the PHI-capable path is approved, an authorized agency administrator can approve the current manifest once for explicitly selected live connections. A newly connected v2 account also stays pending until the administrator selects that exact connection and confirms its private or agency-managed boundary; personal OAuth consent alone never activates PHI-capable tools. The connection updates automatically without reconnecting on its next token rotation: no 401, disconnect, browser redirect, or clinician action. Later tools may improve inside the accepted agency manifest, while a materially broader data category or action requires a new central administrative decision.
- coralia.context — read and analyze only context the current Coralia role and object rules already allow
- coralia.prepare — prepare reversible work on explicit request; never sign, clock, approve, attest, or submit
- A legacy connection keeps its original surface while v2 is dark and upgrades automatically only after the agency approves that exact connection
- Disconnecting revokes the stored connection; no new capability is silently added to an existing grant
The seventeen tools in the v2 surface
Fourteen tools only read — twelve from Coralia's clinical and business records, one from the connector's own operation receipts, and one from its own capability directory — and each must write a required access/disclosure audit row. Their annotations therefore honestly say readOnly false while remaining non-destructive and inside Coralia's closed first-party system. save_note_draft and save_structured_draft are the clinical-content writes; each refuses to overwrite existing words and uses a durable idempotent operation receipt. request_coralia_action records one request for a person in Coralia under the same receipt discipline; it decides, books, and approves nothing.
The first six tools are the v2 context layer. They return explicit structured data plus a text fallback, preserve exact local date and time, and pass opaque handles rather than raw database identifiers. The other seven remain available for focused documentation workflows.
| Tool | What it does | Authorization |
|---|---|---|
| resolve_coralia_reference | Resolves first name plus exact agency-local service date and start time to one authorized session. Ambiguity is returned rather than guessed; success includes a human label, ref_ handle, timezone, and PHI-free Coralia deep link. | coralia.context plus live session-view and object access |
| get_my_shift | Returns the clinician's live local day: exact sessions, authorized team context, unfinished documentation, signatures, work, and next actions. | coralia.context plus live role and object access |
| get_session_context | Returns one resolved session's service identity, lifecycle, clock state, note readiness and gaps, and provenance. It excludes narratives and raw record IDs. | coralia.context plus a current ref_ handle and live access |
| get_sentinel_status | Returns authoritative Sentinel review and revision-check state, freshness, outcomes, and finding counts. It never invents or returns corrected prose. | coralia.context plus a current ref_ handle and live access |
| list_my_caseload | Returns the clinician's own caseload — assigned, supervised and covered — ordered by what needs attention, with an opaque client handle and the reason for each row. It never returns another clinician's cases or the whole agency, even for an administrator, and it states how many cases it left out. | coralia.context plus live client-view and object access |
| get_client_context | Returns one caseload client's measured progress over 30 or 90 days with the prior period, program status by position, care team, documentation and Sentinel state, this week's approved hours against what was delivered in the clinician's own lane, and the next scheduled session. Same-name children are returned as choices, never guessed. | coralia.context plus a current ref_ handle or first name, and live access |
| list_pending_notes | Lists sessions the clinician delivered whose note is missing or returned, with bounded results and opaque handles. | Current context capability or compatible legacy session-read scope |
| get_session_facts | Returns measured facts and documentation context for one pending session without inventing what happened in the room. | Current context capability or compatible legacy session-read scope |
| get_child_progress | Returns authorized measured progress for a child the clinician treats, grouped by program. | Current context capability or compatible legacy scopes |
| get_progress_report | Returns authorized measured and completion context for a progress report, with explicit data-quality omissions when a stored snapshot is malformed; it does not write the report. | Current context capability or compatible legacy report-read scope |
| list_work_owed | Returns role-authorized work queues, including documentation, signatures, supervision, review, and progress-report work. | Current context capability or compatible legacy work-read scope |
| save_note_draft | Saves one narrative only while the note is provably empty, reads it back, and returns a durable audit receipt. It never signs or submits. | coralia.prepare or compatible legacy draft scope, plus live edit and object access |
| get_action_status | Returns the state of one write this connection made — landed, still finishing, or failed — with what the action did and when it was requested and settled. It never returns the drafted text, the child, or the visit. | coralia.prepare or compatible legacy draft scope — the union of the write tools' authorizations |
| get_supervision_context | Returns where this clinician stands on supervision and what the people they are responsible for still owe — work aggregates per supervisee, never a roster, never a child's chart, never a note's text. | coralia.context plus the supervision relationship as the object filter |
| get_coralia_capabilities | Returns what this exact connection can currently ask Coralia, tool by tool, with routing hints and a what-changed block — the one surface that can announce a capability added after a host cached its catalogue. | coralia.context; it reads no clinical record |
| save_structured_draft | Saves drafted prose into named, still-empty progress-report sections as a draft, all-or-nothing under one operation ID and durable receipt. It refuses occupied sections, signed reports, and imported ABM content; it never signs or files. | coralia.prepare plus live report authorship and object access |
| request_coralia_action | Records one request that asks a person in Coralia to do something the connector may never do itself, routed by Coralia's own relationships to a role, never a name. It decides nothing and is not evidence anyone read it. | coralia.prepare; a reportable event is refused and belongs in the incident workflow |
Exact identity, opaque handles, and safe deep links
The supported workflow deliberately uses the child's first name plus exact agency-local service date, start time, end time, and timezone. Those fields are necessary to keep two visits from being confused; hiding the date or time would make the model more likely to discuss or draft for the wrong record.
A successful resolution mints a random ref_ handle valid for 24 hours. It is bound to the connection, agency, entity type, entity ID, and expiry, and encodes no child, visit, or database identifier. Redeeming it rechecks the tenant and object.
The returned /mcp/open/ deep link contains only that handle. Opening it requires a signed-in Coralia user and rechecks the user's agency, live connection, tenant-scoped session, and client access before redirecting. A denied or expired link falls back to the dashboard rather than revealing whether another record exists.
What data can leave Coralia
The exact output depends on the tool and the caller's live role. It can include a child's first name; care-team first names; age in years (or a 90+ age band) and recorded sex only when the role includes clients.view_phi; exact local service date, start and end time, and timezone; procedure and location; measured program data; session, clock, documentation, work, progress-report, and Sentinel state; and limited role-authorized team context. Each tool has an explicit output schema and records disclosure categories and safe identifiers, never PHI values, in the audit ledger.
The connector does not return last names, dates of birth, addresses, phone numbers, insurance identifiers, case numbers, credentials, raw database IDs, or unrelated records. The rich context tools exclude note narratives and Sentinel correction prose. Coralia cannot control PHI a clinician manually types or pastes into an AI conversation.
First name plus exact visit date and time makes this a PHI-capable connection. Use it only in a private or workspace-managed ChatGPT or Claude environment whose applicable contract, retention settings, subprocessors, and business associate agreement cover the complete connector path. Developer mode proves interoperability, not HIPAA coverage. Do not submit or use this PHI-capable connector as a public directory plugin.
- Minimum necessary data only, tied to a named tool and explicit output schema
- No PHI in logs, support screenshots, review credentials, public demos, or compatibility tests
- Synthetic records only for testing and vendor review
- The agency must verify the exact vendor workspace and contractual coverage before enabling production use
The only content write is an idempotent draft
save_note_draft accepts an opaque session handle, the finished narrative, and a newly generated lowercase UUID v4 as operationId. That identifier contains no name, date, or clinical fact. It refuses empty or oversized text, an unreadable or occupied note, an incompatible note shape, missing access, or a session the ordinary Coralia edit workflow would not accept.
Before writing, Coralia creates a durable receipt tied to the connection, action, session, operation ID, and content hash. After writing, it reads the stored note back, verifies the stored hash, completes the receipt, and returns auditReceiptId plus idempotentReplay. Retrying the exact same operation returns the same durable result instead of writing twice; reusing the operation ID for different content or another record is a conflict.
This saves copying and pasting only. The note remains a draft. submit_note has been removed and there is no replacement submission tool. The clinician opens the exact note in Coralia, reads it, completes anything still missing, signs where required, and submits it through the ordinary product workflow.
Authentication, connecting, and revocation
The endpoint uses stateless Streamable HTTP and OAuth authorization code with PKCE S256. It publishes protected-resource and authorization-server metadata, binds tokens to https://coralia.app/api/mcp, accepts bearer tokens in the Authorization header, and publishes no dynamic registration endpoint.
Coralia accepts Client ID Metadata Documents only from exact reviewed ChatGPT/OpenAI and Claude/Anthropic hosts. HTTPS callbacks must stay on the metadata document's own origin; native loopback callbacks are the only exception and receive an explicit device warning. This allowlist says which client identities Coralia recognizes; it does not promise that every vendor plan, workspace, device, mobile app, or interface exposes custom connector setup.
Use the vendor workspace's current private or custom MCP connection flow and enter https://coralia.app/api/mcp. Vendor labels, account eligibility, administrator controls, mobile behavior, and approval menus change independently, so follow current vendor documentation for that exact workspace rather than a screenshot copied from this page.
OAuth consent and per-tool approval are different controls. Coralia asks once for its two capability families and does not add repeated permission prompts, while its tool annotations remain honest about required audit bookkeeping and the draft write. ChatGPT or Claude may still ask according to account, workspace, role, surface, and administrator policy; Coralia neither promises nor bypasses those host controls.
For an existing connection, a normal Coralia upgrade never requires the clinician to reconnect. The agency administrator approves a managed manifest once, Coralia preserves the person's original grant, and the next automatic token rotation makes the approved tools available. Access tokens remain short-lived, refresh tokens rotate on every use, and live agency, staff, role, caseload, and object checks remain in force.
A clinician can disconnect under Settings → Connected apps, and an administrator can disable the agency channel. The client approval, agency switch, membership, clinician profile, stored scopes, uncached role permissions, and object access are rechecked on requests. Agency disablement and staff offboarding permanently revoke connections and credentials; turning access back on never revives an old grant.
- Endpoint: https://coralia.app/api/mcp
- Protected resource metadata: https://coralia.app/.well-known/oauth-protected-resource
- Authorization server metadata: https://coralia.app/.well-known/oauth-authorization-server
- No API key, shipped client secret, or dynamic registration endpoint
Where this connector stops
It never signs, clocks in or out, attests, approves, files, deletes, or invents a clinical fact. It does not return an agency-wide export or bypass caseload and role rules. It cannot know what happened in the room unless the clinician supplies that information, and a model must not infer it from measurements.
It is a governed clinical workflow, not a general-purpose API. The current client allowlist and seventeen tools are implementation facts reviewed on the date below, not a claim that a vendor has reviewed Coralia, supports it on every surface, or guarantees a particular approval experience.
How Coralia handles this
This guide was reconciled on August 31, 2026 against Coralia connector v2 source: two current capability families, seventeen registered tools, six rich context query tools, generic ref_ handles and safe deep links, the idempotent write receipts, the recorded-request landing lane, removal of external submit, and agency-managed zero-touch upgrades for existing connections. Implementation does not equal PHI rollout: the independent v2 deployment approval remains fail-closed until the exact workspace and complete data path are approved. Vendor UI, plan, mobile, approval, retention, and HIPAA claims are deliberately not inferred from Coralia's allowlist and require separate current verification.
Frequently asked questions
What is the Coralia MCP server URL?
https://coralia.app/api/mcp. Enter it in the current private or custom MCP setup flow for an eligible ChatGPT or Claude workspace. Coralia publishes OAuth discovery from its well-known protected-resource and authorization-server endpoints.
What permissions does Coralia connector v2 request?
Two capability families in one clear consent: coralia.context for live, role-authorized Coralia context, and coralia.prepare for reversible work explicitly requested by the clinician. Existing connections are never forced through setup again for a normal upgrade: an authorized agency administrator approves the current manifest for selected connections, and their next automatic token rotation applies it without changing the original grant.
How many MCP tools does Coralia expose?
The implemented v2 surface has seventeen. Six rich context tools resolve an exact session, describe the clinician's shift, return one session's current context, return Sentinel status, list the caseload that needs attention, and return one client's case context. Five focused tools read pending notes, measured session facts, child progress, progress reports, and work owed. get_supervision_context reads supervision standing and supervisees' owed work, and get_coralia_capabilities is a live directory of what the connection can ask. save_note_draft and save_structured_draft are the content writes, request_coralia_action records a request for a person, and get_action_status reports whether one of those writes actually landed. Until the separate PHI-capable deployment approval and agency-managed manifest are active, an existing connection keeps only its original compatible surface; approval upgrades selected connections automatically without involving the clinician.
Can the connector submit or sign a note?
No. submit_note has been removed. The connector can save a narrative only as a draft in a provably empty note. The clinician opens Coralia, reads and completes the record, signs where required, and submits it through the ordinary workflow.
What makes save_note_draft safe to retry?
Each call carries a unique operationId. Coralia stores a durable receipt tied to the connection, session, action, and content hash, reads the saved note back, and returns auditReceiptId and idempotentReplay. An identical retry recovers the same result; conflicting reuse is refused.
What patient data can the connector send?
Only fields declared by the selected tool and allowed by live role and object access. The supported workflow deliberately includes first name and exact agency-local service date, start and end time, and timezone so the correct visit can be identified. Age in years (or a 90+ age band) and recorded sex appear only when the caller's live role includes clients.view_phi; otherwise both are omitted. It can also include the minimum measured and workflow state needed by that tool. It does not return last names, dates of birth, addresses, phone numbers, insurance IDs, case numbers, credentials, raw database IDs, or unrelated records.
Do existing users have to reconnect when Coralia improves the MCP?
No. The connection keeps the scopes originally accepted as historical evidence. After the PHI-capable path is approved, an authorized agency administrator can apply the current manifest to selected live connections once. Coralia delivers it during automatic token rotation, so the clinician does not disconnect, reinstall, visit an office, or repeat OAuth. Voluntary disconnect, offboarding, detected credential theft, or a credential deleted by ChatGPT or Claude remain real security events and are not silently reversed.
Can this connector be used with PHI in a public plugin directory?
No. First name plus exact visit date and time makes the connection PHI-capable. Use it only in a private or workspace-managed environment whose contract, retention controls, subprocessors, and business associate agreement cover the full path. Developer mode or a successful connection does not establish HIPAA coverage or public-directory eligibility.
Does Coralia guarantee connector setup on every ChatGPT or Claude plan or device?
No. Coralia currently recognizes client metadata only from exact reviewed ChatGPT/OpenAI and Claude/Anthropic hosts. Vendor account eligibility, workspace policy, setup screens, mobile availability, and tool approvals are controlled by each vendor and must be verified in its current documentation.
This guide is educational content, not legal or billing advice. Requirements vary by payer and state and change over time — always confirm against your payer contracts, your state Medicaid program, and current BACB publications.