Open Dental MCP
Related Servers
Alternatives to Open Dental MCP
No user-submitted related servers found.
Related Servers
- FlicenseAqualityDmaintenanceMCP server for accessing PersonalEasy / EasyDental Cloud / DentalKids APIs, enabling read-only queries of appointments, production KPIs, provider info, and active units.4-
- AlicenseAqualityCmaintenanceRead-only MCP server for licensed Healthpoint HL7 FHIR API access.101Apache 2.0
- AlicenseAqualityCmaintenanceA read-only MCP server for AppDynamics that exposes 12 task-oriented tools to query applications, topology, metrics, snapshots, health rules, anomalies, events, alerting config, analytics events, and dependency maps via OAuth API-client credentials.121MIT
- AlicenseAqualityDmaintenanceA read-only MCP server over the ServiceTitan API providing six task-shaped tools to find customers, view their jobs, billing details, and resolve external IDs.6MIT
- AlicenseAqualityBmaintenanceRead-only MCP server that lets AI clients query DMS repositories through a local bridge, supporting tools for health checks, listing connections and items, retrieving item info, and reading documents. Credentials are handled securely via a separate broker.7MIT
- AlicenseAqualityDmaintenanceEnables interaction with Open Dental practice management software, allowing reading of patients, appointments, providers, procedures, and recalls, as well as writing communications back to patient charts via MCP clients.147MIT
TDQS
Scored across 12 tools
Each tool maps to a distinct resource/action: exact-ID get_* fetches, plural find_* searches, list_* reference data, and health_check. The clinical history tools (commlogs, recalls, procedurelogs) are clearly separated by domain, so misselection is unlikely.
Names are consistently snake_case with a verb_noun pattern such as get_patient, find_appointments, and list_providers. health_check is a minor deviation, but otherwise the get/find/list verbs are used coherently.
The 12 tools form a well-scoped read-oriented surface for patients, appointments, recalls, notes, procedures, and reference data. There is little redundancy and no obvious padding.
Core read lookups are covered, but the surface is entirely read-only: there are no create/update/cancel operations for appointments or patient records, and broader dental entities such as treatment plans, insurance/claims, and payments are absent. These are notable gaps if the agent is expected to manage the practice rather than just query it.