kolejki-nfz-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KOLEJKI_STATS | No | Set to 1 to enable anonymous counters exposed under /stats. | |
| KOLEJKI_CONTACT | No | Contact information for the server operator. | |
| KOLEJKI_CACHE_DIR | No | Directory used for caching NFZ API responses. | |
| KOLEJKI_PUBLIC_URL | No | Public URL of the deployed server. | |
| KOLEJKI_RATE_LIMIT | No | Rate limit for requests to the NFZ API. | |
| KOLEJKI_CACHE_HOURS | No | Cache duration in hours for NFZ API responses. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_careA | Where a specialist, diagnostic test or treatment paid by NFZ is available soonest near a place in Poland. Returns clinics and hospitals with NFZ's forecast waiting time, people in the queue, address, phone, distance, accessibility and whether children are seen. service: everyday words (okulista, kardiolog, rezonans, zaćma, rehabilitacja…) or an exact NFZ benefit name from find_benefits. place: town, address or 'lat,lon'. |
| find_benefitsA | Look up official NFZ benefit names (clinics, wards, tests, procedures) matching a word, e.g. 'rezonans' or 'okulist'. Use the exact name as find_care.benefit. |
| data_sourcesC | Where the data comes from and caveats. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
find_care and find_benefits both accept everyday service words like 'rezonans' or 'okulista', which could cause an agent to pick the wrong one on first pass. However, the descriptions make the intended two-step flow explicit (resolve name with find_benefits, then query with find_care.benefit), and data_sources is clearly separate.
find_care and find_benefits follow a clean verb_noun pattern, while data_sources is a noun phrase. The deviation is minor and the names remain readable and predictable.
Three tools is lean but well-matched to a narrow domain: one resolver, one search, one provenance/caveats tool. Nothing feels redundant, though data_sources borders on being documentation rather than an operational tool.
The core workflow — resolving an NFZ benefit name and finding the soonest available provider with wait times, distance and accessibility — is fully covered. Minor gaps exist, such as no tool for retrieving full details of a single clinic or browsing benefits by category/location without a search term.