This server provides tools to access live US healthcare cost data, provider pricing, insurance coverage rules, and medical bill analysis, grounded in real hospital transparency and CMS data.
Demo & Connectivity Check — Run demo_estimate (no API key needed) to verify connectivity using a static sample estimate.
Procedure Resolution — Use resolve_procedure to fuzzy-match free-text procedure names (e.g., "knee mri") to canonical slugs with confidence scores.
Procedure Cost Estimation — Use estimate_procedure_cost to get allowed-amount ranges (low/median/high), billing components, risk flags, and optional patient out-of-pocket based on deductible, coinsurance, and OOP max.
Insurance Liability Calculation — Use calculate_liability for exact insurance math given an allowed amount and plan details, returning patient responsibility and plan payment breakdown.
Full Bundled Estimate — Use full_estimate to get procedure ontology + cost + providers + patient liability in a single API call.
Provider Search — Use find_providers to locate providers for a procedure in a state, with real negotiated prices (observed) or estimates, and optional city-level clustering.
Provider Lookup — Use get_provider to retrieve a provider's public profile by 10-digit NPI number.
Procedure Catalog — Use list_procedures to browse 30 procedures with slugs, display names, categories, and CPT codes.
Procedure Details — Use get_procedure_details for structured knowledge about a procedure: billing rules (facts), expected separate bills (bundle), or full ontology.
Insurance Coverage Rules — Use get_coverage to retrieve coverage rules for a procedure/carrier combination by aspect: summary, prior-auth, cost-sharing, frequency, or billing triggers.
Carrier Listing — Use list_carriers to see all supported insurance carrier keys (aetna, cigna, bcbs, medicare, etc.).
Medical Bill Analysis (Pro) — Use analyze_bill to detect anomalies in bill line items (duplicate charges, unbundling, quantity errors), returning a risk score, flags, and a consumer-language summary — stateless, no patient identity required.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@costkits-mcp Colonoscopy cost estimate in CT with $500 deductible and 20% coinsurance."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give Claude, ChatGPT, Cursor, and other MCP clients access to live US healthcare cost data.
CostKits provides procedure cost estimates, patient out-of-pocket calculations, provider pricing, insurance coverage rules, and medical bill analysis using hospital-transparency and CMS data rather than model memory.
Ask healthcare cost questions in natural language. CostKits supplies the structured data and calculations.
A thin Model Context Protocol server for the CostKits API.
Ask questions such as:
"What would a colonoscopy cost in Connecticut?"
"How much would I owe if I have $500 left on my deductible and 20% coinsurance?"
"Compare MRI prices from providers near Dallas."
"Does this procedure commonly require prior authorization?"
"Do these medical bill line items show possible duplicate or unbundled charges?"
"Resolve 'knee scan' to the correct procedure and estimate the cost."
The MCP server selects the appropriate CostKits API tools and returns structured healthcare cost data the model can explain to the user.
User question
↓
MCP client
↓
CostKits MCP tool
↓
CostKits healthcare cost API
↓
Structured estimate, provider pricing, coverage rule, or bill-analysis resultRelated MCP server: Nonpayment Health MCP Server
Create a key at costkits.com/api-keys.
You can test the installation without a key using the demo_estimate tool.
Add this to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"costkits": {
"command": "npx",
"args": ["-y", "@costkits/costkits-mcp"],
"env": {
"COSTKITS_API_KEY": "ck_your_key_here"
}
}
}
}Restart Claude Desktop so it reloads the MCP configuration.
What would a colonoscopy cost me in Connecticut if I have $500 left on my deductible and 20% coinsurance?
The server uses MCP stdio transport and can be used with compatible MCP clients. A tested configuration example is provided for Claude Desktop in examples/claude-desktop-config.json.
Tool | Purpose | Plan |
| Return a sample estimate and verify connectivity | None |
| Convert free text into a supported procedure | Builder |
| Estimate procedure cost by geography | Builder |
| Calculate patient responsibility from benefit inputs | Builder |
| Combine procedure, cost, provider, and liability data | Builder |
Tool | Purpose | Plan |
| Find providers with observed negotiated prices | Builder |
| Retrieve a provider profile by NPI | Builder |
Tool | Purpose | Plan |
| List supported procedures and CPT codes | Builder |
| Retrieve billing bundles and procedure facts | Builder |
| Retrieve prior auth, cost-sharing, frequency, and trigger rules | Builder (triggers: Pro) |
| List supported carrier identifiers | Free |
Tool | Purpose | Plan |
| Flag possible duplicate, unbundled, or suspicious bill items | Pro |
Plans and pricing: costkits-api → plans-and-pricing.
Self-correcting errors — API errors include an agent_hint that tells the model what to call next. A typo'd procedure name becomes a resolve-and-retry, not a dead end.
Transparent estimates — responses include estimate ranges (p25/p50/p75), data sources, data vintage, and model version.
Structured procedure resolution — agents can translate user language into supported procedure identifiers before estimating costs.
Minimal sensitive data — bill analysis requires codes and amounts, not names, member IDs, or dates of birth.
Deterministic insurance math — deductible, coinsurance, copay, and out-of-pocket calculations are performed by the API rather than improvised by the model.
CostKits tools do not require patient names, member IDs, dates of birth, or medical-record identifiers.
For bill analysis, send only the billing codes, descriptions, and amounts needed for analysis. Do not send protected health information.
Env var | Required | Default | Purpose |
| For all tools except | — | Your |
| No |
| Override for testing |
Requirements:
Node.js 18 or later
npm
A CostKits API key for non-demo tools
git clone https://github.com/costkits/costkits-mcp
cd costkits-mcp
npm install
npm run smoke # spawns the server and calls demo_estimate over real MCP stdioRun locally:
COSTKITS_API_KEY=ck_your_key_here npm startPackage: @costkits/costkits-mcp
Category: Healthcare / Finance / Data
Transport: stdio
Authentication: CostKits API key
Public demo tool: demo_estimate
Source: github.com/costkits/costkits-mcp
CostKits API docs & examples · costkits.com · Interactive demo · Get an API key
CostKits is a healthcare cost-transparency platform built by John Caruso, FSA, MAAA, a healthcare actuary with more than 20 years of experience in insurance pricing, medical billing systems, and healthcare cost analytics.
This MCP server exposes the CostKits API as tools for AI assistants and agents.
Methodology · API documentation
Detect anomalies in medical bill line items (Pro plan): duplicate charges, unbundling, quantity errors, screening-to-diagnostic reclassification. Returns a risk score, flags, and a consumer-language summary. Stateless — send only codes and amounts, never patient identity fields.
| Name | Required | Description | Default |
|---|---|---|---|
| line_items | Yes | Up to 100 line items from the bill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it is stateless, returns risk score/flags/summary, and explicitly prohibits patient identity fields. No contradictions.
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 long, front-loading the core purpose and key details. Every sentence adds value with no redundancy.
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 a single parameter and no output schema, the description explains what anomalies are detected and what is returned. It is fully sufficient for an agent to invoke 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?
The input schema provides 100% coverage for the single parameter (line_items). The description adds a usage constraint but does not enhance parameter semantics beyond the schema's property descriptions.
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 tool detects anomalies in medical bill line items, listing specific types (duplicate charges, unbundling, etc.). It distinguishes from siblings like estimate_procedure_cost or calculate_liability by focusing on anomaly detection.
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 advises sending only codes and amounts, never patient identity fields, and notes the 'Pro plan' requirement. While not explicitly stating when not to use, the context signals and sibling names imply appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stateless insurance math: given an allowed amount and a plan snapshot (deductible, coinsurance, OOP max), returns exact patient responsibility, plan payment, and the breakdown, plus p25/p75 scenarios. Use when you already have a dollar amount (e.g. from an EOB or a prior estimate).
| Name | Required | Description | Default |
|---|---|---|---|
| copay | No | Flat copay, if the plan uses one | |
| oop_max | Yes | Annual out-of-pocket maximum in dollars | |
| oop_met | No | Out-of-pocket already met this year | |
| deductible | Yes | Annual deductible in dollars | |
| coinsurance | Yes | Coinsurance as a fraction, e.g. 0.2 for 20% | |
| allowed_amount | Yes | Negotiated/allowed amount in dollars | |
| deductible_met | No | Deductible already met this year | |
| preventive_exception | No | True if ACA preventive $0 cost-sharing applies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the tool's stateless nature and pure calculation behavior. It lists inputs and outputs comprehensively, including 'p25/p75 scenarios'. No contradictory annotations exist.
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 a single, dense sentence that efficiently conveys purpose, inputs, outputs, and use case. It is front-loaded with 'Stateless insurance math', immediately informing the agent of the tool's nature. No filler 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?
For a tool with 8 parameters and no output schema, the description adequately explains the core function and highlights key output types. It implicitly differentiates from siblings via the 'already have a dollar amount' clause. While the output structure is not detailed, the description covers essential aspects.
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 baseline is 3. The description adds context by mapping inputs to real-world concepts ('plan snapshot (deductible, coinsurance, OOP max)'), but does not elaborate on optional parameters like 'copay' or 'preventive_exception'. The mention of 'p25/p75 scenarios' hints at additional computation not in schema, adding slight value.
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 tool performs 'stateless insurance math' to compute liability details, with specific inputs (allowed amount, plan snapshot) and outputs (patient responsibility, plan payment, breakdown, p25/p75 scenarios). It distinguishes from sibling tools like 'estimate_procedure_cost' by specifying use case: when you already have a dollar amount.
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 includes explicit guidance: 'Use when you already have a dollar amount (e.g., from an EOB or a prior estimate).' This clarifies when to use this tool versus other estimation tools. However, it does not explicitly state when not to use it or provide alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Static sample cost estimate (colonoscopy in Connecticut) from the CostKits API. Works with NO API key — use it to verify connectivity and see the response shape.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It mentions it's a static sample (fixed data) and requires no authentication, setting expectations for behavior. It could add more details about the response but is sufficient for the tool's simplicity.
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?
Two sentences with no wasted words, front-loaded with purpose and key usage details.
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 it's a demo with no output schema and 0 parameters, the description covers the essential purpose and use case sufficiently. It could mention the limitation of being a single sample, but it's complete enough.
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?
Input schema has 0 parameters, so schema coverage is 100%. Baseline is 4; description adds context that it's a fixed sample, which is adequate.
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 tool provides a static sample cost estimate for a colonoscopy in Connecticut from the CostKits API, immediately distinguishing it from other tools by being a demo that requires no API key.
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 states it works with no API key and is for verifying connectivity and seeing response shape, implying it's for testing/setup. However, it does not explicitly say when not to use it (e.g., for real cost estimates) or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate what a medical procedure costs in a US state: allowed-amount range (low/median/high), billing components, risk flags, and — if insurance details are given — the patient's expected out-of-pocket. Use resolve_procedure first if the user gave a free-text procedure name. Always present ranges, not single numbers, and cite the returned data_vintage.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | 2-letter US state code, e.g. 'CT' | |
| zip_code | No | Optional 5-digit ZIP for locality | |
| plan_type | No | Insurance plan type (default commercial) | |
| procedure | Yes | Procedure slug or plain name, e.g. 'colonoscopy' or 'mri-knee' | |
| oop_remaining | No | Dollars left to the member's out-of-pocket max | |
| coinsurance_pct | No | Coinsurance percentage, e.g. 20 for 20% | |
| deductible_remaining | No | Dollars left on the member's deductible |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that outputs include ranges (not single numbers), conditional out-of-pocket calculation based on insurance details, and the need to resolve free-text procedures. It does not mention authorization requirements or side effects, but the behavioral description is sufficiently detailed for an estimation tool.
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 long, with the first sentence immediately stating the primary purpose and outputs. There is no redundancy or filler; every sentence is purposeful.
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 complexity (7 params, no output schema), the description covers key aspects: inputs, conditional logic, output format (ranges, data_vintage), and a cross-reference to resolve_procedure. It could be more explicit about return value structure, but it is complete enough for selection.
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 adds value by explaining that insurance parameters (oop_remaining, coinsurance_pct, deductible_remaining) trigger out-of-pocket estimation and clarifying acceptable inputs for 'procedure' (slug or plain name).
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 uses specific verbs ('Estimate') and identifies the resource ('medical procedure costs in a US state'). It enumerates distinct outputs (allowed-amount range, billing components, risk flags, out-of-pocket) and hints at the prerequisite use of resolve_procedure, distinguishing it from 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?
The description explicitly advises using resolve_procedure first for free-text procedure names, and instructs to present ranges and cite data_vintage. However, it does not provide guidance on when to choose this tool over other siblings like full_estimate or demo_estimate, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find healthcare providers for a procedure in a US state. Each provider has pricing_status: 'observed' (real negotiated rate from hospital transparency data — prefer these), 'estimated', or 'none'. Set cluster=true for city-level groups with lat/lng.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 25) | |
| state | Yes | 2-letter US state code | |
| cluster | No | Group by city with lat/lng (default false) | |
| procedure | Yes | Procedure slug or plain name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pricing_data provenance (hospital transparency data) and behavior of cluster parameter, but does not explicitly state read-only nature or any side effects.
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?
Two sentences, no waste. Purpose is front-loaded, and every sentence adds value. Well-structured and efficient.
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 4-parameter tool with no output schema or annotations, the description covers purpose, parameter hints, and data quality. Could mention pagination or response structure, but it's sufficient.
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%, but description adds meaning: explains that cluster=true groups by city with lat/lng, procedure accepts slug or plain name, and limit defaults to 25. It also clarifies pricing_status field values.
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 'Find healthcare providers for a procedure in a US state', specifying the verb (find), resource (providers), and scope. It distinguishes from siblings like analyze_bill or estimate_procedure_cost by focusing on provider search with pricing status.
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 explains when to use cluster mode and notes preference for 'observed' pricing status, but does not explicitly state when not to use this tool or compare it to alternatives like get_provider or list_providers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One call chaining procedure ontology + cost + providers + patient liability. Cheapest way (one metered request) to get the complete picture. Use fields to request a subset; liability requires the plan_* inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | 2-letter US state code | |
| fields | No | Which services to include (default: all) | |
| procedure | Yes | Procedure slug or plain name | |
| plan_oop_max | No | ||
| plan_oop_met | No | ||
| plan_deductible | No | ||
| plan_coinsurance | No | Fraction, e.g. 0.2 | |
| plan_deductible_met | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool chains multiple services in one metered request and is the cheapest way. However, it does not mention any destructive behavior, authorization needs, rate limits, or side effects. The behavioral insight is moderate.
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. Every word is earned, no fluff. Jargon like 'procedure ontology' is concise and targeted to the domain.
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 8 parameters, no output schema, and medium complexity, the description covers the main concepts but lacks details on return format, what 'procedure ontology' means, and the distinction between plan_* inputs. It is adequate but has gaps.
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 50%, and the description adds meaning by stating that liability requires plan_* inputs, implying their purpose. It does not detail each parameter individually. This adds some value beyond the schema but does not fully compensate for the uncovered parameters.
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 tool's purpose: to get a complete estimate including procedure ontology, cost, providers, and liability in one call. The phrase 'one call chaining' and 'cheapest way' distinguishes it from similar tools that might handle only one aspect.
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 guidance on using the 'fields' parameter to request subsets and mentions that liability requires plan_* inputs. It does not explicitly state when to use alternatives like estimate_procedure_cost or find_providers, but the context implies when to consider this tool for a complete picture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insurance coverage rules for a procedure/carrier combination. aspect: 'summary' (status + plain English), 'prior-auth', 'cost-sharing' (deductible/coinsurance/ACA preventive), 'frequency' (how often covered, age rules), or 'triggers' (Pro plan: billing events that flip a $0 preventive claim to diagnostic — the highest-signal aspect).
| Name | Required | Description | Default |
|---|---|---|---|
| aspect | No | Default 'summary' | |
| carrier | Yes | Carrier key, e.g. 'aetna', 'cigna', 'bcbs', 'medicare' — see list_carriers | |
| plan_type | No | ||
| procedure | Yes | Procedure slug, e.g. 'colonoscopy' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds behavioral context by describing each aspect (e.g., 'triggers' for Pro plan billing events). However, it does not disclose other behaviors like authentication, rate limits, or error handling.
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 concise, consisting of one sentence plus a parenthetical enumeration. However, the enumeration is a bit dense; a list format might improve readability. It efficiently uses space without redundancy.
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 absence of an output schema, the description does not explain return values or structure, which is a gap. It adequately covers the tool's purpose and parameters but lacks completeness in explaining what the agent can expect as a result.
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 schema description coverage is 75%, but the description adds significant value for the 'aspect' parameter by explaining each enum value. For 'procedure' and 'carrier', the description reiterates schema info without much additional detail. Overall, it enriches 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?
The description clearly states the tool's purpose: retrieving insurance coverage rules for a specific procedure/carrier combination. It lists the available aspects, which distinguishes it from sibling tools like 'estimate_procedure_cost' (cost) or 'find_providers' (providers).
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 explains what aspects are available and hints at when to use each, but it does not explicitly contrast with alternatives or specify when not to use this tool. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured knowledge about one procedure. aspect='facts' returns LLM-ready billing rules and cost drivers (best for grounding an answer); 'bundle' explains which separate bills to expect (facility, physician, anesthesia...); 'full' returns the complete ontology.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Canonical procedure slug, e.g. 'colonoscopy' | |
| aspect | No | Default 'facts' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It describes the tool as a read-only knowledge retrieval operation, but lacks explicit statements about safety (e.g., no side effects, auth requirements) or handling of invalid slugs. The behavior is adequately conveyed for a straightforward retrieval tool.
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 a single, well-structured sentence that front-loads the core purpose ('structured knowledge about one procedure') and then lists the three aspects using semicolons. Every part is informative with 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 has no output schema and is a retrieval tool, the description adequately covers its functionality. It explains the three aspects and their intent. However, it could hint at the return format (e.g., 'structured knowledge' is vague) or mention that results are LLM-ready. Overall, it is fairly complete for its complexity.
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?
Both parameters are fully described in the schema (100% coverage). The description adds value by clarifying the 'aspect' enum values with specific use cases (LLM-ready billing rules, bundle explanation, full ontology) and provides an example for 'slug' ('colonoscopy').
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 tool provides 'structured knowledge about one procedure' and explains three specific aspects ('facts', 'bundle', 'full'). This distinguishes it clearly from siblings like 'estimate_procedure_cost' or 'analyze_bill' which focus on financial calculations.
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 explicitly describes when to use each aspect: 'facts' for grounding answers, 'bundle' for explaining expected bills, 'full' for complete ontology. It implicitly guides against using this tool for cost estimation or billing analysis, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public profile for a single provider by 10-digit NPI number: name, specialty, address, entity type.
| Name | Required | Description | Default |
|---|---|---|---|
| npi | Yes | 10-digit NPI number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read-only 'Public profile' operation and lists returned fields. However, it does not mention permissions, limitations, or potential side effects, which is acceptable for a simple lookup but could be more transparent.
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 a single sentence that is front-loaded with the tool's purpose and key details. It is concise with 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?
For a simple single-parameter lookup, the description adequately explains what the tool does and the data returned. However, without an output schema, more detail on the return format could enhance completeness.
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% with the parameter 'npi' described as '10-digit NPI number'. The description adds no additional meaning beyond the schema, so a baseline score of 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 tool retrieves a public profile for a single provider using a 10-digit NPI number, specifying the returned fields (name, specialty, address, entity type). This distinguishes it from sibling tool 'find_providers' which likely searches for multiple providers.
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 implies usage when you have an NPI and need provider details. It does not explicitly mention when not to use it (e.g., for searching without an NPI), but the context from sibling tools provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All insurance carrier keys supported by the coverage tools (aetna, cigna, bcbs, medicare, ...). Works on the Free plan — also a good API-key sanity check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behavioral traits. It mentions the tool works on the Free plan and serves as a sanity check, implying successful responses confirm valid API keys. However, it does not describe output format or potential errors.
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?
Two sentences, no wasted words. Immediately conveys the purpose and a key use case. Front-loaded and efficient.
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 parameters and no output schema, the description is mostly complete. It explains what the tool returns and gives a usage hint. Could specify the return type (array of strings) but not required for a simple list.
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?
No parameters. With zero parameters, the baseline is 4. The description adds no param-specific info, which is fine since none exist.
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 it lists all insurance carrier keys supported by coverage tools, with examples. It distinguishes itself from sibling tools that perform calculations or queries on procedures and providers.
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?
States it works on the Free plan and is a good API-key sanity check. This provides clear context for when to use it, though it does not explicitly exclude alternatives (none exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full CostKits catalog: 30 procedures with slugs, display names, categories, and CPT codes (paginated).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | next_cursor from a previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions pagination, which is a behavioral trait, but does not disclose read-only nature or any side effects. For a list tool, this is minimally adequate.
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?
One sentence, front-loaded with the most important information, 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?
For a simple list tool with 2 parameters and no output schema, the description provides enough context about what is returned (specific fields) and pagination behavior. Minor missing details like ordering are acceptable.
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 50% (only 'cursor' has a description). The description mentions 'paginated' which implies cursor/limit usage, but does not explain the 'limit' parameter or acceptable values. It adds some context but does not fully compensate for the schema 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?
The description clearly states the verb 'list' (implied by 'catalog'), the resource '30 procedures', and the specific returned fields ('slugs, display names, categories, and CPT codes'). It distinguishes from siblings like 'get_procedure_details' which likely returns more detail.
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 implies this tool is for a general catalog listing, but it does not explicitly state when to use it versus alternatives like 'get_procedure_details' or 'resolve_procedure'. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-match a free-text procedure name ('knee mri', 'gallbladder removal') to a canonical slug with confidence scores. Call this BEFORE estimate tools whenever the user's wording might not be an exact slug.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text procedure name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the core matching behavior and output (slug with confidence scores). However, it does not disclose whether the tool is read-only or has side effects, which is acceptable for a lookup but could be improved.
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?
Two sentences: first defines purpose, second gives usage guidance. No wasted words, front-loaded with key information.
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 return value (slug and confidence scores). It provides workflow context with sibling tools. Could mention prerequisites or side effects but overall complete for a resolver.
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% with one parameter 'query' described as 'Free-text procedure name'. The description adds minimal extra meaning beyond schema, consistent with high-coverage baseline.
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 tool fuzzy-matches a free-text procedure name to a canonical slug with confidence scores. It uses specific verbs and resources, and distinguishes from siblings like list_procedures and estimate_procedure_cost.
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 explicitly says 'Call this BEFORE estimate tools whenever the user's wording might not be an exact slug.' This gives clear context and when to use, though it does not explicitly name alternatives.
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. Dates show when Glama detected each change.
v1.0.0analyze_billcalculate_liabilitydemo_estimateestimate_procedure_costfind_providersfull_estimateget_coverageget_procedure_detailsget_providerlist_carrierslist_proceduresresolve_procedureEach tool has a clearly distinct purpose: analyzing bills, calculating insurance liability, estimating costs, finding providers, obtaining coverage details, etc. There is minimal overlap, and composite tools like full_estimate are clearly defined as aggregations of other functionalities.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_bill, calculate_liability, list_procedures). Even demo_estimate and full_estimate fit the pattern, using descriptive verbs. No mixing of conventions.
With 12 tools, the server is well-scoped for medical cost estimation. The number is neither too few nor excessive; each tool serves a necessary function in the workflow, from procedure resolution to provider search and liability calculation.
The tool surface covers the full lifecycle of cost estimation: procedure lookup, fuzzy matching, cost estimation, provider discovery, insurance coverage, liability calculation, bill analysis, and a composite endpoint. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Search source-labeled hospital prices, CPT codes, providers, and healthcare cost estimates.
CMS quality ratings, payer-negotiated prices, and clinician data for 41K+ US healthcare facilities.
Pay-per-call US healthcare data: hospital financials, prices, quality, exclusions, wages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/costkits/costkits-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
