tebra-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TEBRA_SOAP_USER | Yes | SOAP API user (email) | |
| TEBRA_CUSTOMER_KEY | Yes | Customer key from Tebra PM admin | |
| TEBRA_FHIR_BASE_URL | No | FHIR R4 base URL (defaults to Tebra production) | |
| TEBRA_SOAP_ENDPOINT | No | Override SOAP endpoint (for testing) | |
| TEBRA_SOAP_PASSWORD | Yes | SOAP API password | |
| TEBRA_FHIR_CLIENT_ID | No | OAuth2 client ID from Tebra developer portal | |
| TEBRA_FHIR_CLIENT_SECRET | No | OAuth2 client secret |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| tebra_search_patientsA | Search for patients in Tebra with flexible filters. Use query/fullName for name search, or combine specific filters like firstName, lastName, DOB range, insurance company, practice, etc. Returns demographics, MRN, contact info, and primary/secondary insurance. Note: MRN and external ID are not server-side filters — use tebra_get_patient for external ID lookup. |
| tebra_get_patientA | Get a full patient record from Tebra by patient ID, or by external system ID (optionally scoped to an external vendor). Includes demographics, contact info, cases, insurance policies, and authorizations. Insurance policy and group numbers are omitted unless named in |
| tebra_get_encounterA | Get encounter details from Tebra by encounter ID, including patient, providers, status, service dates, place of service, and service line IDs. |
| tebra_create_encounterA | Create a new encounter (superbill) in Tebra with diagnoses and procedures. Each procedure becomes a service line carrying up to 4 ICD-10 diagnosis codes (from the encounter-level diagnoses array, or per-procedure diagnosisCodes). practiceName or practiceId is strongly recommended — Tebra requires the practice on most accounts. Returns the created encounter ID. |
| tebra_get_patient_authorizationsA | Get all insurance authorizations for a Tebra patient across all cases and policies. Returns auth number, approved/used/remaining visits, start/end dates, computed status (active/exhausted/expired/pending), payer contact info, and an expiring-soon warning. |
| tebra_get_appointmentsA | Get appointments from Tebra within a date range. Filter by resource (provider name), patient, confirmation status, service location, reason, type, and more. To filter by provider, use resourceName with the provider full name (the WSDL has no provider ID filter). |
| tebra_check_insurance_eligibilityA | Check insurance eligibility for a Tebra patient. Examines on-file insurance policies and authorization history. Note: this is an approximation based on on-file data, not a real-time payer eligibility check. |
| tebra_get_chargesA | Get charges from Tebra with flexible filters: date range, patient name, provider, procedure/diagnosis codes, billing status, encounter status, and more. Returns charge details with payer, adjudication, adjustment reasons, amounts, and balances. Note: posting-date range is limited to 60 days server-side. |
| tebra_get_procedure_codesA | Get procedure codes configured in the Tebra practice. Optionally filter by CPT code, active status, or customer-specific codes. Returns codes with official names, descriptions, and default units. |
| tebra_get_providersA | Get providers with IDs, names, specialties, NPI, and active status. Optionally filter by full name, practice, department, or provider type. Used to resolve provider names to IDs for appointments and encounters. |
| tebra_get_service_locationsA | Get all service locations (offices/facilities). Required for creating appointments and encounters. Optionally filter by practice or location ID. |
| tebra_get_appointment_reasonsA | Get all appointment reasons configured in the practice. Returns reason IDs, names, default durations, and color codes. Needed to create appointments with a reason. |
| tebra_create_appointmentA | Create a new patient appointment in Tebra. Requires patient, provider, service location, start time, and either endDate or duration (minutes). Optionally set reason, mode (InOffice/Telehealth), status, and notes. |
| tebra_update_appointmentA | Update an existing appointment in Tebra. Only provided fields will be changed. When changing startDate, also provide endDate or duration. To only change the status, prefer tebra_update_appointment_status. |
| tebra_update_appointment_statusA | Update only the status of an appointment (e.g. Confirmed, CheckedIn, NoShow, Cancelled). Lighter than tebra_update_appointment — use for check-in/check-out workflows. |
| tebra_delete_appointmentA | Delete an appointment from Tebra by appointment ID. This is irreversible — to keep history, prefer tebra_update_appointment_status with Cancelled. |
| tebra_get_appointment_detailA | Get full detail for a single appointment by ID, including recurrence rules, group data, and all resource slots. |
| tebra_create_patientA | Create a new patient in Tebra with demographics, address, insurance, and guarantor information. The practice is required by Tebra; if practiceName/practiceId are omitted, the account's first practice is used automatically. |
| tebra_update_patientA | Update an existing patient in Tebra. Only provided fields will be changed. The practice is required by Tebra; if practiceName/practiceId are omitted, the account's first practice is used automatically. |
| tebra_update_encounter_statusA | Update the status of an encounter in Tebra. Moves encounters through the billing workflow: Draft → Submitted → Approved (triggers billing) or Rejected (returns to Draft); Unpayable closes it out. Note: Tebra's UI shows Submitted encounters under 'Review'. |
| tebra_get_paymentsB | Get payments from Tebra with optional post-date range, payer, batch, appointment, and reference-number filters. Returns payment details with amounts, methods, and payer info. Note: the Tebra WSDL has no patient ID filter for payments. |
| tebra_create_paymentA | Create a new patient payment in Tebra. Supports Cash, Check, CreditCard, ElectronicFundsTransfer, and Other payment methods. Optionally link to an appointment and practice. Not retried after a timeout or server error (Tebra has no idempotency key, so a re-send can double-charge); if the call fails with an unknown outcome, check tebra_get_payments before resubmitting. Supply referenceNumber so any duplicate is detectable. |
| tebra_get_transactionsA | Get financial transactions from Tebra with optional date range, type, payer, procedure code, and practice filters. Returns transaction details with patient, claim, and insurance info. |
| tebra_get_practicesA | Get all practices associated with the Tebra account. Returns practice IDs, names, NPI, tax ID, and contact info. |
| tebra_create_documentA | Upload a document to a patient record in Tebra via base64 content (PDF, JPG, PNG, TIFF — type inferred from the file extension). documentLabel must be a Tebra DocumentLabel enum value (CamelCase, no spaces), e.g.: MedicalReport, PatientAuthorizationOrReferral, PatientCorrespondence, PatientDemographics, PatientInsuranceCard, PatientDriversLicense, Superbill, ExplanationofBenefits, InsuranceCorrespondence, OperativeReport, ... Use 'Other' when unsure. |
| tebra_delete_documentA | Delete a document from Tebra by document ID. This is irreversible. |
| tebra_get_all_patientsA | Get all patients in bulk with pagination. Returns a page of patients and a continuation key for the next page. Use startKey from the previous response to get the next batch. By default each row is a roster entry (patientId, firstName, lastName, dateOfBirth, mrn, active); pass |
| tebra_update_patient_external_idA | Set or update a patient external ID in Tebra, linking the patient to an external system. Register the vendor first with tebra_register_external_vendor and pass its numeric ID as externalVendorId. |
| tebra_register_external_vendorA | Register a new external vendor in Tebra for external ID mapping. Returns the vendor ID to use with tebra_update_patient_external_id. |
| tebra_get_external_vendorsA | Get all registered external vendors in Tebra with their IDs. |
| tebra_get_throttlesA | Get the per-endpoint API throttle intervals (milliseconds between calls) that Tebra enforces for this account. Useful for monitoring API usage limits. |
| tebra_validate_connectionA | Validate the Tebra API credentials by retrieving the customer ID and authorization flag. Use as a health check. |
| tebra_set_primary_patient_caseA | Promote an existing patient case to be the primary case, by case ID. Find case IDs via tebra_get_patient (cases[].caseId). Note: this cannot rename a case or change its payer scenario. |
| tebra_create_appointment_reasonA | Create a new appointment reason in Tebra with name and default duration. Color is a Tebra color code number (not hex). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 34 tools
Most tools target a distinct Tebra resource and action, and descriptions clearly separate similar entities like appointments vs. appointment details and patients vs. patient searches. A few adjacent pairs such as get_charges/get_payments/get_transactions or check_insurance_eligibility/get_patient_authorizations could be confused, but the descriptions draw reasonable boundaries.
Every tool follows the tebra_ prefix with a consistent verb_noun snake_case pattern, such as get_patient, create_appointment, update_encounter_status, and delete_document. There are no mixed conventions, vague verbs, or unpredictable naming styles.
With 34 tools, the server is well beyond the typical well-scoped range and adds significant selection overhead for an agent. While most tools serve distinct purposes, the overall surface feels heavy for a single MCP server.
Core patient, appointment, encounter, and payment workflows are substantially covered, including create/read/update/status operations. However, there are notable gaps such as no encounter detail editing, no document retrieval/listing, and no creation or update of authorizations or patient cases.