Connect Open Dental to Claude: Sync Scheduling & Insurance
Learn how to connect Open Dental to Claude using a managed MCP server. Automate dental scheduling, insurance verification, and billing with AI agents.
If your team needs to connect Open Dental to Claude to automate patient scheduling, reconcile family insurance plans, or generate clinical progress notes, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's function calls and Open Dental's complex REST API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.
If your team uses ChatGPT, check out our guide on connecting Open Dental to ChatGPT or explore our broader architectural overview on connecting Open Dental to AI Agents.
Giving a Large Language Model (LLM) read and write access to a monolithic Practice Management System (PMS) like Open Dental is an engineering challenge. You are dealing with highly relational healthcare data, interdependent foreign keys, and strict validation rules. Every time Open Dental updates an endpoint or modifies a schema, you have to update your server code, redeploy, and test the integration.
This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Open Dental, connect it natively to Claude Desktop, and execute complex dental management workflows using natural language.
The Engineering Reality of the Open Dental API
A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools over JSON-RPC, the reality of implementing it against Open Dental's API requires significant domain expertise.
If you decide to build a custom Open Dental MCP server, here are the specific integration quirks you will face:
The Patient - Family - Guarantor Hierarchy
In Open Dental, a patient is rarely an isolated entity. Billing, insurance estimates, and account balances revolve around the concept of a "Family" and a "Guarantor". If Claude needs to check a balance, it cannot just query the patient - it needs to fetch the Account Module Agings using the PatNum, which returns the family's aging grid. Your MCP server must expose tools that allow the LLM to traverse these relational jumps without hallucinating patient identifiers.
Definition Lookup Tables (DefNums)
Open Dental relies heavily on dynamic definition tables. You cannot simply create an allergy with the string "Penicillin". The AI must first query list_all_open_dental_allergy_defs to find the exact AllergyDefNum for Penicillin, and then pass that integer into the create_a_open_dental_allergy payload. A well-designed MCP server must expose both the read endpoints for definitions and the write endpoints for instances, and the JSON Schemas must clearly instruct the LLM to fetch the DefNum first.
Planned vs. Scheduled Appointments
Open Dental strictly separates the concept of a planned treatment from a scheduled slot in the operatory. You cannot just "create an appointment." Workflows often require creating a Planned Appointment, finding a slot using list_all_open_dental_appointment_slots (which checks provider and operatory schedules), and then converting it using create_a_open_dental_scheduled_planned_appointment. Exposing these as raw CRUD tools without descriptive schemas will result in LLM errors.
Mutually Exclusive Payload Fields
Open Dental's REST API enforces strict validation where certain fields cannot coexist. For example, when creating a ProcedureLog, you can pass Priority or priority, but not both. Passing both causes silent failures or rejected payloads. Truto handles this complexity by generating clean, deterministic JSON Schemas derived directly from the API documentation, ensuring Claude only sends exactly what Open Dental expects.
How to Generate the Open Dental MCP Server
Truto derives MCP tools dynamically from Open Dental's API definitions. When you connect an Open Dental account, Truto automatically generates a secure JSON-RPC endpoint containing the schemas for every documented endpoint.
You can generate the MCP server in two ways: via the Truto UI or programmatically via the API.
Method 1: Via the Truto UI
For administrators setting up an internal tool, the UI is the fastest path.
- Navigate to the integrated account page for the Open Dental connection in your Truto dashboard.
- Click the MCP Servers tab.
- Click Create MCP Server.
- Configure the server (set a name, apply method or tag filters, and set an optional expiration date).
- Copy the generated MCP server URL (e.g.,
https://api.truto.one/mcp/a1b2c3d4...).
Method 2: Via the API
For developers embedding AI agents into a product, you can generate MCP servers on the fly. This validates that tools are available, generates a secure cryptographically hashed token, and returns a ready-to-use URL.
Make a POST request to /integrated-account/:id/mcp:
// POST https://api.truto.one/integrated-account/<open-dental-account-id>/mcp
// Headers: Authorization: Bearer <Truto_API_Token>
{
"name": "Open Dental Clinical Assistant",
"config": {
"methods": ["read", "write"],
"tags": ["clinical", "scheduling"]
},
"expires_at": "2026-12-31T23:59:59Z"
}The response contains the URL your agent needs:
{
"id": "mcp-789-xyz",
"name": "Open Dental Clinical Assistant",
"config": { "methods": ["read", "write"], "tags": ["clinical", "scheduling"] },
"expires_at": "2026-12-31T23:59:59Z",
"url": "https://api.truto.one/mcp/a1b2c3d4e5f6g7h8"
}How to Connect the MCP Server to Claude
Once you have the Truto MCP URL, connecting it to Claude requires zero additional coding. The URL encodes the authentication and routing logic.
Method 1: Via the Claude UI
If you are using Claude Desktop or an enterprise workspace that supports visual configuration:
- Open Claude and navigate to Settings.
- Go to Integrations (or Connectors depending on your plan tier).
- Click Add MCP Server.
- Paste your Truto MCP URL and save.
Claude will immediately ping the endpoint, perform the initialization handshake, and ingest the Open Dental tool schemas.
Method 2: Via Manual Configuration File
For local development or headless Claude deployments, you can configure the MCP server via JSON. Truto provides an SSE (Server-Sent Events) transport bridge.
Edit your claude_desktop_config.json file:
{
"mcpServers": {
"open-dental-truto": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sse",
"https://api.truto.one/mcp/a1b2c3d4e5f6g7h8"
]
}
}
}Restart Claude. The agent now has direct, authenticated access to the Open Dental instance.
Open Dental Hero Tools
Truto automatically generates tools for the entire Open Dental REST API. When Claude invokes tools/list, it receives a heavily optimized JSON Schema mapping for each endpoint. Here are the highest-leverage tools for automating dental practice workflows.
list_all_open_dental_patients
This is the core discovery tool. It utilizes Open Dental's fast simple search to find a patient by name, birthdate, or phone number. It is significantly faster on large databases than the legacy search_patients method. You need the PatNum returned here for almost every other operation.
"Find the patient record for John Doe, born in 1985. I need his PatNum and current PatStatus."
list_all_open_dental_appointment_slots
This tool replicates the logic of Open Dental's internal appointment search. By passing a ProvNum (Provider ID) and OpNum (Operatory ID), Claude can locate open time blocks without having to manually parse overlapping schedule endpoints.
"Check Dr. Smith's schedule (ProvNum 5) in Operatory 1 (OpNum 1) and find all open appointment slots for next Tuesday between 9 AM and 12 PM."
create_a_open_dental_appointment
Books a scheduled appointment for a patient in a specific operatory. The LLM must pass the PatNum, Op (Operatory), and AptDateTime.
"Book a new appointment for PatNum 1045 on November 12th at 10:00 AM in Operatory 2. Set the pattern to 30 minutes."
list_all_open_dental_family_module_insurances
Retrieves a patient's insurance coverages exactly as they appear in the Family Module. It returns primary and secondary coverage data, including PatPlanNum, SubscriberID, and InsSubNum.
"Pull the insurance details from the Family Module for PatNum 2088. Tell me who the primary subscriber is and provide the SubscriberID."
list_all_open_dental_chart_module_prog_notes
Returns the chronological clinical history for a patient, mirroring the Chart Module. This includes procedures, appointments, commlogs, and tasks. It is the primary read tool for generating clinical summaries.
"Get the progress notes from the Chart Module for PatNum 3412 over the last 6 months. Summarize any completed procedures and clinical notes."
create_a_open_dental_procedure_log
Logs a treatment (planned, completed, or existing). The AI must pass the PatNum, ProcDate, and ProcStatus. This is the foundational tool for treatment planning and charting.
"Log a completed procedure for PatNum 4001 for today. Use the procedure code for a routine adult prophy and set the status to completed."
create_a_open_dental_claim
Generates an insurance claim for completed procedures. The LLM passes the PatNum, a list of procNums, and the ClaimType (Primary, Secondary, etc.). Open Dental automatically handles the routing to the correct InsPlan attached to the patient.
"Create a primary insurance claim for PatNum 5100, attaching the procedures we just marked as completed today."
To see the complete API surface, including custom fields, recall management, and payment plans, view the full Open Dental integration inventory.
Workflows in Action
With the MCP server connected to Claude, you can orchestrate complex, multi-step practice management tasks.
Scenario 1: The AI Front Desk Coordinator
Handling inbound patient scheduling requires verifying identity, finding provider availability, and booking the slot.
"John Doe (DOB: 05/15/1980) called to schedule a follow-up with Dr. Miller. Find his record, find the earliest available slot for Dr. Miller next week, and book the appointment."
Execution Steps:
list_all_open_dental_patients: Claude searches for "John Doe" with the provided DOB to extract thePatNum.list_all_open_dental_providers: Claude searches for "Dr. Miller" to obtain theProvNum.list_all_open_dental_appointment_slots: Claude queries open blocks for next week using the retrievedProvNum.create_a_open_dental_appointment: Claude executes the booking using thePatNum,ProvNum, and the selectedAptDateTime.
Result: The user receives a natural language confirmation that John Doe is scheduled, and the appointment instantly appears on the Open Dental schedule board.
Scenario 2: The Automated Clinical Biller
After clinical treatment is completed, billing requires checking balances, verifying insurance, and generating claims.
"Review the progress notes for Sarah Jenkins from her visit today. If her procedures are marked complete, check her family balance and generate a primary insurance claim."
Execution Steps:
list_all_open_dental_patients: Claude retrieves Sarah'sPatNum.list_all_open_dental_chart_module_prog_notes: Claude filters today's entries to find theProcNumsthat have aProcStatusof Completed (C).list_all_open_dental_account_module_agings: Claude retrieves the family aging grid to check for outstanding balances.create_a_open_dental_claim: Claude submits a POST request with thePatNum, the completedprocNums, andClaimTypeset to "Primary".
Result: Claude summarizes the completed procedures, confirms the current family balance, and provides the ClaimNum for the newly generated insurance claim.
sequenceDiagram
participant Claude as Claude Agent
participant Truto as Truto MCP Server
participant OD as Open Dental API
Claude->>Truto: Call tool (list_all_open_dental_patients)
Truto->>OD: Proxy GET /patients
OD-->>Truto: Return Patient JSON
Truto-->>Claude: Return PatNum
Claude->>Truto: Call tool (list_all_open_dental_chart_module_prog_notes)
Truto->>OD: Proxy GET /chartmodule/prognotes
OD-->>Truto: Return Notes & ProcNums
Truto-->>Claude: Return completed ProcNums
Claude->>Truto: Call tool (create_a_open_dental_claim)
Truto->>OD: Proxy POST /claims
OD-->>Truto: Return Claim ID
Truto-->>Claude: Confirm claim createdSecurity and Access Control
Exposing an EHR/PMS system to an LLM requires strict boundary enforcement. Truto's MCP architecture provides native security controls at the token level, ensuring agents only access what they explicitly need.
- Method Filtering: Configure the MCP server with
methods: ["read"]to ensure the agent can only executeGETorLISToperations. This is critical for building safe reporting or auditing agents that cannot accidentally mutate clinical data. - Tag Filtering: Limit the agent's scope to specific functional areas using
config.tags. For example, settingtags: ["billing"]ensures the LLM cannot see or interact with clinical charting tools. - Require API Token Auth: By setting
require_api_token_auth: true, the MCP endpoint requires a valid API token in theAuthorizationheader, preventing unauthorized execution even if the MCP URL is leaked in logs. - Ephemeral Servers: Use the
expires_atproperty to grant temporary access. An agent can be given a server URL that self-destructs after 2 hours, completely closing the connection to the Open Dental environment.
Handling Rate Limits and Infrastructure Realities
The Open Dental API enforces rate limits to maintain database stability. It is important to note: Truto does not retry, throttle, or apply backoff on rate limit errors.
When the Open Dental API returns an HTTP 429 (Too Many Requests), Truto passes that error directly back to the caller. However, Truto normalizes the upstream rate limit information into standardized IETF headers:
ratelimit-limitratelimit-remainingratelimit-reset
The caller (your application or the MCP client) is responsible for reading these headers and implementing the necessary retry and exponential backoff logic. Truto ensures you have the exact metadata needed to pause the LLM execution until the reset window clears.
Closing the Gap Between AI and Dental Operations
Connecting Claude to Open Dental transforms static LLM conversations into autonomous practice management operations. By utilizing an MCP server, you offload the complexity of schema normalization, definition lookups, and authentication lifecycles.
Rather than spending weeks writing custom integration code to handle the duality of planned versus scheduled appointments, or the hierarchy of patient guarantors, you can rely on Truto's dynamically generated toolset. This allows your engineering team to focus on designing reliable agentic workflows, while the MCP server handles the API execution layer securely and deterministically.
FAQ
- How does Truto handle Open Dental API rate limits?
- Truto does not retry, throttle, or apply backoff on rate limit errors. When the Open Dental API returns an HTTP 429, Truto passes that error directly to the caller. Upstream rate limit info is normalized into standardized IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). The caller is responsible for implementing retry and backoff logic.
- Can I filter which Open Dental tools Claude has access to?
- Yes. When generating the MCP server URL via Truto, you can pass configuration parameters to restrict access by HTTP method (e.g., read-only operations) or by functional tags (e.g., only exposing scheduling endpoints).
- Does Truto store patient data passing through the MCP server?
- No. Truto's proxy API and MCP server architecture acts as a real-time pass-through layer. Data from Open Dental is routed directly to the LLM client without being retained in Truto's databases, aligning with HIPAA requirements for healthcare data.
- How do I handle Open Dental's 'DefNum' references with an LLM?
- Open Dental heavily uses definition tables (like AllergyDefs or ApptFieldDefs). Claude must first use a tool to query the definition list to find the correct DefNum, and then pass that integer into subsequent write operations. Truto's auto-generated schemas instruct the model on these required parameters.