This server provides structured, citable US dental pricing data from the Real Dental Costs US Dental Cost Index 2026 via MCP tools. It covers 12 common procedures (exam, filling, deep cleaning, extraction, root canal, crown, whitening, veneer, braces, implant, dentures, All-on-4) across all 51 US states (including DC) and 200+ cities.
dental_cost_by_state: Get low/average/high cash prices for a procedure in a state, benchmarked against the national average and the state's dental cost index.
dental_cost_by_city: Get average implant cost and clinic count for a specific US city (implant series only), with the parent state's implant price band for context.
out_of_pocket_estimate: Estimate actual patient payment under cash (full list price), typical PPO insurance (preventive ~100%, basic ~80%, major/ortho ~50%, $1,500 annual max; cosmetic/implants not covered), or dental savings plan (~20–40% off list).
dental_national_average: Get US national average low/average/high cash price for a procedure, plus the cheapest and priciest states.
All tools support bilingual responses (en or es), affecting procedure labels, disclaimers, and Medicaid coverage notes.
Every response includes source citations, reference URLs, API URLs, and a per-procedure basis field for full traceability.
Data source: US Dental Cost Index 2026 (DOI 10.5281/zenodo.20531728).
Runs offline over stdio; no API key or network calls required.
A price-transparency data source for your AI assistant. Most dental-cost numbers floating around the web are guesses, ad copy, or averages nobody can trace back to a source. This server hands your assistant a structured, citable dataset instead: 12 common dental procedures, priced across all 51 US states (including DC) and 200+ cities, plus the insurance-coverage math that turns a list price into what a patient actually pays out of pocket.
Data comes from the Real Dental Costs US Dental Cost Index 2026 — an openly published dataset (DOI below), not a scrape or an estimate pulled from thin air.
No installation needed — run directly with npx.
Add to your MCP config (claude_desktop_config.json or .mcp.json):
{
"mcpServers": {
"realdentalcosts": {
"command": "npx",
"args": ["-y", "realdentalcosts-mcp"]
}
}
}Add to .cursor/mcp.json:
{
"mcpServers": {
"realdentalcosts": {
"command": "npx",
"args": ["-y", "realdentalcosts-mcp"]
}
}
}Restart your client after saving. The server runs entirely offline over stdio — no API key, no network calls, no telemetry.
Related MCP server: daxoom
dental_cost_by_stateLow/average/high cash price for a procedure in one US state, benchmarked against the national average and the state's dental cost index.
procedure: "implant" state: "CA"
→ California: $4,780 – $5,733 – $7,290 (observed state average, modelled band)
National average: $3,760 – $4,507 – $5,733
+27.2% vs. national average · Restorative Cost Index 127dental_cost_by_cityObserved average single-implant cost and clinic count for a specific city (206 cities, open dataset DOI 10.5281/zenodo.20819438), with the parent state's implant band for context. Only the implant series is published at city level — per-city veneer/braces figures were retired in the source site's July 2026 data-integrity work.
city: "Los Angeles" state: "CA"
→ 567 clinics
Implants avg $4,500 (CA implant band $4,780 – $7,290)out_of_pocket_estimateWhat a patient actually pays under cash, insurance (typical US PPO:
preventive ~100%, basic ~80% up to a $1,500 annual max, major/ortho ~50% up
to the same max, cosmetic/implants not covered), or savings_plan (~20-40%
network discount).
procedure: "crown" state: "TX" mode: "insurance"
→ List price: $955 – $1,250 – $2,130
Estimated out-of-pocket: $478 – $625 – $1,065
"Major tier: plan typically pays ~50%, up to the $1,500 annual max."dental_national_averageNational average across all 51 states + DC, plus the cheapest and priciest state on average.
procedure: "braces"
→ National average: $2,503 – $6,352 – $10,014
Cheapest: Indiana ($4,767 avg)
Priciest: Nevada ($8,350 avg)All four tools accept lang: "en" | "es" (default "en") — procedure
labels, disclaimers, and Medicaid coverage notes switch to Spanish, serving
the US Hispanic market covered by the source site's /es/ pages.
Every response includes source, reference_url and api_url fields plus a
per-procedure basis (observed / estimated / national) with a provenance
note, so the numbers stay traceable back to the published data they come from.
The same data this MCP server exposes is also available as a free, open JSON API — static versioned endpoints, no key, CORS enabled, documented with an OpenAPI 3.1 spec:
Metadata & DOIs: https://realdentalcosts.com/api/v1/index/meta.json
All 51 state markets: https://realdentalcosts.com/api/v1/states.json
The 12 procedures: https://realdentalcosts.com/api/v1/procedures.json
One procedure across states: https://realdentalcosts.com/api/v1/procedure/dental-implant.json
OpenAPI 3.1 spec: https://realdentalcosts.com/api/v1/openapi.json
License CC BY 4.0 — attribution required: link to https://realdentalcosts.com or cite DOI 10.5281/zenodo.20531728.
Data is derived from the US Dental Cost Index 2026, an open dataset published by Real Dental Costs:
Dataset concept DOI: 10.5281/zenodo.20531728
Full index: https://realdentalcosts.com/en/us-dental-cost-index/
Interactive state comparison: https://realdentalcosts.com/en/compare/
Methodology: https://realdentalcosts.com/en/methodology/
Every procedure carries a basis field. observed state averages are
measured prices (implant = Real Dental Costs' own observed series;
crown/veneer/braces/dentures = ASQ360/CareCredit Average Procedural Cost
Study 2023-2024), with the low/high band around them modelled from national
ratios. estimated procedures have no per-state source: the national figure
is scaled by the state's Restorative Cost Index, which is valid only for
restorative work (implant/crown/denture — it does not predict orthodontic or
cosmetic prices). national (cosmetic) procedures carry no invented state
variation. National averages are the arithmetic mean of all 51 states
(incl. DC) — never a separately invented number. No value in this package is
hand-edited or fabricated; regenerate src/data/cities.json at any time with
node scripts/extract-cities.mjs <path-to-us-dental-cost-by-city-2026.csv>.
This package provides market research pricing data — not medical advice, not a quote, and not a guarantee of what any specific dentist will charge. Actual prices vary by clinic, provider, insurance plan, and case complexity. Always confirm pricing directly with a licensed dental provider before treatment.
MIT © tresor4k
Get average dental costs (implants, veneers, braces) and clinic counts for a specific US city. Example: city="Miami" returns Miami's average prices plus the parent state's low/high range for context (city-level data in the source is a single observed average per procedure — no separate city min/max exists upstream). Pass "state" (2-letter code) to disambiguate same-named cities. Market research pricing data, not medical or financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name, e.g. "Austin" or "San Diego". | |
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| state | No | Optional 2-letter state code to disambiguate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains that city data is a single observed average per procedure (no min/max), includes state low/high range for context, and notes the data is market research not advice. This adds useful limitations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 3 sentences, front-loaded with the purpose, and includes an example, data limitation note, and disclaimer. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what is returned (average prices, state range, clinic counts) and the data limitation. It could be more explicit about the output structure, but the example and context are sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 3 parameters. The description adds marginal value with an example and mention of state disambiguation, but the schema already describes parameters well. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'average dental costs and clinic counts for a specific US city', specifying procedures (implants, veneers, braces). It distinguishes from siblings like dental_cost_by_state and dental_national_average by noting it returns city data plus parent state range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example and mentions using the 'state' parameter to disambiguate, but does not explicitly state when to use this tool versus alternatives (e.g., state-level or national tools). Usage context is implied but lacks direct guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the low/average/high cash price for a dental procedure in a specific US state, compared to the national average. Example: procedure="implant", state="CA" returns California's single-implant price range plus how it compares to the 51-state (incl. DC) national average and the state's dental cost index. Market research pricing data, not medical or financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| state | Yes | Two-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. | |
| procedure | Yes | Procedure id. One of: exam (Exam, cleaning & X-rays), filling (Composite filling (1 tooth)), deepclean (Deep cleaning (SRP, per quadrant)), extraction (Tooth extraction), rootcanal (Root canal), crown (Dental crown), whitening (Professional teeth whitening), veneer (Porcelain veneer (per tooth)), braces (Braces (traditional, full case)), implant (Single dental implant (complete)), dentures (Full set of dentures (both arches)), allon4 (All-on-4 (per arch)). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns market research pricing data, not medical/financial advice, and hints at the comparison metric. It does not mention data freshness or error handling, but the enums in schema prevent invalid inputs. Overall, it is fairly transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by an example and a disclaimer. Every sentence adds value, and there is no extraneous information. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (all described in schema with enums), no output schema, and no annotations, the description is complete enough. It covers what the tool returns (price range, national comparison, cost index) and includes a disclaimer. Some minor details (like pagination or exact format) are missing, but it adequately informs an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by illustrating how parameters work in context (e.g., 'procedure="implant", state="CA" returns...'). It reinforces that state is a two-letter code and procedure uses specific IDs. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'dental cost by state', specifies it returns low/average/high cash price compared to national average, and includes an example. It effectively distinguishes from sibling tools like dental_cost_by_city (city scope) and dental_national_average (national scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit example (implant in CA) and explains the output. While it doesn't explicitly state when to use vs. alternatives, the sibling context (e.g., by_city for city-level, national_average for national only) implies appropriate use cases. No exclusions are given, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the US national average low/avg/high cash price for a dental procedure (mean across all 51 states + DC), plus which state is cheapest and priciest on average. Example: procedure="veneer". Market research pricing data, not medical or financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| procedure | Yes | Procedure id. One of: exam (Exam, cleaning & X-rays), filling (Composite filling (1 tooth)), deepclean (Deep cleaning (SRP, per quadrant)), extraction (Tooth extraction), rootcanal (Root canal), crown (Dental crown), whitening (Professional teeth whitening), veneer (Porcelain veneer (per tooth)), braces (Braces (traditional, full case)), implant (Single dental implant (complete)), dentures (Full set of dentures (both arches)), allon4 (All-on-4 (per arch)). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It states the output includes low/avg/high cash prices and cheapest/prisest state, plus the disclaimer that it's market research data, not advice. This adequately discloses the read-only, non-destructive nature and the data source. No hidden side effects are mentioned, but none are expected for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example. It starts with the core action ('Get the US national average...') and front-loads the most important information. Every sentence adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description sufficiently explains what the tool returns: low/avg/high cash prices and cheapest/priciest state. It also provides a disclaimer about the nature of the data. No critical details appear missing for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not add significant parameter-level detail beyond the schema; it only gives an example ('procedure="veneer"'). The schema already has comprehensive enum descriptions for procedure and lang. Thus, the description adds minimal value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it retrieves the US national average cost for a dental procedure, including low/avg/high prices and cheapest/priciest states. The verb 'Get' and resource 'national average dental cost' are clear, and the example 'procedure="veneer"' reinforces the purpose. It distinguishes well from sibling tools that focus on city or state averages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit 'use this when' or direct comparison to siblings, the description clearly defines the scope as 'US national average' and 'mean across all 51 states + DC'. The sibling names (dental_cost_by_city, dental_cost_by_state, out_of_pocket_estimate) themselves indicate alternative scopes, so an agent can infer that this tool is for nationwide averages. The disclaimer about market research data provides a usage note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate what a patient actually pays for a dental procedure in a given state under a payment mode: "cash" (full list price), "insurance" (typical US PPO plan: preventive ~100%, basic ~80% up to a $1,500 annual max, major/ortho ~50% up to the same max, cosmetic/implants not covered), or "savings_plan" (dental discount plan, ~20-40% off list price). Example: procedure="crown", state="TX", mode="insurance". Market research pricing data, not medical or financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| mode | Yes | Payment mode: "cash", "insurance", or "savings_plan". | |
| state | Yes | Two-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. | |
| procedure | Yes | Procedure id. One of: exam (Exam, cleaning & X-rays), filling (Composite filling (1 tooth)), deepclean (Deep cleaning (SRP, per quadrant)), extraction (Tooth extraction), rootcanal (Root canal), crown (Dental crown), whitening (Professional teeth whitening), veneer (Porcelain veneer (per tooth)), braces (Braces (traditional, full case)), implant (Single dental implant (complete)), dentures (Full set of dentures (both arches)), allon4 (All-on-4 (per arch)). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it explains each payment mode's coverage (e.g., insurance caps, exclusions) and notes that data is market research, not advice. This adds significant behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: first sentence states purpose, then defines modes with key details, followed by an illustrative example and a disclaimer. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 enum parameters, no output schema), the description covers all necessary aspects: what it does, how modes work, what procedures are, and limitations. It leaves no critical gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters, the description enriches them by explaining payment modes in detail, providing an example, and clarifying procedure IDs implicitly, adding value beyond the enum lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool estimates out-of-pocket costs for a dental procedure under a specific payment mode, distinguishing it from sibling tools that likely provide average costs without payment mode consideration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage from the description is clear (when you need an out-of-pocket estimate with a payment mode), but there is no explicit guidance on when to use alternative siblings or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dental_cost_by_citydental_cost_by_statedental_national_averageout_of_pocket_estimateScored across 4 tools
Each tool targets a distinct geographic or pricing use case: city-level, state-level, national average, and out-of-pocket estimation. No overlap in purpose, and descriptions clearly differentiate them.
All tools follow a consistent `dental_` prefix followed by a descriptive noun phrase (e.g., `dental_cost_by_city`, `out_of_pocket_estimate`). Pattern is uniform and predictable.
With 4 tools, the set is slightly small but well-scoped for the domain of US dental cost queries. No tool feels redundant, and the count is appropriate for the focused purpose.
Covers the primary queries: costs by city, state, national average, and out-of-pocket estimates. Minor gaps like a list of procedures or a comparison tool across states exist, but the core use cases are addressed.
Read-only MCP: US dental intel, all-category Medicaid fee schedules, dentist lookup. Free tier.
Live US drug acquisition costs (CMS NADAC) for AI assistants. Free, no auth, weekly data.
US healthcare data for AI agents: CMS, FDA adverse events, CDC, NPPES NPI. Keyless, real samples.
Pay-per-call US healthcare data: hospital financials, prices, quality, exclusions, wages.
