Skip to main content
Glama

Read an authorization follow-up

prior_authorization_status
Read-onlyIdempotent

Read one authorization with its ID and the access token returned when it was sent, the token in an emailed link, or the agent key of the agent whose prior-authorization-submit or prior-authorization-renewal-start part call bought it: payment, status and next step, the payer's case number and its latest words (what it asked for, or its reason for a denial), the approval (units, start and end dates, authorization number), the units used and the day the next authorization is prepared, the clinical documents sent, every step with its date, route and who did it, what is happening on it right now (now_doing: one line read from its records, such as faxing the request, the payer's fax line confirmed it and we wait for its answer, or on the phone with the payer, with that record's time and live true while it happens), and each fax and status call sent to the payer with its sent, arrived and answered steps (receipts). Statuses: awaiting_payment, received (Licium has it and it is paid; it has not gone to the payer yet, sent_to_payer false), submitted (sent to the payer), pending, info_requested (what the payer asked for is in payer_note), approved (approved units, start and end dates, authorization number), denied (the reason is in payer_note), expired.

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.
access_tokenNoThe access_token prior_authorization_request returned (shown once), or the token in an emailed link.
authorization_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 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"
      +}
    • 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: it enumerates the status lifecycle (awaiting_payment, received, submitted, pending, info_requested, approved, denied, expired) and explains the live now_doing field with its timestamp. It does not discuss error behavior or rate limits, but the read-only safety profile is already covered by annotations.

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?

The description is one enormous run-on sentence with deeply nested parentheticals that is difficult to parse. While the opening is front-loaded with the core read action, the bulk is an unstructured enumeration of return fields that should have been separated into a clear list. It is informative but poorly structured and excessively long.

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?

There is no output schema, so the description must explain the returned data, and it does so comprehensively: payment, status, payer case number, payer_note, approval details, units used, clinical documents, step history, live now_doing state, and fax/status call receipts. Combined with the status definitions, an agent has enough to interpret the response without additional documentation.

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?

With 67% schema description coverage, the schema already documents agent_key and access_token. The description adds meaningful provenance semantics: access_token is the one-time token from prior_authorization_request or an emailed link, and agent_key identifies the agent whose prior-authorization-submit or prior-authorization-renewal-start call bought the authorization. This meaningfully helps choose among the optional credentials.

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 opens with a specific verb and resource: read one authorization by ID. It explains the credential provenance (access token, emailed link token, or agent key from a submit/renewal call), which makes the object and scope unambiguous. It does not explicitly contrast with prior_authorization_update or payer_follow_up_status, so it falls short of full sibling differentiation.

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 context is implied: this is the read path after a prior_authorization_request or a paid submit/renewal call, using one of three credential forms. However, it never states when to choose this over prior_authorization_update, payer_follow_up_status, or payment_status, and gives no exclusions or prerequisites beyond credential sourcing.

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