Skip to main content
Glama

Real Dental Costs

by io.github.tresor4k
OverviewDiscussionsAdmin

Check a dental treatment plan line by line

benchmark_treatment_plan
Read-only

Use this when the user has a treatment plan or quote from a US dentist (CDT codes such as D2740, or procedure names, with quantities and quoted amounts) and wants to know where each line sits. For each line, returns the state cash band (observed or estimated badge) and where the quoted amount falls in it, what Medicaid paid per claim line (T-MSIS p25 / median / p75) and the official Medicaid fee schedule with its age scope (children_only or not_verified: context only), plus the state's adult Medicaid rule and numbered sources. quoted_usd is the line total as quoted. Codes billed as parts of one job are summed into a bundle and compared with its band only when the bundle is complete: implant (D6010 + D6056 or D6057 + one crown on the implant: D6058-D6067, D6082-D6084, D6086-D6088, D6094 or D6097), full dentures (D5110 + D5120), veneer (D2962), All-on-4 per arch (D6114 or D6115); a partial bundle returns partial_quote with what the band includes, and a single arch or partial denture gets no verdict; a bridge on implants (D6068-D6079, D6098, D6099, D6120-D6123, D6194, D6195) or a temporary implant crown (D6085) returns no_band. Crown, veneer, braces and dentures have no state band here (per-state figures not licensed for redistribution): those lines and bundles are placed against the national band. No city-level figure is published: passing city returns no_source_at_this_level and the state band applies. Phrasings: "my dentist wrote D2740 and D4341 x4 on the plan, is that in line for Arizona", "go through this dental estimate line by line", "¿es razonable este presupuesto dental en Nevada?", "revisa mi plan de tratamiento con códigos CDT". Every figure carries its source URL and period; a missing cell returns status no_source_at_this_level with the next level up. Medicaid amounts are what Medicaid paid per claim line (T-MSIS), not what a patient is charged. No personal data (age, ZIP, name, insurer) is requested or stored. Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research, not a quote, not medical, coding or insurance advice.

Input Schema

NameRequiredDescriptionDefault
cityNoOptional city in the same state, e.g. "Portland". No city-level figure is published: returns status no_source_at_this_level, and the state band applies.
langNoResponse language for labels/notes: "en" (default) or "es".en
linesYesPlan lines (1-10; split longer plans). Each line needs a code or a procedure.
stateYesTwo-letter US state code (or DC). One of: AL, AR, MS, KY, WV, IA, KS, OK, IN, SD, LA, NE, SC, GA, MO, TN, ND, OH, NC, MI, NM, WI, UT, ID, MN, TX, WY, AZ, FL, MT, CO, VA, IL, ME, PA, CT, OR, VT, DE, NV, RI, MD, WA, NH, NJ, MA, DC, AK, HI, NY, CA.
coverageNoCoverage category only (no plan or insurer name).none

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / city / description
      Previous value: -"Optional city in the same state, e.g. \"Portland\": adds the published city average for a single implant when the city is covered."New value: +"Optional city in the same state, e.g. \"Portland\". No city-level figure is published: returns status no_source_at_this_level, and the state band applies."
  2. Changed1 schema field changed
    • addedInput schema / properties / city
      Added value: +{
+  "description": "Optional city in the same state, e.g. \"Portland\": adds the published city average for a single implant when the city is covered.",
+  "maxLength": 80,
+  "minLength": 1,
+  "type": "string"
+}
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover read-only/closed-world, and the description adds substantial context beyond them: bundle completion rules, partial_quote and no_band outcomes, the no_source_at_this_level fallback to the next level up, national-band substitution where per-state figures are unlicensed, source URL/period per figure, and a privacy guarantee (no personal data stored).

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 a good trigger sentence, and most sentences carry real rules, but the body is a dense run-on paragraph enumerating CDT ranges that is hard to scan. The content is justified for this complexity; the packaging is not.

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?

With no output schema, the description does the work of explaining returned fields (cash band with observed/estimated badge, T-MSIS percentiles, fee schedule with age scope, adult Medicaid rule, numbered sources). Only the coverage parameter's effect on results is left unexplained.

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 coverage is 100%, so the baseline is 3, but the description adds interpretation rules that shape how input lines should be grouped (which code combinations form a billable bundle and which single-arch/partial inputs get no verdict). It never explains the coverage enum values, which is a remaining gap.

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?

Specific verb and resource: it places each line of a multi-line dental treatment plan against a state cash band and Medicaid benchmarks. It is clearly distinguished from siblings like dental_cost_by_state or medicaid_paid_by_code by its per-line, bundle-aware verdict behavior.

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?

Explicit trigger ('user has a treatment plan or quote from a US dentist... with quantities and quoted amounts') and explicit exclusions ('Do not use for: diagnosis, treatment choice, a named insurer's plan price...countries other than the US and Canada'). It does not name sibling tools as alternatives, so it falls 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 Real Dental Costs toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources