Skip to main content
Glama
mymedi-ai-mcp-server

mymedi-ai-mcp-server

by MyMedi-AI

Prior-auth approval rate + CMS requirement facts

pa_predict
Read-only

Predict prior-authorization approval rates for a CPT/HCPCS code using your organization's own decided PAs, with CMS prior-auth requirement facts returned when no cohort exists.

Instructions

Historical prior-authorization approval rate for a procedure code, computed only from your organization's own decided prior authorizations for that code — never from other customers' records — and only from at least 10; an API key or account with no organization has no cohort. With a cohort it returns the rate with cohort size and confidence; without one it returns the verifiable facts instead — CMS Required Prior Authorization List status, category, and published review timeframes — and reports that no rate was computed (the call is refunded on this path). Either way its recommendation states the CMS requirement only. It reports past decisions and makes no coverage or prior-authorization determination. Original Medicare FFS scope.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "procedureCode": "<procedureCode>"
    },
    "name": "pa_predict"
  }
}

Input Schema

NameRequiredDescriptionDefault
payerIdNoPayer category, e.g. "MEDICARE", "AETNA" or "UNITED_HEALTHCARE" (any letter case) — narrows your organization's own decided-PA cohort to that payer. A payer's own ID number names no category, so it finds no cohort.
procedureCodeYesCPT/HCPCS procedure code (e.g., "E0651", "K0800")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.7.9
    • removedInput schema / properties / diagnosisCodes
      Removed value: -{
      -  "description": "Supporting ICD-10 diagnosis codes",
      -  "items": {
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
    • removedInput schema / properties / patientAge
      Removed value: -{
      -  "description": "Patient age in years",
      -  "type": "number"
      -}
    • removedInput schema / properties / patientGender
      Removed value: -{
      -  "enum": [
      -    "M",
      -    "F",
      -    "O"
      -  ],
      -  "type": "string"
      -}
    • changedInput schema / properties / payerId / description
      Previous value: -"Insurance payer ID"New value: +"Payer category, e.g. \"MEDICARE\", \"AETNA\" or \"UNITED_HEALTHCARE\" (any letter case) — narrows your organization's own decided-PA cohort to that payer. A payer's own ID number names no category, so it finds no cohort."
    • addedInput schema / properties / payerId / maxLength
      Added value: +500
    • changedInput schema / properties / procedureCode / description
      Previous value: -"CPT/HCPCS procedure code"New value: +"CPT/HCPCS procedure code (e.g., \"E0651\", \"K0800\")"
    • addedInput schema / properties / procedureCode / maxLength
      Added value: +500
  2. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Goes well past the readOnly/openWorld annotations: it discloses the privacy boundary (own organization only, never other customers), the minimum cohort of 10, the no-organization/no-cohort edge case, the refund on the no-rate path, that the recommendation states CMS requirement only, that no coverage determination is made, and the Original Medicare FFS scope. That is exactly the extra context annotations cannot carry.

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?

Front-loaded with the core purpose, but it is a single dense run-on of em-dash clauses with some repetition ("never from other customers' records" restates the own-organization point) and a parenthetical about refunds buried mid-sentence. Correct information, harder to scan than it needs to be.

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?

With no output schema, the description carries the return-value burden itself, and it does: it describes the rate-plus-cohort-size-plus-confidence payload on one path and the CMS status/category/review-timeframe payload plus a no-rate report on the other. Nothing an agent needs to interpret either response is missing.

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 100%, so the schema already explains procedureCode as CPT/HCPCS and payerId as a payer category rather than a payer ID number. The description reinforces that the cohort is scoped to the organization's own decided PAs, but adds no format, validation, or edge-case detail beyond the schema — baseline 3.

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?

States a specific verb+resource: a historical prior-auth approval rate for a procedure code drawn from the caller's own organization's decided PAs. It also names the fallback payload (CMS Required Prior Authorization List status, category, review timeframes), which helps distinguish it from pa_required_check and pa_status, though it never names those siblings outright.

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?

The description makes the two operating regimes explicit — a cohort of at least 10 decided PAs yields a rate, otherwise CMS facts are returned — but it never says when to pick this tool over pa_required_check, pa_status, or pa_exposure_report. Usage is implied by the data-availability conditions rather than stated as selection guidance.

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