Sourced US and Canadian dental prices, Medicaid and Medicare dental rules, treatment-plan checker.
Scored across 13 tools
The cost tools are mostly cleanly separated by scope: national average, single-state cost, multi-state comparison, quoted-plan benchmarking, and insurance out-of-pocket estimation. The main overlap is that benchmark_treatment_plan also returns Medicaid paid amounts and adult Medicaid rule context, which touches the Medicaid-specific tools, but the intended entry points are still distinguishable.
All names use consistent snake_case and are descriptive, mostly following a domain_topic pattern such as dental_cost_by_state, medicaid_paid_by_code, and cdcp_coverage_check. The minor inconsistency is that two tools use leading verbs (benchmark_treatment_plan, compare_states) while the rest are noun-phrase labels.
Thirteen tools is well within a reasonable range for a dental-cost research server covering US, Canadian, public-program, and private-insurance queries. Each tool maps to a distinct query family and none appears redundant enough to remove.
The surface is broad: US cash costs, state comparisons, national averages, Medicaid reimbursement and rules, Medicare, private insurance estimates, low-cost options, Canadian provincial costs, CDCP, and spending statistics are all covered. Minor gaps remain, such as a dedicated cash-price-by-CDT-code lookup and child Medicaid/CHIP coverage rules, but core workflows are supported.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | 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. | |
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| lines | Yes | Plan lines (1-10; split longer plans). Each line needs a code or a procedure. | |
| 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. | |
| coverage | No | Coverage category only (no plan or insurer name). | none |
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.
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.
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.
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.
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.
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.
Use this when the user asks what a dental procedure costs in a Canadian province, for one of 9 procedures: recall exam, scaling (per unit), one-surface composite filling, simple extraction, molar root canal, complete denture, cast partial denture, ceramic crown, single implant. Returns the amount in Canadian dollars per row from the provincial suggested-fee guide or the listed source, with its source URL and an estimated badge where the dataset marks one (open dataset, DOI 10.5281/zenodo.20744781, 10 provinces; territories return no_source_at_this_level). Rows under a data-quality review are withheld with their issue number. Phrasings: "what does a crown run in Alberta", "root canal fees in Nova Scotia", "¿cuánto cuesta una limpieza dental en Ontario?", "costo de un implante dental en Columbia Británica". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| province | Yes | Two-letter Canadian province or territory code. One of: AB, BC, MB, NB, NL, NS, NT, NU, ON, PE, QC, SK, YT. | |
| procedure | No | Optional procedure key; all 9 when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description nonetheless adds substantive behavior: CAD amounts per row, source URL and estimated badge, the Zenodo DOI, that territories return no_source_at_this_level, and that rows under data-quality review are withheld with an issue number. It does not cover pagination or full return shape, so it lands clearly above baseline but short of exhaustive.
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?
Front-loaded with the trigger condition and procedure list, then return shape, then exclusions — a logical order. It is dense but nearly every clause carries information; the four multilingual example phrasings are the only mildly expendable element.
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?
With no output schema present, the description compensates fully by describing the row shape (amount, source URL, estimated badge), the withholding behavior for reviewed rows, and the territory no_source outcome. There is no material gap an agent would need to call this correctly.
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 enum values are already documented. The description still adds value by mapping procedure keys to plain-language names ('molar root canal', 'cast partial denture') and by flagging that territories (NT/NU/YT, which are valid enum values) yield no_source_at_this_level — context an agent cannot infer from the schema alone.
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 names a specific verb+resource (dental procedure costs in a Canadian province) and enumerates all 9 supported procedures, which immediately separates it from the US-focused sibling dental_cost_by_state. An agent can identify the exact domain without opening the schema.
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?
Explicit 'Use this when the user asks...' trigger followed by a concrete 'Do not use for:' exclusion list (diagnosis, treatment choice, insurer plan price, dentist recommendations, non-Canada/US countries). It also gives sample phrasings in English and Spanish, which pins down the intended invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether the Canadian Dental Care Plan (CDCP) covers a dental procedure and what share they would pay, given an adjusted family net income and a province. Returns the CDCP income tier (share paid by the plan and co-pay percentage), the coverage status and pre-authorization rule of each of the 9 procedures from the federal plan guide, and, when a procedure is given, an estimated co-pay in Canadian dollars on the provincial fee reference (badge estimated; the plan pays on its own fee grid). Only an income figure and a province are asked: no name, SIN, date of birth or insurer. Phrasings: "would CDCP pay for a crown with a family net income of 75k in Ontario", "my share for a filling under the federal dental plan in Manitoba", "¿el plan dental canadiense cubre una endodoncia si la familia gana 72 000 al año?", "copago del CDCP para una extracción en Québec". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| province | Yes | Two-letter Canadian province or territory code. One of: AB, BC, MB, NB, NL, NS, NT, NU, ON, PE, QC, SK, YT. | |
| procedure | No | Optional procedure key for an estimated co-pay. | |
| adjusted_family_net_income_cad | Yes | Adjusted family net income in Canadian dollars (the tax-return figure). No other personal data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, but the description adds important behavioral context: co-pay is an estimate on the provincial fee reference, the plan pays on its own fee grid, no name/SIN/DOB/insurer is requested, figures carry a source URL and period, and output is not a quote or medical advice. No annotation contradiction is present.
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 front-loaded with the use condition and return summary, and every section is relevant to correct invocation. It is somewhat long due to four multilingual example phrasings and the provenance sentence, but it remains well structured rather than padded.
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?
There is no output schema, so the description carries the return-value burden and does so thoroughly: it explains the income tier, coverage and pre-authorization status across 9 procedures, and the optional dollar co-pay estimate with estimation caveats. Given the read-only annotations and complete input schema, nothing critical is missing.
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%, so the schema already documents all four parameters and their enums. The description reinforces that adjusted family net income and province are the key inputs and that procedure is optional for co-pay estimation, but it adds little parameter-level detail beyond the schema, especially for the lang parameter.
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?
States a specific check of Canadian Dental Care Plan coverage and co-pay, names the federal plan, the required income/province inputs, and the returned income tier, coverage status, pre-authorization rule, and estimated co-pay. This is clearly distinguishable from generic dental cost or insurer-plan tools.
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?
Opens with an explicit 'Use this when...' condition and includes a clear 'Do not use for' list covering diagnosis, treatment choice, named insurer pricing, dentist recommendations, and non-US/Canada cases. It also gives multilingual example phrasings, but does not name a sibling alternative for non-CDCP cost questions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user names two to five US states and asks what one of the 12 procedures (exam and cleaning, filling, deep cleaning, extraction, root canal, crown, implant, All-on-4, dentures, braces, veneer, whitening) costs in each, or in which of them it costs less, for instance before a move or before travelling for care. Returns, for each state, the cash band (low / average / high) in US dollars with its basis badge (observed or estimated), its rank among the 51 state averages and its gap in percent to the national mean, plus the national band. Every row comes from the same series with its source and period, so the states are lined up on one basis; cosmetic procedures carry no state variation. For crown, veneer, braces and dentures each state row returns no_source_at_this_level (ASQ360/CareCredit per-state figures, not licensed for redistribution) and only the national band is given. Phrasings: "line up implant costs in Texas, Florida and Arizona", "fillings in Ohio and Michigan side by side", "¿dónde sale más barato un implante, en Texas o en California?", "compara el costo de una endodoncia en Nueva York y Nueva Jersey". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| states | Yes | 2 to 5 two-letter state codes (DC allowed). | |
| 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), allon4 (All-on-4 (per arch)), whitening (Professional teeth whitening), crown (Dental crown), veneer (Porcelain veneer (per tooth)), braces (Braces (traditional, full case)), implant (Single dental implant (complete)), dentures (Full set of dentures (both arches)). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, but the description adds substantial behavioral context: return structure, USD cash bands, basis badges, state rank, gap to national mean, sourcing and period consistency. It also discloses important procedure-specific caveats, including cosmetic procedures having no state variation and several procedures returning no_source_at_this_level.
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 front-loaded with the use case and then adds return details, caveats, examples, and exclusions. It is dense and somewhat long, but nearly every sentence carries routing or behavioral information; a small amount of example/query text could be trimmed without losing essentials.
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?
No output schema exists, so the description needs to explain return values, and it does: cash band, basis badge, rank, gap to national mean, national band, source and period. It also covers limitations and exclusions needed to invoke the tool correctly.
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 enum values and state codes are already fully documented. The description still adds meaningful semantics beyond the schema by explaining that procedures vary by state availability and by calling out which procedures lack per-state licensed figures.
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 states a specific comparison verb and resource: side-by-side dental costs for 2 to 5 US states across 12 named procedures. It clearly scopes the tool to multi-state comparison rather than single-state or national tools, so an agent can distinguish it from siblings without opening the schema.
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?
It explicitly says when to use the tool, including example phrasings in English and Spanish, and gives clear exclusions: no diagnosis, treatment choice, insurer-specific pricing, dentist recommendations, or non-US/Canada countries. This leaves little ambiguity about routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what a dental procedure costs in a given US state (51 incl. DC), or how a state sits next to the US average, for one of 12 procedures: exam and cleaning, filling, deep cleaning, extraction, root canal, crown, implant, All-on-4, dentures, braces, veneer, whitening. Returns the state cash band (low / average / high) in US dollars, the national band, the gap in percent and the state's Restorative Cost Index. For crown, veneer, braces and dentures it returns no state figure: those per-state figures (ASQ360/CareCredit Average Procedural Cost Study 2023-2024) are cited on realdentalcosts.com pages but not licensed for redistribution, so the answer gives status no_source_at_this_level, the study link and the national band. Each figure is labelled observed or estimated, with a note naming the study behind it and its period (implants from Real Dental Costs' editorial estimate, edition 2026.1, DOI 10.5281/zenodo.20531728, not collected data, state ranking validated against ASQ360, levels not verified; other procedures scaled from the national figure and marked estimated), so the answer can say where the state number comes from and how old it is. Phrasings: "how much is a filling in Ohio without insurance", "what do people in Florida pay for a root canal", "¿cuánto cuesta un implante dental en Texas?", "costo de una limpieza dental en California". When the user already has an amount quoted by their dentist and asks whether it is normal, use benchmark_treatment_plan instead: it places the quoted amount against this band line by line. Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical 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), allon4 (All-on-4 (per arch)), whitening (Professional teeth whitening), crown (Dental crown), veneer (Porcelain veneer (per tooth)), braces (Braces (traditional, full case)), implant (Single dental implant (complete)), dentures (Full set of dentures (both arches)). | |
| quoted_usd | No | Optional amount quoted to the user for this procedure, in US dollars, in the unit of the procedure label (per tooth, per arch, full set): returns its position in the state band. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say read-only and closed-world; the description goes much further by disclosing the licensing restriction that suppresses state figures for crown/veneer/braces/dentures and the resulting no_source_at_this_level status, plus observed-vs-estimated labelling, the underlying study and period, and the DOI. That is exactly the behavioral context an agent needs to relay a caveat rather than invent a number.
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?
Front-loaded with the trigger and the return shape before the caveats, and the long source/licensing passage is load-bearing rather than filler. It is still a very dense single block, and the four example phrasings plus provenance detail make it heavier than the routing decisions require.
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?
With no output schema, the description does the work of explaining return fields, the no-source status, and figure provenance, which is enough to call it correctly. The one loose end is the unmentioned quoted_usd input, whose existence conflicts with the instruction to send quoted amounts to benchmark_treatment_plan.
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% and enum labels are documented, so the description only needs to add meaning; it does so by expanding procedure ids into plain-language procedures and by flagging which procedure values have no per-state data. The gap is quoted_usd: the schema accepts it and says it returns the amount's position in the band, yet the description never mentions it and instead routes quote-checking to benchmark_treatment_plan, leaving that parameter's role ambiguous.
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?
States a specific verb+resource (returns dental procedure cost bands for a US state) plus the exact shape of the answer: state cash band low/average/high, national band, percent gap, and Restorative Cost Index. It also carves out four procedures where no state figure is returned, which distinguishes it from the national-average and comparison siblings.
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?
Gives explicit triggers (user asks what a procedure costs in a state, or how a state compares to the US average), names the alternative for a different case (benchmark_treatment_plan when the user has a dentist's quote), and lists explicit exclusions (diagnosis, treatment choice, insurer plan prices, dentist recommendations, non-US/Canada).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what a dental procedure costs in the United States in general, with no state named, for one of the 12 procedures. Returns the national cash band (low / average / high, mean of the 51 state figures incl. DC), its basis (observed or estimated) and the states at both ends of the range of state averages; cosmetic procedures carry no state variation. Phrasings: "average cost of dentures in the US", "typical US cost for braces", "¿cuánto cuesta una endodoncia en Estados Unidos?", "costo promedio de carillas en EE. UU.". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical 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), allon4 (All-on-4 (per arch)), whitening (Professional teeth whitening), crown (Dental crown), veneer (Porcelain veneer (per tooth)), braces (Braces (traditional, full case)), implant (Single dental implant (complete)), dentures (Full set of dentures (both arches)). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotations, the description explains the returned national cash band, its observed/estimated basis, the states at both ends of the range, and that cosmetic procedures carry no state variation. It also discloses data provenance ('source URL and period on every figure') and safety limits ('not a quote, not medical advice').
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 dense but front-loaded: the core use case comes first, followed by return details, examples, exclusions, and provenance. Every sentence contributes to correct tool selection or interpretation, and the examples are directly useful for multilingual routing.
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?
With no output schema, the description carries the burden of explaining return values and does so thoroughly: band values, basis, endpoint states, cosmetic exception, and data source. It also covers scope limits and non-goals, leaving little ambiguity for an agent invoking this 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%, so the procedure enum and language parameter are already well documented in the schema. The description adds little parameter-level meaning beyond noting that the procedure must be one of the 12, which is already captured by the enum.
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 gives a specific verb and resource: national US dental procedure cost for one of 12 procedures when no state is named. It clearly distinguishes itself from siblings such as dental_cost_by_state and canada_dental_cost_by_province by scoping the answer to the US overall.
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?
It states when to use the tool ('no state named'), provides concrete example phrasings, and lists explicit exclusions such as diagnosis, insurer plan prices, and non-US/Canada countries. It does not name the exact alternative sibling tools to use for named states or Canada, so routing is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what changed, or when a change took effect, in a US public dental program: Medicaid dental fee schedule updates and rate changes, or the start date of an adult Medicaid annual dental cap. Returns adopted changes with their effective date, verbatim quote or data file and source URL, filterable by state and by date range (YYYY-MM-DD); the Texas rate change of September 2026 lists its codes when state is TX. A state without dated tracking returns not_yet_tracked, never a claim that nothing changed. Phrasings: "what changed in Texas Medicaid dental reimbursement this fall", "since when does Colorado cap adult Medicaid dental benefits", "¿qué cambió en el Medicaid dental de Nevada en 2026?", "¿desde cuándo hay un límite anual dental en Medicaid de Massachusetts?". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional end of the period (YYYY-MM-DD), on effective dates. | |
| from | No | Optional start of the period (YYYY-MM-DD), on effective dates. | |
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| state | No | Optional 2-letter state code; all tracked states when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, and closed-world, so the safety profile needs no restating. The description earns credit by disclosing non-obvious return behavior: every figure ships with a source URL and period, verbatim quotes, and a 'not_yet_tracked' sentinel for untracked states that explicitly must not be read as 'nothing changed' — an absence-handling rule an agent could not infer.
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?
Purpose and trigger conditions are correctly front-loaded, but the body pads out with four quoted example questions across two languages and a trailing boilerplate line about market research and 'not medical advice.' Roughly a third of the text could be cut with no loss of routing signal.
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?
With no output schema, the description carries the return-value burden and does so: it names the record contents (adopted change, effective date, verbatim quote or data file, source URL) and the sentinel case. For a 4-parameter, all-optional filter tool, nothing an agent needs to call it correctly is missing.
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 goes beyond it by clarifying that from/to filter on effective dates rather than publication dates, and by noting that the state parameter changes result shape (TX lists individual CPT codes for the Sep 2026 rate change). The lang parameter is left entirely to the schema, which covers it adequately.
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?
States a specific resource (dated changes in US public dental programs), the two question shapes it answers (what changed, when a change took effect), and the underlying data type (adopted changes with effective dates). This separates it cleanly from siblings like medicaid_adult_dental_rules (current rules) and medicaid_paid_by_code (code-level payment) without needing to open either schema.
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?
Explicit routing on both sides: an affirmative 'use this when the user asks what changed / when a change took effect' plus a 'Do not use for' list covering diagnosis, treatment choice, insurer pricing, dentist recommendations and non-US/Canada geographies. Example user phrasings in English and Spanish further anchor the trigger conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user has a private dental plan or a Medicare Advantage plan with dental benefits, knows its figures (deductible left, annual maximum left, coinsurance per procedure or per class), and asks what they would still pay for dental work in a US state. Every plan parameter comes from the user; the tool assumes none and names no insurer. Returns, per line, the state cash band (observed or estimated badge; the national band for crown, veneer, braces and dentures, whose per-state figures are not published here) and an estimated split (deductible, plan share, user share) on the low, average and high of the band, with the formula written out; a line missing a parameter is not computed and says which one. Phrasings: "my plan has 50 dollars of deductible left and 1,200 of annual max, coinsurance 50% on crowns, what would a crown in Ohio leave me to pay", "estimate my share for a root canal and a crown with my Medicare Advantage dental benefit in Florida", "¿cuánto me tocaría pagar por un implante con mi seguro dental si me quedan 800 del máximo anual?", "¿cuál sería mi parte de una endodoncia con coaseguro del 20% en Texas?". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| lines | Yes | Lines in the order the user expects them to be billed (1-10). | |
| 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. | |
| coverage | Yes | Coverage category only (no plan or insurer name). | |
| no_annual_maximum | No | true only if the user's plan document states no annual maximum. | |
| coinsurance_by_class | No | The user's coinsurance in percent per class label they provide, e.g. their plan's own class names. | |
| annual_max_remaining_usd | No | Annual maximum still available this benefit year, in US dollars. Required unless no_annual_maximum is true. | |
| deductible_remaining_usd | No | Deductible still to meet this benefit year, in US dollars (0 if met). Required to compute. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag a safe read-only, non-open-world operation; the description adds substantial behavioral context: no assumed plan values, observed/estimated bands, formula written out, and uncomputed lines reported with the missing parameter. This is well beyond what the annotations provide.
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?
It front-loads the usage condition and keeps the return behavior in a compact block, but the four example phrasings and the do-not-use/provenance caveats make it longer than necessary. The length is still defensible for an 8-parameter nested tool.
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?
For a complex, read-only estimator with no output schema, the description explains the returned bands, badges, splits, formula, and missing-parameter behavior well. The only notable completeness flaw is the "US and Canada" exclusion line, which conflicts with the schema's US-only state enum.
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%, and the schema already documents all eight parameters in detail. The description reinforces the user-supplied plan inputs and gives examples, but adds little parameter-level syntax or constraints beyond the schema.
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 opening sentence states the specific estimate and the exact precondition: user-supplied deductible, annual max, and coinsurance figures for a US state. It also rules out named-insurer quotes and medical advice, so an agent can separate this from the benchmark and state-cost siblings.
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?
It gives explicit "Use this when" criteria and a "Do not use for" list, plus representative phrasings. It does not name alternative sibling tools for cases like missing plan figures, and the "US and Canada" exclusion line is potentially inconsistent with the schema's US-only state enum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user in a US state looks for low-cost or free dental care, or asks where to get dental work on a tight budget. Returns a list for that state where each route names its source and check date: dental schools with patient clinics (name, city, clinic URL, verified date), the count of HRSA dental shortage-area (HPSA) designations with the date of the HRSA file and the health-center finder link, Mission of Mercy events and charity programs (Dental Lifeline Network and named clinics), with an optional county for the dental-desert atlas row. Dental-school clinic fees are not published by Real Dental Costs. Phrasings: "where can I get dental work on a tight budget in Columbus", "dental school clinics that see patients in Ohio", "¿dónde hay dentistas gratis en Illinois?", "clínicas dentales de bajo costo en Franklin County". Also use it when the user asks whether their county is a dental shortage area or where the community health centers are. 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.
| 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. | |
| county | No | County name, e.g. "Franklin". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnly, non-destructive, and not open-world, while the description adds rich behavioral context: source URLs and periods on figures, the no_source_at_this_level missing-data status, T-MSIS Medicaid payment interpretation, no personal data storage, and market-research/non-advice caveats. No annotation contradiction is present.
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 front-loads the use case and output shape, and its long return-detail list is justified because there is no output schema. A few repeated disclaimers and four example phrasings make it longer than strictly necessary, so it is efficient but not maximally concise.
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?
For a complex tool with no output schema, the description explains returned fields, source and check dates, missing-data behavior, privacy constraints, and exclusion boundaries. Annotations cover safety and the schema covers parameters, leaving no material gap for an agent to call it correctly.
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 state, lang, and county are already well documented in structured fields. The description adds that county is optional for the dental-desert atlas row and that state scopes the returned list, but it does not explain lang or add enum-level guidance, making this baseline adequate rather than rich.
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?
States a specific verb and resource: returns low-cost or free dental care options for a US state, enumerating dental-school clinics, HPSA counts, charity programs, and related routes. It differentiates from adjacent data tools through exclusions such as insurer plan prices, dentist recommendations, diagnosis, and treatment choice, but does not name sibling tools.
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?
Gives explicit when-to-use guidance, bilingual example phrasings, and a do-not-use list covering diagnosis, insurer prices, dentist recommendations, and non-US/Canada queries. It lacks named sibling 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.
Use this when the user asks whether adult Medicaid covers dental care in a US state, what it covers, whether it has a yearly dollar limit or how much that limit is. Returns the state's adult Medicaid dental level with its sources. For the annual dollar cap: the amount, the benefit period and a verbatim quote with the URL it was read from (CareQuest Institute coverage checker or state Medicaid documents) and its retrieval date, so the answer can cite a dated figure for that state (cap_kind annual_dollar_cap, no_dollar_cap, emergency_only, no_adult_benefit, or not_verified when no source confirms it). Also: program summary with its check date, orthodontics and implants policy (verified, silent or not_verified, with a quote), share of dentists billing Medicaid (T-MSIS 2023-2024) and the official fee schedule (URL, effective date, age scope). Phrasings: "does Medicaid cover adult dentures in Georgia", "is there a yearly dental limit on Medicaid in Massachusetts", "¿Medicaid cubre el dentista para adultos en Texas?", "límite anual dental de Medicaid en Nueva York". 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.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, so safety is largely covered. The description still adds substantive behavior beyond them: the enumerated cap_kind outcomes (including not_verified), the no_source_at_this_level fallback with escalation to 'the next level up', the dated-source quoting convention, the T-MSIS caveat that amounts are paid-per-claim-line rather than patient charges, and a privacy statement. It does not state latency or rate limits, so it falls just short of the top score.
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 front-loaded with the core use case and the exclusion list at the end, which is good structure. However it is roughly 200 words with redundancy: the sourced-and-dated claim is made twice ('a verbatim quote with the URL it was read from… and its retrieval date' and again 'Every figure carries its source URL and period'), and the enumeration of returned fields is dense enough to be hard to scan.
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?
There is no output schema, so the description accepts the burden of describing returns, and it does so thoroughly: cap kind taxonomy, benefit period, quote provenance and retrieval date, program summary check date, orthodontics/implants status, dentist participation data vintage (T-MSIS 2023-2024), fee schedule URL/effective date/age scope, and the no_source fallback path. Scope limits and privacy behavior are also covered, leaving no material gaps for correct invocation.
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% and both parameters are enum-bounded with full documentation, so the schema carries the semantic load. The description says nothing explicit about the `state` or `lang` parameters, though the Spanish example phrasings implicitly signal the `lang` option. Baseline 3 is the right level here.
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 first sentence states the exact question class it answers (adult Medicaid dental coverage, scope, annual dollar limit, limit amount) in a specific US state, naming the resource and the decision it supports. It returns named fields (cap_kind values, program summary, orthodontics/implants, dentist participation, fee schedule), which is far more specific than the title. It is clearly separable from siblings like medicaid_paid_by_code (claim-line spend) and compare_states (multi-state comparison).
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?
Explicit trigger conditions are given (coverage, scope, yearly limit, limit amount) along with concrete example phrasings in English and Spanish. An explicit exclusion block follows ('Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada'), which routes the agent to siblings such as dental_cost_by_state or insurance_out_of_pocket.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what Medicaid pays or paid for a CDT dental code (61 codes), nationally or in a US state. Returns the amount paid per claim line from T-MSIS (2018-2024 series, percentiles), the state cell with its rank and the official fee when a state is given (age scope children_only or not_verified: context only), and the national cash band for context. Phrasings: "Medicaid reimbursement for D7140 in Ohio", "what does Medicaid pay a dentist for code D2750", "¿cuánto paga Medicaid por el código D2391?", "reembolso de Medicaid por D1110 en Florida". 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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | CDT code, e.g. "D2740". | |
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| state | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, closed-world; the description adds substantive behavior beyond them: data source (T-MSIS), period, percentile methodology, the exact fallback semantics ('no_source_at_this_level' with next level up), source URL per figure, the children_only/not_verified age-scope caveat, and a privacy statement. It also preempts a likely misreading by stating these are paid amounts, not patient charges.
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?
Front-loaded with the trigger and the return shape before caveats and exclusions, so the critical information comes first. It is dense and carries some redundancy (the 'not what a patient is charged' point is restated by the 'not a quote' disclaimer), but nearly every clause adds routing or interpretation value.
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?
No output schema exists, and the description compensates by describing the return payload in detail: per-claim-line amount, percentiles, state cell with rank and official fee, national cash band, per-figure source URL and period, and the missing-data status. Combined with the privacy and advice disclaimers, nothing material is left unspecified.
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 goes further by explaining what supplying `state` actually changes (adds the state cell with rank and official fee, subject to age scope) and by demonstrating Spanish output via `lang` in the example phrasings. It does not explain syntax beyond the schema's pattern, which keeps it below a 5.
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?
States a specific verb and resource (what Medicaid pays/payed per claim line for a CDT code), plus scope: national vs. US state, T-MSIS 2018-2024 percentiles. It is clearly separable from siblings like medicaid_adult_dental_rules (eligibility rules) or dental_cost_by_state (charge-based costs).
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?
Opens with an explicit 'Use this when...' trigger, supplies four representative phrasings in English and Spanish, and adds an explicit 'Do not use for' exclusion list (diagnosis, treatment choice, named insurer plan price, non-US/Canada). This is about as complete as routing guidance gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether Medicare covers dental work (cleanings, fillings, extractions, dentures, implants), what Original Medicare (Part A or Part B) does for teeth, or in which cases Medicare pays toward dental care. Returns the rule as verbatim legal text, each quote with its source URL and retrieval date: the statutory exclusion (Social Security Act 1862(a)(12)), the regulation (42 CFR 411.15(i)) and the medicare.gov coverage page with its narrow exceptions (dental care tied to a hospital admission or to certain covered medical treatments), plus the dated Medicare Advantage open enrollment period, so the answer can quote the rule itself. Medicare Advantage plans for 2027 and their dental limits plan by plan are not yet tracked; for a plan whose figures the user knows, it points to insurance_out_of_pocket. Phrasings: "will Medicare pay for my dentures", "is a tooth extraction covered by Part B", "¿Medicare cubre los implantes dentales?", "¿Medicare paga la limpieza dental?". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
| coverage | No | The user's Medicare coverage category, if known (no plan name). | not_sure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and non-destructive annotations, the description discloses the exact return behavior: verbatim legal text with source URLs and retrieval dates, specific statutory and regulatory citations, medicare.gov exceptions, and dated Medicare Advantage open enrollment information. It also clearly states a current limitation: Medicare Advantage 2027 plan dental limits are not tracked plan by plan.
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 front-loaded with the core use case and return content, then adds exclusions and alternative routing. It is somewhat long and includes multiple phrasings and disclaimers, but the information is largely useful rather than repetitive.
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?
For a read-only reference tool with no output schema, the description is complete enough: it explains what the tool returns, the legal sources included, the scope limitations, and where to route plan-specific inquiries. Safety behavior is covered by annotations, and parameters are fully documented in the schema.
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%, and both parameters have enum descriptions, so the schema already carries the parameter semantics. The description does not add meaningfully to the lang or coverage parameter definitions beyond implying bilingual support and coverage categories.
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 states a specific verb and resource: answering whether Medicare covers dental work, including what Original Medicare does for teeth and when Medicare pays toward dental care. It clearly distinguishes itself from siblings by naming insurance_out_of_pocket for known plan figures and noting that Medicare Advantage plan-level dental limits are not tracked.
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?
It gives explicit when-to-use guidance with example phrasings in English and Spanish, and explicit when-not-to-use exclusions: diagnosis, treatment choice, named insurer plan pricing, dentist recommendations, and non-US/Canada countries. It also names the alternative tool for plan-specific out-of-pocket figures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how much people in the United States spend on dental care in a year, what share they pay out of pocket, or how many people see a dentist, at national level. Returns survey-weighted national figures from the federal Medical Expenditure Panel Survey (MEPS, AHRQ) for 2023 and 2024: spending per person, out-of-pocket amounts (mean, median, share of spending), total spending, share of people with a dental visit, plus the paired 2023-2024 change for the same persons with its 95% confidence interval. Person-level spending, not the cost of a procedure: procedure costs go to dental_cost_by_state. Phrasings: "how much does a typical American spend at the dentist per year", "what part of dental bills do US households cover themselves", "¿cuánto gasta al año un estadounidense en el dentista?", "gasto de bolsillo en odontología en Estados Unidos". Do not use for: diagnosis, treatment choice, a named insurer's plan price, dentist recommendations, countries other than the US and Canada. Market research and public program data with a source URL and period on every figure; not a quote, not medical advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language for labels/notes: "en" (default) or "es". | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it as a read-only, closed-world, non-destructive lookup, and the description adds real substance on top: survey-weighted figures, data vintage (2023-2024), 95% confidence intervals on the change, a source URL and period on every figure, and the caveat that results are not a quote or medical advice. With no output schema, it also enumerates what comes back (per-person spending, mean/median out-of-pocket, total spending, visit share).
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?
Front-loaded with the trigger condition and scope, then returns, then disambiguation, which is the right order. It is somewhat long: four verbatim example queries and a trailing compliance sentence ('Market research and public program data... not a quote, not medical advice') add bulk beyond what an agent strictly needs.
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?
For a zero-required-parameter informational lookup, the definition covers everything an agent needs: what is returned, the data source and vintage, the statistical treatment (survey weighting, confidence intervals), the geographic and topical boundaries, and the sibling to use instead for procedure-level costs. Nothing material is left ambiguous.
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?
The single `lang` parameter is fully documented in the schema, so the description doesn't need to restate it. It does add value by including example Spanish queries ('¿cuánto gasta al año un estadounidense en el dentista?'), which signals that the Spanish response mode is a real supported path rather than a technicality.
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?
States a specific verb+resource+scope: national US dental spending, out-of-pocket share, and visit prevalence from MEPS for 2023-2024. It explicitly distances itself from dental_cost_by_state ('procedure costs go to dental_cost_by_state') and from person-level vs procedure-level data, so an agent can separate it from siblings without opening the schema.
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?
Gives an explicit when-to-use clause, four concrete example phrasings (including Spanish), and a 'Do not use for' list covering diagnosis, insurer plan prices, non-US countries and dentist recommendations. It also names the correct alternative for procedure costs.
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.
benchmark_treatment_plan1 field changedInput schema / properties / city / descriptionPrevious 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."dental_cost_by_citybenchmark_treatment_plan1 field changedInput schema / properties / cityAdded 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"
+}dental_cost_by_state1 field changedInput schema / properties / quoted_usdAdded value: +{
+ "description": "Optional amount quoted to the user for this procedure, in US dollars, in the unit of the procedure label (per tooth, per arch, full set): returns its position in the state band.",
+ "maximum": 500000,
+ "minimum": 0,
+ "type": "number"
+}benchmark_treatment_plancanada_dental_cost_by_provincecdcp_coverage_checkcompare_statesdental_cost_by_citydental_cost_by_statedental_national_averagedental_program_changesinsurance_out_of_pocketlow_cost_dental_optionsmedicaid_adult_dental_rulesmedicaid_paid_by_codemedicare_dental_checkus_dental_spending_statsRead-only MCP: US dental intel, all-category Medicaid fee schedules, dentist lookup. Free tier.
London dental prices from practices' own sites, next to NHS charges and NHS places. Dated, sourced.
Public Root Data dental analytics directory for DSOs, dental practices, blog, and FAQ tools.
US healthcare public data, one endpoint: prices, Medicare, MA benefits, Stars, Medicaid, providers.
Add one secure layer between your agents and this server.
