coverage-rights
Server Details
Insurer denial rates, appeal outcomes by treatment and condition, and appeal rights lookups.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 7 of 8 tools scored.
Tools are mostly distinct, targeting specific aspects like appeal rights, condition outcomes, and insurer metrics. Some potential confusion between get_condition_outcomes and get_treatment_outcomes, but descriptions clarify the difference.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_appeal_rights, list_insurers). No mixing of styles or ambiguous names.
8 tools is well-scoped for the domain of insurance denial and appeal information. Each tool serves a clear purpose without redundancy.
Covers key operations: searching, retrieving appeal rights, outcomes, insurer metrics, and rankings. Minor gaps like absence of a tool for specific plan details or administrative processes, but overall comprehensive for the intended domain.
Available Tools
8 toolsget_appeal_rightsARead-onlyIdempotentInspect
Appeal rights, deadlines, escalation path, and matching outcome statistics for a denial situation. Citations come from a verified corpus (CFR/statute references included).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter state code, e.g. 'ca' | |
| program | Yes | Plan type | |
| insurer_slug | No | Insurer slug for insurer-specific stats | |
| denial_reason | Yes | Denial reason category |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by specifying that citations come from a verified corpus with CFR/statute references. This informs the agent about data reliability beyond what 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?
The description is two sentences, front-loading the core output (appeal rights, deadlines, etc.) and adding source credibility in the second. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately lists return elements (rights, deadlines, escalation path, statistics). It lacks detail on output structure or format, but given the simple parameter set, it is reasonably complete.
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 clear parameter descriptions. The tool description does not add new semantic meaning to parameters beyond stating the tool is for a 'denial situation,' which is already evident from the denial_reason parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns appeal rights, deadlines, escalation path, and matching outcome statistics for a denial situation. It distinguishes itself from siblings like get_condition_outcomes and get_insurer_metrics by focusing specifically on appeal-related information.
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 use for 'a denial situation' but does not explicitly say when to use this tool versus alternatives like search_outcomes or get_treatment_outcomes. No exclusion criteria or prerequisites are mentioned, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_condition_outcomesARead-onlyIdempotentInspect
External-review outcomes for a medical condition: how often insurance denials involving this condition were overturned, plus the most-fought treatments for it.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Condition slug, e.g. 'obesity', 'autism', 'hepatitis-c' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context about returning overturn rates and most-fought treatments, which is valuable beyond the structured annotations.
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?
Single sentence, 17 words, front-loaded with the core purpose. No extraneous 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 the tool's simplicity (one parameter, clear annotations, no nested objects), the description is largely sufficient. However, without an output schema, slightly more detail on the return format would improve 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 coverage is 100% with a clear description for the slug parameter. The tool description does not add new meaning beyond the schema; baseline 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 specifies the verb 'get' and the resource 'external-review outcomes for a medical condition', and clearly distinguishes from sibling tools like get_treatment_outcomes by focusing on condition-level denial overturn rates and most-fought treatments.
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?
No guidance on when to use this tool versus alternatives (e.g., get_treatment_outcomes, search_outcomes). The description only states what it does without context on appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_insurer_metricsARead-onlyIdempotentInspect
Get an insurer's verified CY2025 prior-authorization metrics (denial rate, appeal overturn rate, decision times) from its own CMS-0057-F disclosure, plus contract/plan-level rows where collected. Includes source URLs and scope notes.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Insurer slug from list_insurers, e.g. 'unitedhealthcare' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds rich behavioral context: the data is verified CY2025 from a specific disclosure, includes contract/plan-level detail, and provides source URLs and scope notes. This goes beyond the annotations and clarifies what the tool returns and what source it uses.
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-loading the main purpose and key specifics. Every word adds value: the verb, the resource, the year, the metrics, the source, and what else is included. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, full schema coverage, and safety annotations, the description provides sufficient context: data source, time period, metrics, additional rows, and what is included. The sibling tools suggest a family of outcome-related tools, and this description precisely scopes its domain. No output schema exists, but the description conveys the return content well.
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 parameter 'slug' has a fully descriptive schema comment ('Insurer slug from list_insurers, e.g. 'unitedhealthcare''). The tool description does not add additional parameter-level detail, but schema coverage is 100%, so baseline 3 is appropriate. The description implies the slug identifies the insurer, which is already clear from 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 description clearly identifies the verb 'Get', the specific resource (insurer's verified CY2025 prior-authorization metrics), and the data source (CMS-0057-F disclosure). It also mentions additional data types (contract/plan-level rows) and included elements (source URLs, scope notes). This level of specificity distinguishes it from sibling tools like get_appeal_rights or get_condition_outcomes.
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 context (when you need insurer denial metrics from a regulatory disclosure), but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusion criteria or prerequisites. The guidance is implied through the resource description but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_state_external_reviewARead-onlyIdempotentInspect
How a state's external review process works: filing deadline, regulator contact, and key facts. Covers 10 launch states.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. 'ca', 'ny', 'fl' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds limited behavioral context beyond stating it covers 10 states. It does not disclose any additional traits beyond what 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?
The description is a single sentence that front-loads the purpose and includes essential scope. No extraneous information, every word earns its place.
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 read-only tool with one parameter and annotations, the description sufficiently covers what the tool returns (filing deadline, regulator contact, key facts) and its scope. It does not describe output format, but that is acceptable given the simplicity and lack of output 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?
The input schema already fully describes the single 'state' parameter with examples. The tool description does not add any further meaning or constraints beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about a state's external review process, including specific details like filing deadline and regulator contact. It also specifies coverage scope ('10 launch states'), distinguishing it from sibling tools that cover other aspects like appeal rights or outcomes.
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 the tool is for retrieving external review process info for a state, but does not explicitly state when to use this tool versus alternatives like get_appeal_rights or list_insurers. No mention of when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_treatment_outcomesARead-onlyIdempotentInspect
External-review outcomes for a treatment: how often insurer denials of this treatment/drug/procedure were overturned by independent reviewers (42,749 published CA IMR decisions, 2001–2026). Accepts a category slug (e.g. 'pharmacy') or specific treatment slug (e.g. 'zepbound', 'speech-therapy').
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Treatment slug, e.g. 'zepbound', 'pharmacy', 'speech-therapy'. Use search_outcomes to find slugs. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: data source (CA IMR decisions), scope (42,749 decisions over 2001-2026), and input types. 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?
Two concise sentences, front-loaded with key information. No unnecessary words. Efficiently communicates purpose, input, and data source.
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 does not specify the return format or fields. While it states 'how often denials were overturned,' an agent might benefit from knowing if returns include counts, rates, or metadata. Minor completeness gap.
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?
Only one parameter (slug) with 100% schema coverage. The description adds meaning beyond the schema by explaining slug can be a category or specific treatment, and provides examples. Useful context for the agent.
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 returns external-review outcomes for a treatment, specifically how often insurer denials were overturned. It specifies the dataset size, time range, and distinguishes from sibling tools by focusing on outcomes.
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 acceptable inputs (category or specific slug) and references search_outcomes to find slugs. It implies when to use this tool but does not explicitly list when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_insurersARead-onlyIdempotentInspect
List tracked U.S. health insurers with whether verified CMS-0057-F prior-authorization metrics are available for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, non-destructive nature is clear. The description adds functional detail: listing insurers and whether metrics are available. No contradictions, and the description adds value beyond annotations.
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?
A single, front-loaded sentence that conveys the purpose and key output without any unnecessary words. Every part of the description earns its place.
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 sufficiently explains what the tool returns (list of insurers with a metric availability flag). It is complete for this simple tool type.
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 has zero parameters, so schema_description_coverage is 100%. The description does not need to add parameter information. Baseline 4 is appropriate for a no-parameter tool.
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 specifies a clear verb ('List'), a specific resource ('tracked U.S. health insurers'), and the key information included (availability of CMS-0057-F metrics). This distinguishes it from sibling tools that focus on specific insurers or metrics.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is a starting point for listing insurers, but it does not mention exclusions or context for other tools like get_insurer_metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_denial_ratesARead-onlyIdempotentInspect
Ranked table of insurer prior-authorization denial rates (CY2025) from each insurer's own public CMS-0057-F disclosure, with appeal overturn rates and source links. Scope varies by insurer — read the notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds value by noting that scope varies by insurer and advising to read notes. This goes beyond the structured annotations to warn about potential inconsistency.
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. The first sentence delivers the core purpose and components, the second adds an important caveat. Perfectly front-loaded and 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?
Without an output schema, the description covers what the table contains (denial rates, appeal overturn rates, source links) and notes scope variation. It does not specify column order or sorting, but for a simple read-only tool this is adequate.
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 has zero parameters, so the baseline is 4. No additional parameter information is needed, and the description does not attempt to add any, which 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 returns a ranked table of insurer prior-authorization denial rates from a specific source (CMS-0057-F), with appeal overturn rates and source links. This is a specific verb-resource combination that distinguishes it from sibling tools like get_insurer_metrics or get_appeal_rights.
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 the tool is for obtaining denial rates but does not explicitly state when to use it versus alternatives like get_insurer_metrics. There is no when-not or exclusion guidance, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_outcomesARead-onlyIdempotentInspect
Search treatments (categories + specific drugs/procedures) and conditions by name. Returns slugs for get_treatment_outcomes / get_condition_outcomes plus headline overturn rates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per type (default 10) | |
| query | Yes | Search text, e.g. 'wegovy', 'back pain', 'imaging' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns slugs and overturn rates, which is helpful but does not disclose additional behavioral traits like rate limits or pagination.
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, efficient and front-loaded. Every sentence adds value: the first explains the search scope, the second specifies return values.
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 simple input schema and annotations, the description sufficiently covers what the tool does and returns (slugs and overturn rates). No output schema exists, but the description fills that gap adequately.
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 100% description coverage for both parameters. The description does not add new parameter details beyond the schema, which already provides adequate meaning (e.g., limit default, query examples). 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?
Description clearly states the tool searches treatments and conditions by name, and explicitly mentions what it returns (slugs for downstream tools and headline overturn rates). This distinguishes it from sibling tools like get_treatment_outcomes or get_condition_outcomes.
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 needing to identify treatments/conditions for subsequent queries (get_treatment_outcomes / get_condition_outcomes), providing clear context. However, it does not explicitly state when NOT to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!