Skip to main content
Glama

Start an authorization follow-up

prior_authorization_request

We handle outpatient behavioral health authorizations, for counseling and for ABA, at a flat $39 per authorization: we submit the request to the payer, follow it up until it is approved or denied, and watch the approved units and end date so the next authorization is started before the current one runs out. Send the practice's email and name, the rendering clinician's NPI, the payer (when it has plans in several states or of several kinds, also the member's plan as payer_state, two letters, and plan_type: commercial, medicare_advantage, medicaid, chip, exchange or other), the patient's name, date of birth and member ID, the service type (outpatient_counseling or aba), the service (CPT or HCPCS codes, up to 8; the units or sessions requested with unit_kind; the start date and, optionally, the period as end_date or weeks; for ABA the hours per week and at least one adaptive behavior code, 97151 to 97158, 0362T or 0373T, and with end_date or weeks the units may be left out: they are worked out as hours a week x 4 fifteen-minute units x weeks, and the reply's requested_period says how), the ICD-10 diagnosis codes (up to 12), and whether it is new or a renewal (a renewal or re-authorization adds the current authorization number and the date it expires). A clinical document is a PDF, JPG or PNG up to 3 MB as base64 in a request of at most 4.4 MB, or up to 4 MB as a form upload; it is optional for counseling, and an ABA request goes to the payer only once its treatment plan or assessment is in (send it with the request or later on its page). Paid at checkout before any work starts; nothing is sent to the payer until payment. The reply has the reference, a Stripe checkout link, the requested period as saved (requested_period) and an access token, shown once, that opens the authorization's status. Once approved, the next authorization is prepared 14 days before the approved end date for counseling and 30 days before for ABA, or sooner when the units used say they run out first; a renewal or re-authorization is its own request, at the price of the authorization it follows. Not included: appeals of a denial, peer-to-peer reviews, and billing claims.

Input Schema

NameRequiredDescriptionDefault
payerYesThe payer or health plan, as on the insurance card.
weeksNoOptional. Or the length in weeks (26 for six months): the end date is worked out from start_date.
end_dateNoOptional. The last day of service requested (YYYY-MM-DD), up to a year after start_date. Send this or weeks.
cpt_codesYesCPT or HCPCS codes, such as 90837, or for ABA 97153 and 97155.
member_idYesAs on the insurance card.
plan_typeNoOptional. The kind of plan on the card, when the payer has several (a payer's Medicaid plan can go by a different route than its commercial plans).
unit_kindNosessions or units, with units_requested. Worked-out ABA totals are units (15 minutes each).
start_dateYesThe first day of service, such as 2026-11-03; up to 90 days back or 365 ahead.
patient_dobYesDate of birth, such as 1990-04-15.
payer_stateNoOptional. The state of the member's plan (two letters, such as TX), when the payer has plans in several states.
partner_codeNoOptional. A partner code Licium gave you: your agreed price is charged instead of the list price. A code that is not active is refused and nothing is saved.
patient_nameYesThe patient's first and last name as on the insurance card.
request_typeYesnew, or renewal of a current authorization (send its number and expiration).
service_typeYesaba: applied behavior analysis (hours per week, adaptive behavior codes, the treatment plan before it goes to the payer).
clinician_npiYesThe rendering clinician's 10-digit NPI.
practice_nameYes
hours_per_weekNoABA only: hours per week requested.
practice_emailYesThe practice's email, where status emails go.
diagnosis_codesYesICD-10 codes, such as F33.1.
units_requestedNoUnits or sessions requested in total, with unit_kind. ABA: leave it out with hours_per_week and end_date or weeks, and Licium works it out (hours a week x 4 fifteen-minute units x weeks; the reply's requested_period says how).
clinical_document_base64NoA treatment plan or assessment, base64 encoded: a PDF, JPG or PNG up to 3 MB, in a request of at most 4.4 MB. Optional for counseling; an ABA request goes to the payer once it is in.
existing_authorization_numberNoRenewal only: the current authorization number.
existing_authorization_expires_onNoRenewal only: the day the current authorization expires.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / end_date
      Added value: +{
      +  "description": "Optional. The last day of service requested (YYYY-MM-DD), up to a year after start_date. Send this or weeks.",
      +  "maxLength": 40,
      +  "type": "string"
      +}
    • addedInput schema / properties / payer_state
      Added value: +{
      +  "description": "Optional. The state of the member's plan (two letters, such as TX), when the payer has plans in several states.",
      +  "maxLength": 2,
      +  "minLength": 2,
      +  "type": "string"
      +}
    • addedInput schema / properties / plan_type
      Added value: +{
      +  "description": "Optional. The kind of plan on the card, when the payer has several (a payer's Medicaid plan can go by a different route than its commercial plans).",
      +  "enum": [
      +    "commercial",
      +    "medicare_advantage",
      +    "medicaid",
      +    "chip",
      +    "exchange",
      +    "other"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / unit_kind / description
      Added value: +"sessions or units, with units_requested. Worked-out ABA totals are units (15 minutes each)."
    • changedInput schema / properties / units_requested / description
      Previous value: -"Units or sessions requested."New value: +"Units or sessions requested in total, with unit_kind. ABA: leave it out with hours_per_week and end_date or weeks, and Licium works it out (hours a week x 4 fifteen-minute units x weeks; the reply's requested_period says how)."
    • addedInput schema / properties / weeks
      Added value: +{
      +  "description": "Optional. Or the length in weeks (26 for six months): the end date is worked out from start_date.",
      +  "maximum": 52,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "practice_email",
      -  "practice_name",
      -  "clinician_npi",
      -  "payer",
      -  "member_id",
      -  "patient_name",
      -  "patient_dob",
      -  "service_type",
      -  "cpt_codes",
      -  "units_requested",
      -  "unit_kind",
      -  "start_date",
      -  "diagnosis_codes",
      -  "request_type"
      -]New value: +[
      +  "practice_email",
      +  "practice_name",
      +  "clinician_npi",
      +  "payer",
      +  "member_id",
      +  "patient_name",
      +  "patient_dob",
      +  "service_type",
      +  "cpt_codes",
      +  "start_date",
      +  "diagnosis_codes",
      +  "request_type"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / partner_code
      Added value: +{
      +  "description": "Optional. A partner code Licium gave you: your agreed price is charged instead of the list price. A code that is not active is refused and nothing is saved.",
      +  "maxLength": 100,
      +  "type": "string"
      +}
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only mark this as a non-idempotent, non-destructive open-world write; the description adds critical behavior beyond that: nothing is sent to the payer until payment, the access token is shown once, document size/encoding limits, ABA gating on the treatment plan, and the 14/30-day prep cadence for the next authorization. These are exactly the operational facts an agent needs before invoking a paid, one-shot request.

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

Conciseness3/5

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

Nearly every clause carries real information, but the description is one dense run-on paragraph cramming payment, document rules, ABA logic and follow-up cadence together with no line breaks or grouping. It is front-loaded with price and scope, yet a reader has to re-parse it to extract the ABA and renewal rules.

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 a 23-parameter, 12-required, paid mutation with no output schema, the description covers the gaps structured fields cannot: what the reply contains (reference, Stripe link, requested_period, one-time access token), payment gating, document constraints, and the downstream renewal cadence. Very little an agent needs to call this correctly 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?

Schema coverage is 96%, so the baseline is 3; the description still adds conditional meaning, e.g. send payer_state/plan_type only when the payer spans several states or plan kinds, and leave units_requested out for ABA when hours_per_week plus end_date/weeks are given because the reply's requested_period explains the derivation. practice_name is the one required field not explained anywhere, but otherwise semantics are reinforced.

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?

States a concrete verb and resource — submits an outpatient behavioral-health authorization to the payer, follows it up, and watches units/end date — plus the flat $39 price. An agent can immediately distinguish this from prior_authorization_status or prior_authorization_update, and it names the two service lines (counseling, ABA) the tool supports.

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?

Gives explicit when-to-use context (new vs. renewal, ABA requires a treatment plan before it goes to the payer) and explicit when-not-to-use exclusions: 'Not included: appeals of a denial, peer-to-peer reviews, and billing claims.' It stops short of naming the sibling tools that handle status/updates, so alternatives are implied rather than directed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources