Skip to main content
Glama
ContentWriterco

leki-mcp

by ContentWriterco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Podłącz w 30 sekund

Adres MCP: https://leki.compabase.com/mcp (Streamable HTTP, bez logowania).

  • Claude: Ustawienia → Connectors → Add custom connector → wklej adres.

  • ChatGPT: Settings → Connectors (tryb deweloperski) → dodaj serwer MCP.

  • Claude Code: claude mcp add --transport http leki https://leki.compabase.com/mcp

  • Lokalnie (stdio): npx -y leki-mcp, np. w Claude Desktop:

{ "mcpServers": { "leki": { "command": "npx", "args": ["-y", "leki-mcp"] } } }

Related MCP server: Israel Drugs MCP Server

Co potrafi

Narzędzie

Do czego

drug_price

Urzędowa cena w aptece, limit finansowania NFZ, poziom odpłatności (ryczałt, 30%, 50%, bezpłatny) i ile dopłacasz. Tańsze odpowiedniki – ta sama substancja, dawka i liczba sztuk – z różnicą w złotówkach, najtańsze opakowanie w przeliczeniu na tabletkę, wskazania objęte refundacją oraz czy lek jest bezpłatny dla 65+, dzieci do 18 lat i kobiet w ciąży. Szukaj po nazwie i dawce („Tulip 20 mg”), substancji – po polsku lub łacinie („atorwastatyna”, „atorvastatinum”), liczbie sztuk („30 szt”) albo kodzie EAN z opakowania. Gdy dany lek nie jest refundowany, podpowiada refundowane leki z tą samą substancją.

drug_info

Dane z Rejestru Produktów Leczniczych: substancja, dawka, postać, kod ATC, podmiot odpowiedzialny, na receptę czy bez (OTC), opakowania z kodami EAN, linki do ulotki i charakterystyki produktu.

data_sources

Źródła, data wykazu i zastrzeżenia.

Przykładowe pytania: „Ile zapłacę za Xarelto 20 mg i czy jest coś tańszego?”, „Najtańsza metformina 1000 mg na 60 tabletek”, „Czy Euthyrox 50 jest za darmo dla seniora?”, „Czy ibuprofen 400 jest bez recepty i gdzie jest ulotka?”.

Skąd dane

  • Wykaz leków refundowanych – obwieszczenie Ministra Zdrowia (załącznik .xlsx z gov.pl, zwykle co kwartał: 1 stycznia, kwietnia, lipca i października). Serwer sam znajduje najnowsze obwieszczenie i pobiera je codziennie. Używamy części A1–A3 (leki, środki spożywcze specjalnego przeznaczenia i wyroby medyczne w aptece) oraz list D1 (65+), D2 (do 18 lat) i E (kobiety w ciąży).

  • Rejestr Produktów Leczniczych (e-Zdrowie, rejestry.ezdrowie.gov.pl) – pełny eksport CSV, ok. 20 tys. leków stosowanych u ludzi.

  • Ceny leków refundowanych są urzędowe – takie same w każdej aptece. Cen leków nierefundowanych (w tym OTC) nie podajemy: są wolne i różnią się między aptekami.

  • Odpowiedniki to leki z tej samej grupy limitowej, z tą samą substancją, dawką i liczbą sztuk; farmaceuta ma obowiązek poinformować o tańszym odpowiedniku i wydać go na życzenie pacjenta, chyba że lekarz wpisał „NZ”.

  • To informacja, nie porada medyczna – zmianę leku skonsultuj z lekarzem lub farmaceutą.

Własny serwer

npx -y leki-mcp --http --port 3000      # MCP: http://localhost:3000/mcp
npx -y leki-mcp price "Tulip 20 mg 30 szt"
npx -y leki-mcp info "ibuprofen 400 mg"

Dane (~20 MB) pobierają się przy pierwszym użyciu do ~/.cache/leki-mcp i odświeżają raz na dobę. Zmienne: LEKI_DATA_DIR, LEKI_REFRESH_HOURS (24), LEKI_REFUND_XLSX_URL (bezpośredni link do załącznika), LEKI_RATE_LIMIT, LEKI_STATS=1 (anonimowe liczniki pod /stats), LEKI_CONTACT, LEKI_PUBLIC_URL.

Licencja

Kod: MIT. Dane: Ministerstwo Zdrowia (wykaz leków refundowanych), Urząd Rejestracji Produktów Leczniczych / Centrum e-Zdrowia (Rejestr Produktów Leczniczych) – dane przetworzone. Projekt niezależny, hostowany pro publico bono przez Compabase. Zobacz też rozkład-mcp (rozkłady jazdy) i ceny-nieruchomosci-mcp (ceny transakcyjne i działki).

English

leki-mcp gives AI assistants the official prices of refunded medicines in Poland: the pharmacy price, the NFZ refund limit, the refund level and what the patient pays, plus cheaper equivalents (same substance, strength and pack size), the cheapest pack per tablet and whether the drug is free for patients 65+, under 18 or pregnant. drug_info adds prescription status (Rx/OTC), registered packs and leaflet links from the Polish Medicinal Products Register. Public endpoint: https://leki.compabase.com/mcp (no key), or run locally with npx -y leki-mcp. Data: Minister of Health refund list (updated quarterly, fetched daily) and the Medicinal Products Register. Information only – not medical advice.

Available Tools

3 tools
data_sourcesData sourcesC
Read-only
Inspect

Where the data comes from, how current it is, caveats.

NameRequiredDescriptionDefault

No parameters

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral beyond that — no return format, no scope of sources, no indication of how 'current' is determined. It largely restates the title's concept.

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

Conciseness3/5

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

It is short and front-loaded with no filler, but it is a three-item fragment that omits the framing sentence that would make it interpretable. This is under-specification presented as concision rather than genuinely efficient prose.

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

Completeness3/5

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

With no output schema and no parameters, the description carries the burden of explaining what comes back, and it only gestures at that (sources, currency, caveats). For a simple read-only tool this is minimally adequate, but an agent still cannot predict the shape or fields of the response.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4; there are no parameter semantics to explain and the description cannot be faulted for omitting them.

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

Purpose3/5

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

The description names the resource it exposes (data provenance, freshness, caveats) but is a telegraphic noun phrase rather than a verb+resource statement, so it never says what the tool actually returns or does. It does loosely separate itself from the drug_info/drug_price siblings by topic, but only by implication.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no conditions, and no mention of the sibling tools. An agent has to guess whether this is for auditing, disclaimers, or metadata display, and when it should prefer drug_info or drug_price instead.

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

drug_infoMedicine registration data (Poland)C
Read-only
Inspect

Data from the Polish Medicinal Products Register: substance, strength, form, ATC, marketing authorisation holder, prescription status (OTC / Rp / Rpz / Rpw / Lz), registered packs with EAN and links to the patient leaflet and SmPC.

NameRequiredDescriptionDefault
maxNo
queryYesDrug name, substance or EAN/GTIN

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds only a list of returned fields and omits behavioral facts an agent would want: the hard cap of 15 results (max=15), matching/ranking behavior, and whether the query is exact or partial. It adds little beyond what the structured fields give.

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

Conciseness3/5

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

It is a single dense sentence with no wasted clauses, which is good, but it is a noun-phrase fragment that front-loads data fields instead of the action, making it less immediately actionable than a verb-led opening would be.

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

Completeness3/5

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

With no output schema, the description's enumeration of returned fields (ATC, prescription status codes, EAN packs, leaflet/SmPC links) is genuinely useful return-value context. However, it leaves out the 15-result cap, query matching semantics, and any routing guidance, so it is only minimally complete for a 2-parameter lookup tool.

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?

Schema coverage is 50%: `query` is documented in the schema as 'Drug name, substance or EAN/GTIN', and the description reinforces this by naming substance/EAN-like content. The `max` parameter, by contrast, is undocumented in both schema and description, so the description only partially compensates for the coverage gap.

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

Purpose3/5

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

The description states what data comes back (substance, strength, form, ATC, MAH, prescription status, packs, leaflet/SmPC links) but never states an action verb such as 'look up' or 'search'. An agent can infer a register lookup from the name and the required `query` param, but the purpose is framed as a data-content list rather than a task, and no sibling (drug_price, data_sources) is distinguished.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of the siblings drug_price or data_sources, even though a price lookup is the obvious adjacent tool an agent must choose between. Nothing tells the agent when this tool is the right call versus pricing or source metadata.

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

