> ## Documentation Index > Fetch the complete documentation index at: https://agents.nanonets.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # AdvancedMD Operations > Call any supported AdvancedMD API through one declarative operation catalog. ## What these tools are The AdvancedMD integration exposes two kinds of tool. The hand-written ones (`advancedmd_post_payment`, `advancedmd_update_appointment_type`, and so on) implement multi-step workflows: they make several API calls, resolve carriers, run pre-post balance checks, and fall back deliberately when AdvancedMD answers oddly. The tools on this page are different. Each one is a single AdvancedMD API call, described declaratively in an operation catalog rather than implemented in code. They are named `advancedmd_op_` and there are 35 of them. Use a workflow tool when one exists for your task. Reach for these when you need an AdvancedMD endpoint that no workflow tool covers. ## Authentication and enablement All of these tools read the workspace's AdvancedMD integration — office code, username and password — from the connected integration. Those fields are never supplied by the agent and are not part of the model-visible schema. If AdvancedMD is not connected, the tool returns a "not connected" result rather than failing the task. **Every operation is disabled by default.** Enable the specific ones an agent needs; do not enable all 35. ## Inputs and outputs Each tool's inputs are exactly the arguments its operation declares — the schema and each field's description come from the catalog, so what you see in the tool picker is what AdvancedMD accepts. Patient and visit ids are reshaped automatically where AdvancedMD is inconsistent about them (some actions want `pat11506958`, others reject the prefix and want `11506958`). Every result carries: * `success` — whether a declared result path actually resolved. **Not** merely whether the call returned: AdvancedMD answers a rejected request with HTTP 200 often enough that "no error" is not evidence of anything. * `operation` — the operation name, echoed back. * `data` — the projected records. * `matched_at` — where in AdvancedMD's response the data was found. Present only when a path resolved. * `message` — present only when no path resolved, saying that the empty `data` is not evidence the record does not exist. * `warnings` — present only when the response arrived in a different envelope than expected. ### Rehearsing a write Every write accepts `dry_run`. With `dry_run: true` the tool builds the request, returns it, and sends nothing — it does not even authenticate. The result then also carries: * `status: "dry_run"` and `sent: false` * `would_send` — the exact request that would have gone to AdvancedMD **Use it before any write you have not run before.** AdvancedMD has no undo and no idempotency key. **Read `warnings` when it appears.** It means AdvancedMD returned a shape the catalog did not predict, and the data may be partial. This is surfaced rather than swallowed because a silently-empty result is indistinguishable from "this patient genuinely has no records". ## Limits and side effects * **Writes are not idempotent and not retried.** AdvancedMD has no idempotency key and, for most of these actions, no undo. Calling a write twice creates two records — two patients, two batches, or a patient who receives the same form twice. * **Rate limiting is real.** AdvancedMD returns HTTP 429 under modest concurrency; calls are paced and retried with backoff per office, so a burst of operations will take longer rather than fail. * **Access differs per office.** An operation that works for one AdvancedMD office can be unavailable on another belonging to the same customer. A failure on one office proves nothing about another. * Document upload lands a file on the patient's timeline. It cannot attach to a visit or encounter, and there is no delete. ## Expected errors | Error | Meaning | | -------------------------------------------- | ------------------------------------------------------------------------------- | | `AdvancedMD is not connected...` | No AdvancedMD integration on the workspace | | `: is required` | A required argument was omitted; rejected before any call | | `unknown argument "..."` | An argument the operation does not declare | | `AdvancedMD: Server Error (Server): AMD-...` | AdvancedMD rejected the request; its own reference code is included for support | | HTTP 400 with no detail | Usually an argument in the wrong shape for that specific action | ## Available operations Operations are grouped by surface: `pm_*` covers practice management (patients, scheduling, charges, master files) and `ehr_*` covers the clinical record and patient forms. | Tool | What it does | Kind | AdvancedMD endpoint | | --------------------------------------------------- | -------------------------------------------------- | ----- | ------------------------------------------- | | `advancedmd_op_ehr_accept_consent_form` | Accept a submitted consent form | write | `patientportal/uploadconsentform` | | `advancedmd_op_ehr_accept_intake_form` | Accept a submitted intake form | write | `patientforms/importnote` | | `advancedmd_op_ehr_assign_consent_form` | Assign a consent form to a visit | write | `patientforms/addconsentform` | | `advancedmd_op_ehr_assign_intake_form` | Assign an intake form to a visit | write | `patientforms/addnote` | | `advancedmd_op_ehr_decline_patient_form` | Decline a patient form | write | `patientforms/rejectconsentform` | | `advancedmd_op_ehr_get_consent_form` | Get a consent form's content | read | `patientforms/getconsentform` | | `advancedmd_op_ehr_get_patient_forms` | Get patient forms | read | `patientforms/getpatientforms` | | `advancedmd_op_ehr_get_visit_notes` | Get EHR notes for a visit | read | `api/getehrnotesbyvisit` | | `advancedmd_op_ehr_list_form_templates` | List EHR form templates | read | `api/getehrtemplates` | | `advancedmd_op_ehr_list_forms_for_review` | List forms awaiting review | read | `POST /patientforms/patientforms/forreview` | | `advancedmd_op_ehr_send_patient_forms_notification` | Email patient their forms link | write | `portal/sendpatientformsmailnotification` | | `advancedmd_op_ehr_upload_document` | File a document on the EHR timeline | write | `POST /files/documents` | | `advancedmd_op_pm_create_batch` | Open a new posting batch | write | `batches/newbatch` | | `advancedmd_op_pm_create_patient` | Create a patient | write | `api/addpatient` | | `advancedmd_op_pm_find_patient` | Find patient | read | `api/lookuppatient` | | `advancedmd_op_pm_get_carrier` | Get a carrier by id | read | `masterfiles/selectcarriers` | | `advancedmd_op_pm_get_charge_detail` | Get charge detail | read | `demographics/getchargedetaildataicd10` | | `advancedmd_op_pm_get_patient_demographics` | Get patient demographics | read | `demographics/getdemographic` | | `advancedmd_op_pm_get_patient_episodes` | Get patient episodes | read | `demographics/getepisodes` | | `advancedmd_op_pm_get_patient_insurances` | Get a patient's insurance plans | read | `demographics/getdemographic` | | `advancedmd_op_pm_get_transaction_history` | Get a patient's transaction history | read | `demographics/gettxhistory` | | `advancedmd_op_pm_get_visit_by_id` | Get visit by id | read | `api/getvisitsbyid` | | `advancedmd_op_pm_list_date_visits` | List visits for a date | read | `api/getdatevisits` | | `advancedmd_op_pm_list_day_appointments` | List a scheduler column's appointments for one day | read | `scheduler/getAppts` | | `advancedmd_op_pm_list_scheduler_columns` | List scheduler columns | read | `GET /scheduler/Columns` | | `advancedmd_op_pm_list_updated_visits` | List visits changed since a timestamp | read | `api/getupdatedvisits` | | `advancedmd_op_pm_lookup_carrier` | Look up an insurance carrier by code | read | `api/lookupcarrier` | | `advancedmd_op_pm_lookup_diag_code` | Look up a diagnosis code | read | `api/lookupdiagcode` | | `advancedmd_op_pm_lookup_mod_code` | Look up a billing modifier | read | `api/lookupmodcode` | | `advancedmd_op_pm_lookup_proc_code` | Look up a procedure code | read | `api/lookupproccode` | | `advancedmd_op_pm_lookup_provider` | Look up a provider by name | read | `api/lookupprovider` | | `advancedmd_op_pm_save_memo` | Save chart memo | write | `demographics/savememo` | | `advancedmd_op_pm_save_patient_note` | Save a patient master-file note | write | `masterfiles/savepatientnotes` | | `advancedmd_op_pm_select_provider` | Search providers | read | `masterfiles/selectprovider` | | `advancedmd_op_pm_update_patient` | Update a patient's demographics | write | `api/updatepatient` | ## Trying an operation locally The catalog ships with a command that runs one operation through the same executor the tools use, so a result there is the result an agent would get. It needs no MCP client and no running platform. ```bash theme={null} cd backend # The catalog. No credentials needed. go run ./cmd/amd-mcp -list export AMD_OFFICE_CODE=... AMD_USERNAME=... AMD_PASSWORD=... # Call a read. go run ./cmd/amd-mcp -call pm_find_patient -args '{"name":"Smith"}' # Build a write's request and print it WITHOUT sending. Do this first for # anything that writes: AdvancedMD has no undo. go run ./cmd/amd-mcp -call pm_save_patient_note -dry-run \ -args '{"patient_id":"111","patient_id_ref":"111","note_text":"test"}' # Send a real write. -allow-write is required: without it -call refuses any # operation marked write, so a forgotten -dry-run cannot become a live write. go run ./cmd/amd-mcp -call pm_save_patient_note -allow-write \ -args '{"patient_id":"111","patient_id_ref":"111","note_text":"test"}' # Or serve the whole catalog over MCP on stdio. -allow-write gates writes here # too — without it a connected client's non-dry-run write is refused. go run ./cmd/amd-mcp -allow-write ``` Arguments are validated against the operation before anything is sent, so a typo is rejected locally rather than by AdvancedMD. ## Verification status Every read operation in this catalog has been called against a live AdvancedMD test office and its response shape confirmed. Write operations are verified by building and inspecting the exact request they would send, not by executing them: they alter real patient records. Where a write's payload can be corroborated against a client already running it in production, that is recorded in the operation's own guidance — the two form-accept operations and the decline are confirmed field-for-field against fleming's implementation, which runs them on a schedule against a live tenant. A handful of operations carry caveats in their own tool description — that an inner element name is inferred rather than observed, or that a request shape comes from a known-good client rather than a test call. Those notes are part of the tool description the agent sees, so they are visible where they matter.