Skip to main content
Glama

Medicare Coverage

by io.github.pipeworx-io
OverviewAdmin

Medicare Lcd Search

medicare_lcd_search
Read-onlyIdempotent

Search current final Medicare Local Coverage Determinations (LCDs), optionally restricted to a state. LCDs are contractor- and jurisdiction-specific and can differ across locations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults (1-100, default 25).
queryNoPolicy title/topic or LCD number. Omit to browse the most recently updated LCDs — that is the answer to "what changed recently".
stateNoOptional US state name or two-letter abbreviation. California, New York and Missouri span multiple MAC jurisdictions; those resolve to the whole-state jurisdiction and the response reports which one under state_resolved.
statusNoOptional CMS status filter.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
totalYes
sourceYes
returnedYes
documentsYes
interpretationYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Policy title/topic or LCD number."New value: +"Policy title/topic or LCD number. Omit to browse the most recently updated LCDs — that is the answer to \"what changed recently\"."
    • changedInput schema / required
      Previous value: -[
-  "query"
-]New value: +[]
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds useful context that LCDs are contractor- and jurisdiction-specific and can differ across locations, which helps the agent understand the variability of results. It does not contradict annotations, nor does it disclose additional behavioral traits like pagination or rate limits, so a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that lead with the action and resource, no redundant words. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a rich schema, annotations, and output schema. The description covers the core purpose and a key caveat about jurisdictional differences. While it doesn't mention the optional query omission for recent changes, that is handled in the schema, so the description is sufficiently complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 4 parameters with descriptions (100% coverage). The description mentions state restriction but adds no additional semantic detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this tool searches Medicare LCDs, optionally filtered by state, using a specific verb ('search') and resource ('current final Medicare Local Coverage Determinations'). It distinguishes from sibling tools like medicare_lcd_detail and medicare_local_coverage_variation by focusing on search of current final determinations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for what the tool does but does not explicitly say when to use it over alternatives. It implies usage as a general LCD search tool, but does not mention exclusions or point to sibling tools such as medicare_lcd_detail. A score of 3 reflects the implied but not explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Medicare Coverage toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources