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., "@Claims desk MCP Server What are the Medicare documentation requirements for CPT 99213?"
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.
Personal demo by Andrew Espira.
A claims reviewer MCP App: one tool returns structured prior-auth / attachment / filing guidance plus doc:// citation URIs (never document bytes). The App streams the live CMS LCD or claims-manual pages beside that answer.
Implements the current MCP Apps extension (io.modelcontextprotocol/ui).
Check | Where |
Tool bound to a UI |
|
UI resource |
|
Capability |
|
App-only tools |
|
Split | Tool JSON has citation URIs only; the App fetches bytes via app-only tools |
Related MCP server: mymedi-ai-mcp-server
Python 3.10+ (3.12 recommended). Needs network for live cms.gov fetches. PDF page preview uses pdftoppm (poppler).
python3.12 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e .
python scripts/serve_app.pyLeave Medicare / 27447, click Ask MCP tool.
Confirm First Coast Jurisdiction N + 12-month / 1 calendar year filing on the left, LCD L33618 on the right.
Try 70553 (claims-manual PDF), E0601 (no DMEPOS PA; CMNs discontinued), and UHC commercial outpatient MRI (UHC PA list, not a Medicare manual).
The local host resources/reads the ui:// HTML, loads it in an iframe, and proxies tools/call over postMessage. The view never POSTs /mcp.
python -m mcp_pdf_demo.serverPoint the client at that command. Optional Streamable HTTP: python -m mcp_pdf_demo.server --http → http://127.0.0.1:3001/mcp.
Optional enrichment (not required to review the Apps wiring):
export RCI_API_KEY=...
export RCI_API_URL=https://api-dev.rcintell.comAlways two parts: a tool that returns data, and a ui:// resource the host renders.
Python SDK Apps extension — Apps() + MCPServer(..., extensions=[apps]) so the server advertises io.modelcontextprotocol/ui.
Bind the result tool — @apps.tool(resource_uri="ui://claims-desk/app.html", meta={"ui/resourceUri": "..."}) on review_claim_requirements.
Serve the view — FunctionResource / add_html_resource at that URI with MIME text/html;profile=mcp-app. Bundle CSS + JS into one HTML file (app_html.py + app/view.js).
App-only helpers — same resource_uri, visibility=["app"], for chunked reads and PDF rasterization.
View talks to the host, not the server — ui/initialize then tools/call over window.parent.postMessage (app/view.js).
Host is the MCP client — fetch ui:// HTML, iframe it, handle ui/initialize, proxy tools/call / resources/read (app/host.js + scripts/serve_app.py). Production hosts (Claude, VS Code, ext-apps basic-host) do this step for you.
Policy URLs live in fixtures/catalog.json. Fetch/cache is src/mcp_pdf_demo/live.py.
Path | Role |
| MCP server: Apps tools, |
| Live CMS fetch + optional RCI |
| Bundles the view into one HTML document |
| MCP App view ( |
| Local Apps host |
| Runs that host on |
| CPT → CMS URL map |
MIT
List live CMS policy documents wired into this claims desk.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. "List" implies a non-mutating read operation, and "live" plus "wired into this claims desk" clarify that only active, desk-scoped documents are returned. However, it does not mention pagination, ordering, permission requirements, or what metadata is included.
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 sentence with no filler. The verb and key qualifiers ("live," "wired into this claims desk") are front-loaded, making the purpose immediately clear.
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 zero parameters and the presence of an output schema, the description does not need to explain return values or parameter details. It adequately states what the tool lists and at what scope, though it could be slightly stronger by naming the sibling tools it complements.
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 tool has zero parameters and an empty input schema, so there is nothing to document. The description adds context that the scope comes from the environment ("wired into this claims desk"), which is useful for understanding why no parameters are needed.
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 a specific verb, "List," and identifies the exact resource: "live CMS policy documents wired into this claims desk." This clearly differentiates the tool from siblings like read_document_bytes or preview_pdf_pages, which target different resources and operations.
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?
There is no explicit guidance on when to use this tool versus alternatives like review_claim_requirements or read_document_bytes. The phrase "wired into this claims desk" implies a scoped context, but no when-to-use or when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
App-only: rasterize the first pages of a cited policy PDF for the reviewer.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | ||
| pages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates read-only safety, and the description adds meaningful behavior beyond that: it rasterizes only the first pages rather than the whole document, and it is restricted to app-only contexts.
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, tightly written sentence that front-loads the access constraint and the core action. There is no wasted wording or unnecessary repetition.
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?
The tool is simple and has an output schema, so the description does not need to explain return values. However, it omits when to prefer this over read_document_bytes or list_policy_library, and it leaves the uri parameter underspecified, so it is adequate but not fully 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 description coverage is 0%, so the description carries the burden of explaining parameters, but it only hints that uri identifies a policy PDF and pages refers to the first pages. It does not specify uri format, page range, bounds, or the meaning of pages beyond an intuitive default.
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 ('rasterize') and resource ('cited policy PDF'), and narrows the operation to 'first pages'. This clearly distinguishes it from siblings like read_document_bytes (raw bytes) and list_policy_library (listing policies).
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 is given for when to use this tool versus alternatives. 'App-only' is an availability constraint, not a routing cue, and no sibling tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
App-only: stream a fetched policy document in base64 chunks (offset/length/hasMore). Used by the claims App to render source docs.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | ||
| length | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes it as a safe read. The description adds valuable behavioral context beyond annotations: app-only restriction, base64 chunking, and offset/length/hasMore streaming semantics. No contradiction with the annotation.
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 filler. The core streaming behavior is front-loaded, and the use-case context is delivered in the second sentence 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?
The output schema covers return values, and the readOnlyHint covers safety. The description covers the access restriction, use case, and streaming behavior. The main gap is the lack of explicit uri parameter semantics, but this is minor given the output schema and simple defaults.
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 0%, so the description must compensate. It only implies the roles of offset and length through chunking, and never explains the uri parameter. This is partial guidance, not sufficient for an agent to confidently use all three 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 uses a specific verb ('stream') and a concrete resource ('a fetched policy document'), and adds unique behavior details: base64 chunks, offset/length/hasMore. It clearly differentiates itself from siblings like preview_pdf_pages by noting its role in rendering source docs for the claims App.
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 the tool is App-only and used by the claims App to render source docs, giving clear context for when this tool is appropriate. However, it does not explicitly name alternative tools or 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.
Resolve claim documentation requirements for a payer + CPT. Fetches live cataloged policy sources (CMS or payer) and optionally enriches from an RCI knowledge API when RCI_API_KEY is set. Returns structured requirements plus document URIs — never PDF/HTML bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| cpt | Yes | ||
| payer | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool fetches live cataloged policy sources, may enrich from an RCI API conditionally on RCI_API_KEY, and returns structured data plus URIs rather than raw bytes. This gives the agent useful operational context beyond the simple input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly written, with the core purpose in the first sentence and important behavioral constraints following. Every phrase adds value, including the explicit 'never PDF/HTML bytes' boundary.
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 moderate complexity—live fetching, optional API enrichment, and structured output—the description covers the important operational aspects well. An output schema exists, so return-value details are handled elsewhere. Minor gaps include no guidance on payer/CPT formats or what happens when the RCI key is absent, but these are not critical for tool 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?
The schema has 0% description coverage, so the description must compensate. It does identify both parameters ('payer' and 'CPT') and their role in the operation, but it adds no additional semantics such as expected formats, examples, or constraints. The description merely restates the parameter names in context rather than enriching them.
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 ('Resolve') with a clear resource ('claim documentation requirements') and identifies the key inputs (payer + CPT). It also differentiates from sibling tools by stating it returns structured requirements and document URIs, never PDF/HTML bytes, making it easy to distinguish from read_document_bytes and preview_pdf_pages.
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 establishes the context for use: resolving claim requirements for a payer and CPT, and it implies this is the right tool when structured requirements rather than file bytes are needed. However, it does not explicitly compare itself to siblings or state when not to use it, leaving the routing largely to inference.
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.
v0.4.0list_policy_librarypreview_pdf_pagesread_document_bytesreview_claim_requirementsEach tool has a distinct primary purpose, and the names/descriptions are mostly clear. However, read_document_bytes and preview_pdf_pages both operate on cited policy documents for app rendering, and their raw-bytes vs. rasterized-preview distinction could cause minor selection confusion.
All tools follow a consistent verb_noun pattern: review_claim_requirements, read_document_bytes, preview_pdf_pages, and list_policy_library. No casing or style inconsistencies exist, and each name clearly suggests its action.
Four tools is well-scoped for a focused claims document and requirements server. Each tool covers a distinct step in the workflow: resolving requirements, reading document bytes, previewing PDFs, and listing the policy library.
The core workflow is covered end-to-end: review claim requirements, access document content, preview PDFs, and browse the policy library. Minor gaps remain, such as no general search/filter over the library and no non-app-facing document retrieval path.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic CMS NCCI/MUE claim scrubbing and CARC/RARC denial explanations, cited to source.
Validates ICD-10-CM against the real FY2026 catalog (NCHS/CDC) and CPT by structure/category.
Hosted MCP for denial, prior auth, reimbursement, workflow validation, batch scoring, and feedback.
ICD-10-CM / HCC medical coding tools with database-verified accuracy and denial-prevention rules.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/espirado/mcp-resources-apps-demo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
