Skip to main content
Glama

Start a weekly payer follow-up

payer_follow_up_request

Weekly payer follow-up: we check every pending payer enrollment application with the payer until it is approved or denied (every 30 minutes, day and night, for payers that post their status online; the others every week, or as often as every business day with check_every_days), and tell you within one business day when a payer is missing a document; with the application bundle we first write and submit the application. Send an email, the plan and how you will give access (payer portal user, PECOS surrogate, delegation letter, CAQH admin invite, or call only). Group and per-application plans take the roster as NPIs and the pending applications (clinician NPI, payer, state, date submitted; payer reference number and notes optional). The application bundle takes applications_to_submit (clinician NPI, payer, state, and documents: caqh to use the clinician's CAQH profile, or send to send the license, malpractice certificate, W-9 and CV or work history; notes optional); where a payer requires the clinician's own signature, the clinician signs or attests. The reply has a Stripe checkout link and an access token, shown once, that opens the status later; nothing is checked until payment. A platform starting follow-ups for its own practices can keep every email from them with notify: platform_only (every email goes only to notify_email, its own address) or webhook_only (no email; status by the webhook). Group plan: $15 per clinician per month for the whole roster (weekly license, Medicare revalidation, exclusion list and NPI registry monitoring, only changes reported, plus a CAQH re-attestation and Medicare revalidation calendar), plus $149 per month for each clinician with a pending application, until all their applications are decided or six months. Per-application plan: $79 per application, checked until decided with no time limit; optional roster monitoring $3 per clinician per month. On the per-application plan and the application bundle, an application the payer never decides (no record on 3 checks in a row over at least 3 weeks, or 12 months without a decision) is stopped with an email and can be reopened at no charge within 30 days. Application bundle: $199 per application, paid up front, one checkout line per application, written, submitted and then checked until decided. Add webhook_url to get each status change as a signed POST (the reply carries webhook.secret once). Cancel subscriptions any time, from the next month. Not included: appeals, contract or rate negotiation. Up to 500 clinicians and 300 applications; up to 100 applications per bundle. Billing firms and software platforms get volume pricing, set up with us rather than at checkout. Book 20 minutes at https://calendly.com/licium/20-minutes or write to hello@licium.ai. Add partner_code if Licium gave you one. A request that cannot be used is refused with every field to fix at once (problems: field and error) and each unusable entry (invalid_entries), and nothing is saved.

Input Schema

NameRequiredDescriptionDefault
npisNoThe roster: 10-digit NPIs, up to 500. Every application's clinician is added to it.
planYesgroup: monthly, $15 per roster clinician plus $149 per clinician with a pending application. per_application: $79 per application, one time, checked until decided with no time limit. application_bundle: $199 per application, one time, we write and submit it, then check it until decided; send applications_to_submit, not a roster or pending applications.
emailYes
accessYesHow you will give access: payer portal user, PECOS surrogate, delegation letter, CAQH admin invite, or call_only by itself.
notifyNoOptional. Who gets this follow-up's emails: practice (default) sends them to email; platform_only sends every email (payment confirmation, missing documents, document requests and reminders, roster changes, the Monday status email, stopped applications) only to notify_email, your platform's address, marked with the practice it is about, and never to email; webhook_only sends no email at all (webhook_url is required) and status reaches you by the webhook and GET /v1/payer-follow-ups/{id}.
companyNo
ref_codeNo
caqh_textNoThe same dates as text: one line per clinician, NPI and date.
monitoringNoPer-application plan only: add roster monitoring at $3 per clinician per month.
roster_textNoThe roster as text with NPIs anywhere in it; with or instead of npis.
webhook_urlNoOptional. An HTTPS address on a public host (port 443 or 8443; no private, loopback, link-local or local addresses; at most 300 characters) that gets a signed POST each time an application's status changes. The reply carries webhook.secret, shown once.
applicationsNoPending applications, one clinician with one payer each, up to 300.
contact_timeNoLeave empty.
notify_emailNoRequired with notify platform_only, and only then: the address every email of this follow-up goes to instead of email.
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.
idempotency_keyNoOptional, sent as the Idempotency-Key header: 1 to 128 printable ASCII characters with no spaces. Retry with the same key, email and fields within 24 hours to get the first reply again instead of a second follow-up; that repeated reply has replayed true and access_token null (the token and any webhook secret are shown only in the first reply). The same key with different fields is refused (409).
check_every_daysNoOptional, 1 to 7 (default 7, weekly): days between the checks of an application that are not reads of the payer's public status page (calls, emails, portal checks), always on a business day; 1 is every business day. For every application of the request, or set in an application entry for that one. The price does not change. Status pages are read every 30 minutes, day and night.
applications_textNoPending applications as CSV or tab-separated lines: NPI, payer, state, date submitted, payer reference (optional), notes (optional); with or instead of applications.
caqh_attestationsNoOptional CAQH last attestation dates for the deadline calendar (re-attestation is due 120 days later).
applications_to_submitNoapplication_bundle only: the applications to write and submit, one clinician with one payer each, up to 100.
roster_from_provider_checkNoThe request ID of a provider check sent from the same email; its NPIs join the roster.
applications_to_submit_textNoapplication_bundle only: the same as CSV or tab-separated lines: NPI, payer, state, documents (caqh or send), notes (optional); with or instead of applications_to_submit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields 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"
      +}
    • changedInput schema / properties / plan / description
      Previous value: -"group: monthly, $15 per roster clinician plus $149 per clinician with a pending application. per_application: $29 per application, one time, checked until decided with no time limit. application_bundle: $129 per application, one time, we write and submit it, then check it until decided; send applications_to_submit, not a roster or pending applications."New value: +"group: monthly, $15 per roster clinician plus $149 per clinician with a pending application. per_application: $79 per application, one time, checked until decided with no time limit. application_bundle: $199 per application, one time, we write and submit it, then check it until decided; send applications_to_submit, not a roster or pending applications."
  2. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "description": "Optional, sent as the Idempotency-Key header: 1 to 128 printable ASCII characters with no spaces. Retry with the same key, email and fields within 24 hours to get the first reply again instead of a second follow-up; that repeated reply has replayed true and access_token null (the token and any webhook secret are shown only in the first reply). The same key with different fields is refused (409).",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. Changed7 schema fields changed
    • addedInput schema / properties / applications / items / properties / check_every_days
      Added value: +{
      +  "description": "This application's own check_every_days (wins over the request's).",
      +  "maximum": 7,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / applications_to_submit / items / properties / check_every_days
      Added value: +{
      +  "description": "This application's own check_every_days (wins over the request's).",
      +  "maximum": 7,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / check_every_days
      Added value: +{
      +  "description": "Optional, 1 to 7 (default 7, weekly): days between the checks of an application that are not reads of the payer's public status page (calls, emails, portal checks), always on a business day; 1 is every business day. For every application of the request, or set in an application entry for that one. The price does not change. Status pages are read every 30 minutes, day and night.",
      +  "maximum": 7,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / notify
      Added value: +{
      +  "description": "Optional. Who gets this follow-up's emails: practice (default) sends them to email; platform_only sends every email (payment confirmation, missing documents, document requests and reminders, roster changes, the Monday status email, stopped applications) only to notify_email, your platform's address, marked with the practice it is about, and never to email; webhook_only sends no email at all (webhook_url is required) and status reaches you by the webhook and GET /v1/payer-follow-ups/{id}.",
      +  "enum": [
      +    "practice",
      +    "platform_only",
      +    "webhook_only"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / notify_email
      Added value: +{
      +  "description": "Required with notify platform_only, and only then: the address every email of this follow-up goes to instead of email.",
      +  "format": "email",
      +  "maxLength": 254,
      +  "type": "string"
      +}
    • changedInput schema / properties / plan / description
      Previous value: -"group: monthly, $15 per roster clinician plus $149 per clinician with a pending application. per_application: $29 per application, one time, up to 120 days. application_bundle: $129 per application, one time, we write and submit it, then check it weekly until decided; send applications_to_submit, not a roster or pending applications."New value: +"group: monthly, $15 per roster clinician plus $149 per clinician with a pending application. per_application: $29 per application, one time, checked until decided with no time limit. application_bundle: $129 per application, one time, we write and submit it, then check it until decided; send applications_to_submit, not a roster or pending applications."
    • addedInput schema / properties / webhook_url
      Added value: +{
      +  "description": "Optional. An HTTPS address on a public host (port 443 or 8443; no private, loopback, link-local or local addresses; at most 300 characters) that gets a signed POST each time an application's status changes. The reply carries webhook.secret, shown once.",
      +  "maxLength": 300,
      +  "type": "string"
      +}
  4. Changed7 schema fields changed
    • changedInput schema / properties / access / description
      Previous value: -"How you will give access: payer portal user, delegation letter, CAQH admin invite, or call_only by itself."New value: +"How you will give access: payer portal user, PECOS surrogate, delegation letter, CAQH admin invite, or call_only by itself."
    • changedInput schema / properties / access / items / enum
      Previous value: -[
      -  "portal_user",
      -  "delegation_letter",
      -  "caqh_admin",
      -  "call_only"
      -]New value: +[
      +  "portal_user",
      +  "pecos_surrogate",
      +  "delegation_letter",
      +  "caqh_admin",
      +  "call_only"
      +]
    • changedInput schema / properties / access / maxItems
      Previous value: -4New value: +5
    • addedInput schema / properties / applications_to_submit
      Added value: +{
      +  "description": "application_bundle only: the applications to write and submit, one clinician with one payer each, up to 100.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "documents": {
      +        "description": "caqh: use the clinician's CAQH profile (give CAQH access). send: you send the license, malpractice certificate, W-9 and CV or work history after payment.",
      +        "enum": [
      +          "caqh",
      +          "send"
      +        ],
      +        "type": "string"
      +      },
      +      "notes": {
      +        "maxLength": 500,
      +        "type": "string"
      +      },
      +      "npi": {
      +        "maxLength": 40,
      +        "type": "string"
      +      },
      +      "payer": {
      +        "maxLength": 200,
      +        "type": "string"
      +      },
      +      "state": {
      +        "description": "Two-letter code, such as TX.",
      +        "maxLength": 40,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "npi",
      +      "payer",
      +      "state",
      +      "documents"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 200,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • addedInput schema / properties / applications_to_submit_text
      Added value: +{
      +  "description": "application_bundle only: the same as CSV or tab-separated lines: NPI, payer, state, documents (caqh or send), notes (optional); with or instead of applications_to_submit.",
      +  "maxLength": 100000,
      +  "type": "string"
      +}
    • changedInput schema / properties / plan / description
      Previous value: -"group: monthly, $15 per roster clinician plus $149 per clinician with a pending application. per_application: $29 per application, one time, up to 120 days."New value: +"group: monthly, $15 per roster clinician plus $149 per clinician with a pending application. per_application: $29 per application, one time, up to 120 days. application_bundle: $129 per application, one time, we write and submit it, then check it weekly until decided; send applications_to_submit, not a roster or pending applications."
    • changedInput schema / properties / plan / enum
      Previous value: -[
      -  "group",
      -  "per_application"
      -]New value: +[
      +  "group",
      +  "per_application",
      +  "application_bundle"
      +]
  5. Added

TDQS

A3.7/5.0
Behavior5/5

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

Goes well beyond the annotations: nothing is checked until payment, the reply carries a Stripe checkout link and a once-shown access token, pricing and cancellation terms, hard caps (500 clinicians / 300 applications / 100 per bundle), check cadence (30 minutes for online status pages, weekly otherwise), webhook secret shown once, and validation behavior (refusal with problems and invalid_entries, nothing saved). The idempotency-key replay semantics are also spelled out in the schema.

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

Conciseness2/5

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

A single run-on paragraph of several hundred words with nested parentheticals; pricing tables, the Calendly link, the email address and partner-code sales copy do not help an agent invoke the tool. Front-loading is decent (the core behavior comes first), but the block is far larger than needed for tool selection.

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 22-parameter subscription-creating tool with no output schema, it covers the payment gate, what the reply contains (checkout link, token), the operational caps, failure modes, and cancellation. Missing only the practical handoff details, e.g. which identifier to feed into payer_follow_up_status or how long setup takes after checkout.

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 86%, so the schema already documents plan, access, notify, check_every_days, webhook_url and the applications structures in similar words. The description adds billing/plan economics and the access-mode vocabulary, but much of it duplicates rather than extends the schema fields, so the baseline 3 applies.

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 opening clause names the concrete service — checking every pending payer enrollment application until approved or denied, plus optional application writing/submission. It is clear what the tool initiates, but it never uses an explicit verb like 'start' or 'submit' and never distinguishes itself from siblings such as payer_follow_up_status, payer_follow_up_documents or payer_follow_up_reopen.

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?

Plan-selection guidance is implicit in the prose (group/per-application take a roster and pending applications; the application bundle takes applications_to_submit instead), and scope exclusions are stated ('Not included: appeals, contract or rate negotiation'). However, there is no guidance on when to choose this tool versus the sibling status/documents/reopen tools, so routing must be inferred from the name.

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