Skip to main content
Glama

Licium

by io.github.Licium-ai
OverviewDiscussionsAdmin

Start a weekly payer follow-up

payer_follow_up_request

Weekly payer follow-up: we check every pending payer enrollment application every week until the payer approves or denies it, and email 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. 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: $29 per application, checked weekly until decided, up to 120 days, then $4 per check; optional roster monitoring $3 per clinician per month. Application bundle: $129 per application, paid up front, one checkout line per application, written, submitted and checked weekly until decided. 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.

Input Schema

TableJSON 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: $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.
emailYes
accessYesHow you will give access: payer portal user, PECOS surrogate, delegation letter, CAQH admin invite, or call_only by itself.
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.
applicationsNoPending applications, one clinician with one payer each, up to 300.
contact_timeNoLeave empty.
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. 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"
+]
  2. Added

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the weekly cadence, the one-business-day missing-document email, that nothing is checked until payment, that the reply contains a Stripe checkout link and an access token shown only once, cancellation timing, and explicit exclusions (appeals, contract/rate negotiation). Return format is described at a high level.

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?

Purpose is front-loaded, but the body is a dense wall of text bundling process, parameter rules, four price tiers, and exclusions into one run-on paragraph. The pricing detail is lengthy and hard to parse; structure is weak and the definition is significantly longer than it needs to be.

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 complex 16-parameter tool with no output schema, the description covers the workflow, plan selection rules, access modes, downstream reply contents, and exclusions, which is close to sufficient. Missing only explicit sibling routing and any statement about error/failure handling.

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 81%, so the schema already documents most parameters. The description reinforces the plan enum semantics and the caqh-vs-send document choice, but largely restates structure the schema already carries rather than adding syntax or format detail.

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?

Opens with a concrete verb and resource: it subscribes the user to a weekly service that checks every pending payer enrollment application until approved/denied, and names the three plan modes. Purpose is unambiguous. It does not, however, distinguish itself from the sibling payer_follow_up_status or provider_check_request, leaving the agent to infer the boundary.

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?

Usage is implied through plan descriptions (group/per_application take a roster plus pending applications; application_bundle takes applications_to_submit), so the agent can infer which plan fits. But there is no explicit when-to-use-this-vs-alternatives guidance and no statement of prerequisites beyond the payment requirement.

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

All Licium toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources