tebra-mcp-server

Get Payments

tebra_get_payments

Read-only

Retrieve payment records from Tebra using filters for date ranges, payer, batch, appointment, or reference number to get amounts, methods, and payer info.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	No	Optional exact amount filter
`payerName`	No	Optional payer name filter
`payerType`	No	Optional payer type filter (e.g. Patient, Insurance)
`paymentId`	No	Optional payment ID lookup
`toPostDate`	No	Optional end post date filter (ISO 8601)
`batchNumber`	No	Optional batch number filter
`fromPostDate`	No	Optional start post date filter (ISO 8601)
`practiceName`	No	Optional practice name filter
`appointmentId`	No	Optional appointment ID filter
`toCreatedDate`	No	Optional end created date filter (ISO 8601)
`fromCreatedDate`	No	Optional start created date filter (ISO 8601)
`referenceNumber`	No	Optional reference/check number filter
`toLastModifiedDate`	No	Optional end last-modified date filter (ISO 8601)
`fromLastModifiedDate`	No	Optional start last-modified date filter (ISO 8601)

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.6.0Sep 21, 2026

addedInput schema / properties / amount

Added value: +{
+  "description": "Optional exact amount filter",
+  "type": "string"
+}

addedInput schema / properties / appointmentId

Added value: +{
+  "description": "Optional appointment ID filter",
+  "type": "string"
+}

addedInput schema / properties / fromCreatedDate

Added value: +{
+  "description": "Optional start created date filter (ISO 8601)",
+  "type": "string"
+}

removedInput schema / properties / patientId

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

addedInput schema / properties / payerType

Added value: +{
+  "description": "Optional payer type filter (e.g. Patient, Insurance)",
+  "type": "string"
+}

addedInput schema / properties / paymentId

Added value: +{
+  "description": "Optional payment ID lookup",
+  "type": "string"
+}

addedInput schema / properties / practiceName

Added value: +{
+  "description": "Optional practice name filter",
+  "type": "string"
+}

addedInput schema / properties / toCreatedDate

Added value: +{
+  "description": "Optional end created date filter (ISO 8601)",
+  "type": "string"
+}

First observedv0.2.5Jun 14, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds the note about the Tebra WSDL lacking a patient ID filter, which is a useful external constraint. However, it does not describe return format, pagination, or how filters interact (AND/OR). With annotations covering the safety profile, a 3 is appropriate.

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

Conciseness4/5

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

The description is concise—two sentences plus a note—with no fluff. It front-loads the core action and filter categories. It could be slightly more structured, but it is efficient and readable. The note about the WSDL limitation is a valuable addition without excessive length.

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

Completeness2/5

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

For a tool with 14 optional parameters and no output schema, the description is incomplete. It does not explain whether it returns a single payment or a list, how filters combine, or any default behavior (e.g., date range default). It also does not mention response structure or error conditions. Given the complexity, more contextual detail is needed for an agent to call it correctly.

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 description coverage is 100%, so all 14 parameters have descriptions in the schema. The tool description summarizes some filters (post-date range, payer, batch, appointment, reference-number) but omits others like amount, paymentId, practiceName, and created/last-modified dates. Since the schema does the heavy lifting, the description adds minimal additional meaning beyond the schema, warranting a baseline 3.

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 the verb 'Get' and the resource 'payments', and lists specific filters (post-date range, payer, batch, appointment, reference-number). It also adds a useful note about the missing patient ID filter. However, it does not explicitly differentiate from sibling tools like tebra_get_charges or tebra_get_transactions, though the resource is unambiguous.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions or scenarios where another tool would be more appropriate. The only hint is the patient ID filter limitation, but it does not point to a substitute. An agent is left to infer usage from the name and filters.

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

Deploy Server

Get Payments

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools