Skip to main content
Glama
Sign In

Licium

by ai.licium
OverviewDiscussionsAdmin

Send units used or a clinical document for an authorization

prior_authorization_update

Update one authorization with its ID and its access token (or the agent key of the agent whose part call bought it): units_used (the units or sessions used so far on an approved authorization; the day the next authorization is prepared follows the pace) and/or one clinical document, a PDF, JPG or PNG up to 4 MB: clinical_document_url (an HTTPS link Licium downloads), or clinical_document as multipart form data to PATCH /v1/authorizations/{id}; clinical_document_base64 inside JSON takes files up to 3 MB, since base64 makes a file a third larger and a request is at most 4.4 MB. A document sent while the payer waits on more information goes to the payer next; an ABA request waiting on its treatment plan goes on to the payer once the plan arrives. Returns what changed and the authorization.

Input Schema

NameRequiredDescriptionDefault
agent_keyNoInstead of access_token: the agent key (lk_...) of the agent whose part call bought this authorization, or whose verified owner email is the practice email.
units_usedNoApproved authorizations: the units or sessions used so far.
access_tokenNoThe access_token prior_authorization_request returned (shown once), or the token in an emailed link.
authorization_idYes
clinical_document_urlNoOr the document as an HTTPS link Licium downloads: a PDF, JPG or PNG up to 4 MB (a signed link is fine). A link is not held to the 4.4 MB request limit that keeps clinical_document_base64 to 3 MB.
clinical_document_base64NoA PDF, JPG or PNG up to 3 MB, base64 encoded, in a request of at most 4.4 MB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / agent_key
      Added value: +{
+  "description": "Instead of access_token: the agent key (lk_...) of the agent whose part call bought this authorization, or whose verified owner email is the practice email.",
+  "type": "string"
+}
    • addedInput schema / properties / clinical_document_url
      Added value: +{
+  "description": "Or the document as an HTTPS link Licium downloads: a PDF, JPG or PNG up to 4 MB (a signed link is fine). A link is not held to the 4.4 MB request limit that keeps clinical_document_base64 to 3 MB.",
+  "maxLength": 2000,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "authorization_id",
-  "access_token"
-]New value: +[
+  "authorization_id"
+]
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the annotations (readOnly false, destructive false, non-idempotent, open-world), the description adds real behavior: PATCH semantics, the two auth paths, the 4 MB file limit and why base64 is capped at 3 MB, and — most valuable — that a document sent while the payer waits goes to the payer next. It also notes the return value. It stops short of saying whether a re-sent update is safe or reversible, which matters given idempotentHint=false.

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?

The purpose is front-loaded, but the body is one sprawling sentence stitched with parentheses, colons and semicolons, forcing the reader to re-parse the limits clause. The size-limit information appears twice in compressed form. It is dense rather than economical.

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 non-idempotent mutation with no output schema, the description covers auth options, payload choices, size ceilings, upgrade path, and what is returned. Only the reversibility/partial-update question is left open, which is a minor gap given the annotations already flag the write semantics.

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 description coverage is 83%, so 3 is the baseline; the description earns more by explaining units_used's downstream effect (the next authorization's preparation timing follows the pace) and by positioning the three document channels relative to each other. Some of this repeats the schema's own text, but the routing logic between clinical_document_url and clinical_document_base64 is clarified beyond it.

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 description states a specific verb and resource: update one authorization with units_used and/or a clinical document, keyed by authorization_id. It is clearly distinguishable from prior_authorization_request (create/request) and prior_authorization_status (poll), though it never names those siblings. The title reinforces the units-or-document duality.

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 rather than stated: send units once sessions are used on an approved authorization, or attach a document the payer is waiting on. There is no explicit 'when not to use' and no pointer to prior_authorization_status for checking, so an agent must infer the boundary. The ABA treatment-plan example is the only concrete conditional in the text.

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