Skip to main content
Glama
jamesrosing

tebra-mcp-server

by jamesrosing
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Document

tebra_create_document

Upload a medical document to a patient's Tebra record using base64 content, with file type inferred from the extension and a required category label.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNameYesFile name with extension (e.g. lab_results.pdf) — the extension determines the file type
patientIdYesTebra patient ID
practiceIdNoPractice ID (required by Tebra; auto-resolved to the account's first practice if omitted)
descriptionNoOptional document description/notes
fileContentYesBase64-encoded file content
documentNameNoOptional display name for the document (defaults to fileName)
documentLabelYesDocument category label from the Tebra DocumentLabel enum (e.g. MedicalReport, PatientAuthorizationOrReferral, PatientCorrespondence, PatientDemographics, PatientInsuranceCard, PatientDriversLicense, Other). Spaces are stripped automatically.
encounterDateNoOptional document date to associate with (ISO 8601)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.6.0
    • changedInput schema / properties / documentLabel / description
      Previous value: -"Document category label (e.g. Lab Results, Referral Letter)"New value: +"Document category label from the Tebra DocumentLabel enum (e.g. MedicalReport, PatientAuthorizationOrReferral, PatientCorrespondence, PatientDemographics, PatientInsuranceCard, PatientDriversLicense, Other). Spaces are stripped automatically."
    • addedInput schema / properties / documentName
      Added value: +{
+  "description": "Optional display name for the document (defaults to fileName)",
+  "type": "string"
+}
    • changedInput schema / properties / encounterDate / description
      Previous value: -"Optional encounter date to associate with (ISO 8601)"New value: +"Optional document date to associate with (ISO 8601)"
    • changedInput schema / properties / fileName / description
      Previous value: -"File name with extension (e.g. lab_results.pdf)"New value: +"File name with extension (e.g. lab_results.pdf) — the extension determines the file type"
    • removedInput schema / properties / fileType
      Removed value: -{
-  "description": "File type: PDF, JPG, PNG, or TIFF",
-  "enum": [
-    "PDF",
-    "JPG",
-    "PNG",
-    "TIFF"
-  ],
-  "type": "string"
-}
    • addedInput schema / properties / practiceId
      Added value: +{
+  "description": "Practice ID (required by Tebra; auto-resolved to the account's first practice if omitted)",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "patientId",
-  "documentLabel",
-  "fileName",
-  "fileContent",
-  "fileType"
-]New value: +[
+  "patientId",
+  "documentLabel",
+  "fileName",
+  "fileContent"
+]
  2. First observedv0.2.5

TDQS

A4.5/5.0
Behavior4/5

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

The description adds meaningful behavioral detail beyond the annotations: file type is inferred from the extension, documentLabel must be a CamelCase enum value, spaces are stripped automatically, and 'Other' is a safe fallback. This is useful context on top of the readOnlyHint/idempotentHint/destructiveHint annotations.

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 purpose statement is front-loaded in one precise sentence, and the follow-up sentence provides high-value enum guidance. The list of examples is long but directly necessary for correct invocation, and no sentence is wasted.

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

Completeness5/5

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

For an 8-parameter create operation with no output schema, the description plus schema cover everything needed to call the tool correctly: required parameters, accepted file types, base64 content format, label enum constraints, and practiceId auto-resolution behavior. No essential invocation detail is missing.

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

Parameters4/5

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

The input schema already documents all eight parameters, so the baseline is 3. The description adds value by explaining documentLabel semantics (CamelCase, no spaces, enum examples, fallback to Other) and how fileName's extension determines the accepted file type, which goes beyond the schema descriptions.

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

Purpose5/5

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

The description uses a specific verb and resource: 'Upload a document to a patient record in Tebra' and specifies the mechanism (base64 content) and accepted file types (PDF, JPG, PNG, TIFF). This clearly differentiates it from the only close sibling (tebra_delete_document) and from patient/appointment creation tools.

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

Usage Guidelines4/5

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

The intended use is clear: when a document needs to be attached to a Tebra patient record. It does not explicitly discuss alternatives or when not to use the tool, but no close alternative exists among the siblings, and the guidance to use 'Other' when unsure helps the agent choose an appropriate label.

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

Deploy Server

Other Tools