drug_priceRefunded drug price, co-payment and cheaper substitutes (Poland)A
Read-only
Inspect

Official pharmacy price, NFZ refund limit, refund level and patient co-payment of a medicine on the Polish refund list, with cheaper equivalents (same substance, strength and pack size) and the cheapest price per tablet. Also tells if the pack is free for seniors 65+, children under 18 or pregnant women. query: brand + strength ("Tulip 20 mg"), substance ("atorwastatyna 20 mg" / "atorvastatinum"), pack size ("30 szt") or EAN/GTIN.

NameRequiredDescriptionDefault
maxNoHow many substitutes to list (default 5)
queryYesDrug name / substance with optional strength and pack size, or EAN/GTIN
indicationNoDisease or indication, when refund depends on it (e.g. 'cukrzyca')

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real domain behavior beyond that: the tool surfaces refund limits, per-tablet cheapest price, and free-of-charge status for seniors 65+, under-18s and pregnant women, which tells the agent what to expect semantically. It does not cover ambiguous queries, no-match behavior, or result shape, keeping it short of a 5.

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

Conciseness4/5

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

Two dense sentences front-load the return payload, followed by a compact query-format line. Nearly every clause carries information; only the long enumeration of free-of-charge groups could be tightened.

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?

With no output schema, the description correctly carries the return-value burden and does so thoroughly, plus it documents the key query parameter. It stops short of describing edge cases (ambiguity, no match, non-refunded medicines) that an agent would want for a 3-parameter lookup tool.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema's generic 'Drug name / substance with optional strength and pack size, or EAN/GTIN' by giving concrete query forms ('Tulip 20 mg', 'atorwastatyna 20 mg', 'atorvastatinum', '30 szt', EAN/GTIN), which materially helps query construction. `max` and `indication` are not discussed, so it is not a full 5.

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 names a precise resource (Polish refund-list medicine pricing) and enumerates exactly what is returned: official pharmacy price, NFZ refund limit, refund level, patient co-payment, cheaper equivalents, and price per tablet. That scope cleanly separates it from the generic-sounding sibling drug_info without needing to name it.

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?

Usage is implied by the Polish refund-list scope and the query-format guidance, but the description never states when to prefer this over drug_info or data_sources, nor any exclusion (e.g. non-refunded or foreign drugs). No explicit when/when-not routing is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.1
    • First observeddata_sources
    • First observeddrug_info
    • First observeddrug_price
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

The three tools have clearly distinct purposes: drug_price handles reimbursement, co-payment, and price comparisons; drug_info retrieves official registry metadata and leaflet links; data_sources explains provenance. There is no meaningful overlap that would cause an agent to misselect between them.

Naming Consistency5/5

All tool names use consistent snake_case with descriptive noun phrases (drug_price, drug_info, data_sources). The drug_ prefix groups the two drug lookup tools logically, and data_sources is still stylistically consistent.

Tool Count5/5

Three tools are well-scoped for a focused Polish drug pricing and registry lookup server. Each tool has a clear, non-redundant role, and no obvious operation is missing that would justify adding more tools.

Completeness4/5

The surface covers the core domain well: pricing/refund data, cheaper equivalents, senior/child/pregnancy exemptions, registry details, pack EANs, leaflets, and data provenance. Minor potential gaps exist around broader discovery or safety/interaction information, but the stated scope is substantially covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-aemps

    romanpert
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to query the official Spanish AEMPS/CIMA registry for real-time pharmaceutical data, including medications, supply problems, and clinical equivalences.
    84 PyPI
    1
    Apache 2.0

  • Israel Drugs MCP Server

    DavidOsherdiagnostica
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides AI agents with comprehensive access to Israel's complete pharmaceutical database from the Ministry of Health, enabling drug information search, therapeutic comparisons, and safety assessments.
    19
    Creative Commons Attribution Non Commercial Share Alike 4.0 International

  • mcp-pharma

    atomno-mcp
    A
    license
    A
    quality
    B
    maintenance
    Russian drug reference for AI agents: check ГРЛС registration, get a drug card, look up ЖНВЛП price caps, check recalls, and link the official instruction straight from the state registers.
    6
    35 PyPI
    MIT