Skip to main content
Glama

DenialPath

by io.github.maxbeech

Look up NCCI PTP edits for a pair or a code

get_ncci_edits
Read-onlyIdempotent

Look up NCCI procedure-to-procedure (PTP) edits, in two modes. Pair mode: pass column1, column2 (either order) and dateOfService to check whether that specific pair bundles on that date; status is no_data (we hold no edit for this pair in our dataset - NOT confirmation CMS has none), not_applicable (we hold the edit but it does not apply on this date, either outside its effective/deletion window or modifierIndicator "9" meaning the edit is deleted or never applicable), or applies. List mode: pass code alone to get every pair in the dataset involving that code, in either column, with no date filtering. modifierIndicator "0" means no modifier may ever bypass the edit; "1" means a modifier may bypass it, but only where the services were genuinely distinct. Free, no API key needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoList mode: a single code. Returns every pair in the dataset involving it, in either column, with no date filtering.
column1NoPair mode: a CPT/HCPCS code. Send with column2 and dateOfService. Column order does not matter; the response reports the pair in CMS column order.
column2NoPair mode: the other code in the pair.
dateOfServiceNoPair mode, required: ISO yyyy-mm-dd, e.g. "2026-07-01". NCCI PTP edits are versioned quarterly, so a pair lookup cannot be answered without a date.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changed
    • addedInput schema / oneOf
      Added value: +[
+  {
+    "required": [
+      "column1",
+      "column2",
+      "dateOfService"
+    ],
+    "title": "Pair mode: does this specific pair bundle on this date?"
+  },
+  {
+    "required": [
+      "code"
+    ],
+    "title": "List mode: every pair involving this code"
+  }
+]
    • changedInput schema / properties / code / description
      Previous value: -"List mode: a single code, returning every pair involving it."New value: +"List mode: a single code. Returns every pair in the dataset involving it, in either column, with no date filtering."
    • changedInput schema / properties / column1 / description
      Previous value: -"A CPT/HCPCS code. Pair mode: use with column2 and dateOfService."New value: +"Pair mode: a CPT/HCPCS code. Send with column2 and dateOfService. Column order does not matter; the response reports the pair in CMS column order."
    • changedInput schema / properties / column2 / description
      Previous value: -"The other code in the pair."New value: +"Pair mode: the other code in the pair."
    • changedInput schema / properties / dateOfService / description
      Previous value: -"ISO yyyy-mm-dd. Required in pair mode."New value: +"Pair mode, required: ISO yyyy-mm-dd, e.g. \"2026-07-01\". NCCI PTP edits are versioned quarterly, so a pair lookup cannot be answered without a date."
    • addedInput schema / properties / dateOfService / format
      Added value: +"date"
    • addedInput schema / properties / dateOfService / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds substantial context beyond annotations: it explains the meaning of status values (no_data, not_applicable, applies) and modifierIndicator values ('0' vs '1'), including the nuance that no_data is dataset-specific, not CMS confirmation. This aligns perfectly with openWorldHint=false and adds value.

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

Conciseness5/5

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

The description is concise yet comprehensive, front-loaded with its purpose. It structures the two modes clearly, uses bullet-like separation via 'Pair mode' and 'List mode,' and every sentence contributes essential details (status semantics, modifier meanings, free/no-key note). No redundancy or filler.

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?

Despite having no output schema, the description fully covers behavioral context: both modes, status values, modifier indicators, the closed-world dataset nuance, and pricing/access. It leaves no major ambiguity for an AI agent selecting or invoking the tool correctly.

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 coverage is 100%, so the baseline is 3. The description adds some contextual meaning—e.g., column order does not matter and why dateOfService is required—but most of this is already present in the schema descriptions. No substantial new parameter semantics are introduced beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb and resource: 'Look up NCCI procedure-to-procedure (PTP) edits.' It immediately distinguishes two modes (pair and list), each clearly defined. This effectively separates it from sibling tools like get_mue and get_timely_filing, which target different edit types or workflows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use each mode: pair mode for a specific pair/date, list mode for a code. It also notes the tool is free and requires no API key. However, it does not explicitly mention alternatives or when not to use the tool relative to siblings, stopping short of a 5.

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

All DenialPath toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct function: claim checking, appeal drafting, denial explanation, MUE lookup, NCCI edits lookup, and timely filing. There is no overlap in purpose, and the descriptions make the boundaries clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (check_claim, draft_appeal, explain_denial, get_mue, get_ncci_edits, get_timely_filing). The verbs are specific and the nouns are meaningful, creating a predictable and readable naming scheme.

Tool Count5/5

Six tools is well within the ideal range for a focused server. The count feels appropriate for the denial management domain, with each tool earning its place and no redundancy.

Completeness5/5

The toolset covers the full denial lifecycle: pre-claim checking (check_claim), denial explanation (explain_denial), appeal drafting (draft_appeal), and supporting lookups (get_mue, get_ncci_edits, get_timely_filing). No obvious gaps exist for the stated purpose.

Resources