tebra-mcp-server

Get Charges

tebra_get_charges

Read-only

Fetch Tebra charges with filters for date, patient, provider, procedure, diagnosis, status, and more. Returns payer, adjudication, adjustment reasons, amounts, and balances.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`fields`	No	Optional list of result fields to return (dotted paths for nested values, e.g. "cases.policies.companyName"). Omit for the default field set. Request only the fields you need — results contain protected health information.
`status`	No	Charge status filter. Observed values include 'Pending', 'Completed', 'Error - Rejection', 'Voided', 'Ready'. Note: 'Denied' is not a status Tebra uses; rejected claims carry 'Error - Rejection'.
`toDate`	No	Service end date filter (ISO 8601)
`billedTo`	No	Billed-to entity filter
`fromDate`	No	Service start date filter (ISO 8601)
`batchNumber`	No	Filter by batch number
`patientName`	No	Patient full name to filter by (ChargeFilter has no patient ID member)
`diagnosisCode`	No	Filter by ICD diagnosis code
`procedureCode`	No	Filter by CPT procedure code
`toCreatedDate`	No	Created date range end (YYYY-MM-DD)
`toPostingDate`	No	Posting date range end (YYYY-MM-DD); max 60 days from fromPostingDate
`encounterStatus`	No	Encounter status filter
`fromCreatedDate`	No	Created date range start (YYYY-MM-DD)
`fromPostingDate`	No	Posting date range start (YYYY-MM-DD); max 60 days from toPostingDate
`casePayerScenario`	No	Case payer scenario filter
`toLastModifiedDate`	No	Modified date range end (YYYY-MM-DD)
`fromLastModifiedDate`	No	Modified date range start (YYYY-MM-DD)
`renderingProviderName`	No	Rendering provider full name
`includeUnapprovedCharges`	No	Include unapproved charges (default false)

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.6.0Sep 21, 2026

addedInput schema / properties / fields

Added value: +{
+  "description": "Optional list of result fields to return (dotted paths for nested values, e.g. \"cases.policies.companyName\"). Omit for the default field set. Request only the fields you need — results contain protected health information.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / fromPostingDate / description

Previous value: -"Posting date range start (YYYY-MM-DD)"New value: +"Posting date range start (YYYY-MM-DD); max 60 days from toPostingDate"

removedInput schema / properties / patientId

Removed value: -{
-  "description": "Tebra patient ID to filter by",
-  "type": "string"
-}

addedInput schema / properties / patientName

Added value: +{
+  "description": "Patient full name to filter by (ChargeFilter has no patient ID member)",
+  "type": "string"
+}

changedInput schema / properties / status / description

Previous value: -"Charge status filter"New value: +"Charge status filter. Observed values include 'Pending', 'Completed', 'Error - Rejection', 'Voided', 'Ready'. Note: 'Denied' is not a status Tebra uses; rejected claims carry 'Error - Rejection'."

changedInput schema / properties / toPostingDate / description

Previous value: -"Posting date range end (YYYY-MM-DD)"New value: +"Posting date range end (YYYY-MM-DD); max 60 days from fromPostingDate"

First observedv0.2.5Jun 14, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. The description adds valuable behavioral context beyond the annotations, notably the server-side 60-day limit on posting-date ranges menus, and it explains what kind of charge details the result contains. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loads the core purpose in the first sentence, and gives a concise summary of outputs and a key limitation. There is no filler, repetition of schema properties, or unnecessary detail that would burden an agent selecting or invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only filtered-list tool with 19 optional parameters, the description covers the core inputs, the output shape, and an important server-side constraint. There is no output schema, but the description names the key returned groups (payer, adjudication, adjustment reasons, amounts, balances). Pagination and default field-set behavior are not described, but the annotations and schema already mitigate most gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 19 parameters with meaningful descriptions. The tool description mostly summarizes filter categories that the schema already names individually, adding little new parameter-level meaning; the 60-day caveat is also already present in the posting-date parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Get charges from Tebra', and lists both the available filter dimensions and the returned charge details. It is distinguishable from sibling tools like tebra_get_payments and tebra_get_transactions because it explicitly targets 'charges', though it does not name or contrast those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool's use is implied by the description: an agent can tell it is meant for retrieving charge records using various filterscombinations and seeing payer/adjudication details. However, there is no explicit guidance about when to choose this over related tools such as get_payments or get_transactions, and no stated exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Get Charges

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools