If your practice runs on IntakeQ or PracticeQ, you've probably tried to use Claude with patient-facing work and run into the same friction: the data lives in your IntakeQ account and Claude has no way to reach it. The workaround most practices use is copy-paste: pull a client's intake responses or appointment notes out of IntakeQ and paste them into Claude.
That works for one-off tasks. It fails the moment you want anything that touches multiple clients, runs on a recurring basis, or needs to write back a note or appointment update. And it produces no audit trail of what the AI saw, which is a problem for HIPAA compliance.
An MCP server solves this. As of July 2026, no one had shipped one for IntakeQ. So we built one.
Short answer
- What it is: the first open-source MCP connector for IntakeQ and PracticeQ. Claude reads your clients, appointments, forms, notes, and invoices through your own IntakeQ API key. Every PHI access logged locally. Nothing routed through us.
- Get it free:
npm install -g @oktopeak/intakeq-mcp - Don't want to configure the API key, audit-log destination, and HIPAA setup yourself? We deploy it in your practice with a fixed-price proposal.
Why IntakeQ specifically
Most behavioral health and healthcare platforms put a wall in front of their API. AdvancedMD, NextGen, and athenahealth all require you to go through a sales-approved partner program before you can generate an API key. That process takes weeks, costs money, and is designed to filter out everyone who isn't building a commercial product to resell to their clients.
IntakeQ does not do this. You generate an API key from your own account settings. The whole process takes two minutes and requires nothing from IntakeQ's side except your account being active.
The second thing IntakeQ does that most platforms don't: it includes a Business Associate Agreement on every plan. You sign it inside your account. You don't negotiate it, you don't request it from a compliance team, and you don't wait. This is the document that makes it legal under HIPAA to build a connector that processes patient content at all. Without a BAA covering the connection layer, there is no compliant path forward regardless of how good the audit logging is.
Those two facts together (self-serve API key, self-serve BAA) are why we built for IntakeQ first rather than the larger platforms. The compliance path is actually open.
What MCP changes
MCP (Model Context Protocol) is Anthropic's open standard for letting Claude talk to external systems. An MCP server is a small program that runs locally on your computer, holds credentials for one specific service, exposes a defined set of tools to Claude, and returns results inside your Claude session.
The architecture is the point. With the IntakeQ MCP server running:
- The server runs on your own machine. Your IntakeQ API key lives in an encrypted file under
~/.oktopeak-intakeq/, not on a third-party server. - Claude reads IntakeQ data through your own API key using the same calls any sanctioned integration would make. Nothing screen-scrapes, nothing sits between IntakeQ and Claude except code running on your computer.
- Every tool call that touches patient data writes a line to a local audit log: timestamp, tool name, which client or record was accessed, your IntakeQ practitioner ID. The log is append-only. It is what a HIPAA compliance review wants to see if you are asked to demonstrate AI use of PHI.
- No data passes through Oktopeak. The server is open-source code your practice runs. It does not call home.
What the connector covers
The connector exposes tools across the core IntakeQ resource areas a behavioral health practice actually uses day-to-day: clients, appointments, intake forms, consultation notes, practitioners, invoices, and tags. Read access spans everything; writes are deliberately limited to a small set of low-risk operations (see next section).
| Resource area | What Claude can do | Access type |
|---|---|---|
| Clients | Search by name or email, retrieve full client record including demographics and contact info | Read |
| Appointments | List upcoming and past appointments for a client or date range, retrieve full appointment details | Read |
| Intake forms | List forms sent to a client, retrieve full form responses and submission metadata | Read |
| Consultation notes | List notes for a client, retrieve full note content; create a new note on a client record | Read + Write |
| Practitioners | List all practitioners in the account, retrieve practitioner profile | Read |
| Invoices | List invoices for a client, retrieve invoice details and payment status | Read |
| Tags | List all tags in use across the account; useful for filtering or classification tasks | Read |
Full tool list with exact names and parameters is in the README at github.com/oktopeak/intakeq-mcp. Two MCP resources surface at session start: your current connection status and a HIPAA reminder that PHI access is being logged.
Why writes are scoped
The connector reads across all resource areas but writes in only one: creating and updating consultation notes. Appointments, client records, invoices, intake forms, and practitioner profiles are read-only.
This is deliberate. An LLM that can modify client records, update invoices, or reschedule appointments creates a different risk profile than one that reads and summarizes. In a behavioral health context, the stakes are higher: a wrong write to a client's record can affect treatment plans, insurance billing, or discharge documentation. Notes are the right place to permit writes because they're explicitly created as a record of what happened, they're reviewed before they matter, and note creation is the task clinicians actually want to automate (drafting a session summary, capturing a phone check-in, logging a referral).
If your practice needs expanded write scope for a specific workflow, the connector is MIT-licensed. We've added custom tool scopes for clinics in our healthcare integration work. The audit and auth layers don't need to be modified to add new tools.
HIPAA: what the connector does and what it doesn't
The connector handles three things on its own: encrypted API key storage, a local append-only audit log on every PHI access, and a local MCP server that doesn't route patient content through any third-party infrastructure including ours.
What the connector cannot do is make the AI provider HIPAA-compliant. That requires a separate step: a signed Business Associate Agreement with Anthropic, Zero Data Retention enabled on an enterprise Claude tier, and training disabled on the content you submit. This governs what the model is permitted to do with patient content during inference. Without those agreements in place, the audit log records access that may not have been permissible under HIPAA regardless of how good the logging is.
For the full argument on access vs retention and why data locality is not the same as compliance, see our post We Open-Sourced a HIPAA-Aware Claude + IntakeQ Connector. The short version: with any hosted model, patient content reaches the model for inference. That access is the compliance event. The BAA and ZDR govern what the provider does with it afterward.
IntakeQ's self-serve BAA covers your IntakeQ account and the data that flows through IntakeQ's own API. It does not cover Anthropic as a downstream processor. You need a separate BAA with Anthropic (available under Claude for Enterprise), and IntakeQ's BAA and Anthropic's BAA need to be in place before you send real patient data through the connector.
Setup
About five minutes, assuming you have an active IntakeQ or PracticeQ account and Claude Desktop or Claude Code.
- Log into IntakeQ, go to Settings → Integrations → API and generate an API key. IntakeQ provides this instantly. Copy it.
- Install the connector globally:
npm install -g @oktopeak/intakeq-mcp - Add the server to your Claude Desktop config (
claude_desktop_config.json) or Claude Code MCP config with yourINTAKEQ_API_KEYand a 64-character hexENCRYPTION_KEYin the env block. The README has the exact JSON snippet. - Restart Claude. The connector will verify your API key on first connection and write the encrypted credentials to
~/.oktopeak-intakeq/. - Test it: ask Claude "List my appointments for this week." Claude calls the appointments tool, returns the result, and an entry appears in
~/.oktopeak-intakeq/audit.log.
Full setup guide including environment variable reference and troubleshooting: github.com/oktopeak/intakeq-mcp. PracticeQ accounts use the same setup with the same API key format.
Limitations
- AI provider BAA required before sending real patient data. The connector runs locally and logs every access, but HIPAA compliance at the model layer requires a signed BAA with Anthropic, Zero Data Retention, and training disabled. The Guided Setup covers the configuration side; the BAA negotiation is with Anthropic directly.
- Single practice, single practitioner per installation. One API key per running instance. Multi-practitioner or multi-location scenarios that need to run on shared infrastructure require a hosted MCP server architecture. We build those as part of integration engagements.
- stdio transport only in v1. Local Claude Desktop and Claude Code. No hosted HTTP server, no remote access from outside the machine.
- Appointment writes not included in v1. Creating or modifying appointments requires calendar write scope that has different risk characteristics from note creation. It is on the roadmap; the architecture supports it cleanly. Open an issue on GitHub if this is blocking a specific workflow.
- IntakeQ API rate limits. IntakeQ's API has rate limits that vary by plan. The connector applies conservative request throttling and respects rate-limit headers. High-volume bulk reads (all notes for 500+ clients) will take proportionally longer.
Who this is for
Solo practitioners and small behavioral health practices on IntakeQ or PracticeQ who want Claude for the tasks a general-purpose LLM is good at: drafting session notes from a summary, reviewing intake responses before a first appointment, extracting themes from a client's note history, or combining IntakeQ data with other tools (EHR APIs, scheduling systems, documentation references) inside a single Claude session.
It is not a replacement for IntakeQ's own built-in automations or documentation features. It is an additional AI surface that can read and write to your IntakeQ account in a way that is auditable, scoped to your API key, and doesn't require IntakeQ to build the feature you need.
Want it running without doing the setup yourself?
The connector is free and installs in minutes. Generating the API key, configuring the audit-log destination, setting up encryption, validating the HIPAA stack, and confirming your IntakeQ BAA and Anthropic BAA are both in place before you send real patient data is the part most practices would rather hand off. With Guided Setup we deploy it inside your practice: scoped API key, audit-log destination configured, the HIPAA checklist walked through with your team, and a workflow built with your clinical lead. Fixed-price proposal within five business days. No retainer, no lock-in.
See Guided Setup →If you need this in production at clinic scale (multi-practitioner, hosted, custom note templates, integration with your EHR or billing system), that is the work we do for healthcare practices. Integration engagements typically run 4-6 weeks and include a hardened deployment of the open-source connector plus the practice-specific extensions your workflows require.
Ship details
- Source: github.com/oktopeak/intakeq-mcp (TypeScript, MIT)
- npm:
@oktopeak/intakeq-mcp(npm install -g @oktopeak/intakeq-mcp) - MCP Registry:
io.github.oktopeak/intakeq-mcp(auto-ingested by PulseMCP and mcpservers.org) - Companion connectors: if your practice uses Clio or MyCase alongside IntakeQ, the Clio and MyCase MCP connectors are built on the same architecture.
Questions, issues, or feature requests: GitHub issues. Want it deployed in your practice without the setup work: Guided Setup. Need it at clinic scale or extended for a specific workflow: book a call.
