Click on "Deploy 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., "@ilac-mcp Parol 500 mg tabletin eşdeğerleri neler?"
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.
Türkiye'de ruhsatlı beşeri ilaçlar için TİTCK verisini yapay zekâ asistanlarına açan bir Model Context Protocol sunucusu.
An MCP server exposing Turkish Medicines and Medical Devices Agency (TİTCK) drug lists: search, generic equivalents, licence and e-prescription status.
⚠️ Tıbbi tavsiye değildir. Veriler TİTCK'nın kamuya açık listelerinden derlenir. İlaç kullanımı veya değişikliği için hekim ya da eczacıya danışın.
Araç | Açıklama |
| Ürün adı, etkin madde, barkod ya da ATC koduyla arama. Türkçe karakter ve büyük/küçük harf fark etmez. |
| Barkodla tek ürün: ruhsat no/tarihi, askı durumu, reçete türü, temel ilaç listeleri. |
| Aynı ATC kodu, aynı doz ve aynı form grubundaki ürünler; diğer doz/formlar ayrıca listelenir. |
| Son e-reçete listesinde yeni eklenen ve değişen ürünler. |
| TİTCK'dan güncel listeleri indirip yerel veritabanını yeniden kurar. |
| Yerel verinin hangi tarihli listelerden kurulduğu. |
Örnek sorular: "Parol 500 mg tabletin eşdeğerleri neler?", "8699522095650 barkodlu ilaç e-reçetede aktif mi?", "Bu hafta e-reçete listesine hangi ilaçlar eklendi?"
Related MCP server: mcp-aemps
uv gerekir.
git clone https://github.com/dckaratas/ilac-mcp
cd ilac-mcp
uv run ilac-mcp sync # TİTCK listelerini indirir (~4 MB, ~20 sn)İstemcinin MCP yapılandırmasına ekleyin (yolu kendi klasörünüzle değiştirin):
{
"mcpServers": {
"ilac": {
"command": "uv",
"args": ["run", "--directory", "C:\\Dev\\mcp\\ilac-mcp", "ilac-mcp"]
}
}
}İlk çağrıda veri yoksa sunucu listeleri kendisi indirir.
uv run ilac-mcp ara "majezik"
uv run ilac-mcp syncListe | Güncellenme | Kullanılan alanlar |
Haftalık (cuma) | Barkod, ürün adı, etkin madde, ATC, ruhsat sahibi/no/tarihi, askı durumu | |
Haftalık (salı) | Aktif/pasif, reçete türü, ATC adı, temel ilaç listeleri, haftalık değişiklikler |
İki liste barkod üzerinden birleştirilir. Veri yerelde saklanır (Windows: %LOCALAPPDATA%\ilac-mcp);
konumu ILAC_MCP_DATA_DIR ortam değişkeniyle değiştirilebilir.
Bu repo yalnızca kodu içerir ve MIT lisanslıdır. TİTCK verisi repoda dağıtılmaz; her kullanıcının makinesinde doğrudan titck.gov.tr'den indirilir. Yanıtlar kaynak ve liste tarihini içerir.
Eşdeğerlik sezgiseldir. Doz ve form ürün adından çıkarılır; ürünlerin ~%28'inde doz, ~%19'unda form
tespit edilemiyor. Bu ürünler farkli_doz altında görünür.
Fiyat yok. TİTCK'nın güncel fiyat listesi giriş gerektiriyor; kamuya açık referans fiyat listesi düzensiz yayımlanıyor.
Prospektüs (KT/KÜB) henüz yok. Yol haritasında.
KT/KÜB metinlerinden bölüm getirme (endikasyon, doz, yan etki, uyarılar)
Referans fiyat listesi ve fiyat geçmişi
Ruhsat iptal listesi ve geri çekme duyuruları
PyPI yayını (uvx ilac-mcp)
uv run pytest
git config core.hooksPath .githooks # commit öncesi kontrolleri etkinleştirir (bir kez)Commit öncesi kanca; anahtar/secret dosyalarını ve TİTCK verisini engeller, gitleaks
ile secret taraması yapar ve testleri çalıştırır. gitleaks'in PATH'te olması gerekir. CI aynı taramayı
tüm git geçmişi üzerinde tekrarlar.
Testler gerçek TİTCK dosyalarının başlık ve sayfa yapısını taklit eden küçük örnek dosyalar kullanır.
Bir ilacın eşdeğerlerini bulur: aynı ATC kodu ve aynı doz.
"farkli_doz" aynı etkin maddenin başka dozlarını içerir. Farmasötik form ve
SGK geri ödeme durumu ayrıca kontrol edilmelidir.
| Name | Required | Description | Default |
|---|---|---|---|
| barkod | Yes | ||
| sadece_aktif | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds meaningful scope: equivalence means same ATC code and dose, 'farkli_doz' contains other doses of the same active ingredient, and pharmaceutical form and reimbursement are not covered. This is useful behavioral context beyond the annotations, though return structure is left to the output 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 short sentences, front-loaded with the purpose, followed by actionable caveats. No filler; every sentence carries 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?
An output schema exists, so return values need not be described, and the annotations cover safety. However, with no parameter explanations and no explicit sibling routing, the description leaves the agent guessing how to fill 'barkod' and 'sadece_aktif'. Adequate but with clear gaps.
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 for both parameters. It never mentions 'barkod' (the required identifier) or 'sadece_aktif' (default true), leaving the agent to infer their meaning from field names alone. This is a significant gap for a 2-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?
States a specific verb and resource ('Bir ilacın eşdeğerlerini bulur') and defines the matching criteria (same ATC code and same dose). It is distinguishable from ilac_ara and ilac_detay, though it does not explicitly name those siblings.
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?
Implies usage for equivalence lookup by barcode, and advises checking pharmaceutical form and SGK reimbursement separately, which hints at routing to other tools. It does not explicitly state when to prefer this over ilac_detay or ilac_ara, nor any exclusions beyond the caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Son e-reçete listesinde yeni eklenen ve değişiklik yapılan ürünleri listeler.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds scope by specifying that it lists newly added and modified products in the latest e-prescription list, but it does not clarify the weekly window or what counts as a change.
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?
It is a single, front-loaded sentence with no wasted words. It could be slightly more precise about the weekly time window, but it is appropriately sized for a no-argument listing tool.
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?
An output schema exists, annotations cover safety, and there are no parameters, so the description only needs to identify the data source and change types. It does that adequately, though it leaves the meaning of 'haftalik' implicit in the tool name rather than the description.
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 takes zero parameters, and the schema coverage is 100%, so there are no parameter semantics to explain. A baseline of 4 is appropriate because the description need not compensate for any parameter documentation gap.
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 ('listeler') and resource ('yeni eklenen ve değişiklik yapılan ürünler') within the latest e-prescription list. It is distinguishable from the drug lookup and update siblings, though it does not explicitly name them.
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 guidance on when to use this tool versus alternatives such as veri_durumu or veri_guncelle. The agent must infer that it is for monitoring recent weekly changes rather than querying drug details or updating data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
İlaç arar. Sorgu ürün adı, etkin madde, barkod (8-14 hane) ya da ATC kodu (ör. N02BE01) olabilir.
Türkçe karakterler ve büyük/küçük harf fark etmez. Aktif ürünler önce listelenir.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sorgu | Yes | ||
| sadece_aktif | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real operational context beyond that: case- and Turkish-character-insensitivity, and the ordering rule that active products are listed first. It does not discuss result volume or what limit does, which keeps it from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action and all query formats front-loaded, followed by normalization and ordering behavior. Nothing is redundant and nothing restates the tool name without adding 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?
An output schema exists, so return values need not be described, and the read-only nature is covered by annotations. The description supplies query semantics and sort order, which is what an agent needs to call it correctly; the only gap is guidance on 'limit' and 'sadece_aktif'.
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, and it does so well for 'sorgu' by specifying all four accepted input formats and the expected normalization. However, 'limit' and 'sadece_aktif' are never explained — only indirectly hinted at by 'aktif ürünler önce listelenir' — leaving two of three parameters undocumented.
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?
States a specific verb and resource ('İlaç arar') and enumerates the exact query forms accepted (product name, active ingredient, barcode 8-14 digits, ATC code with example). It does not explicitly contrast itself with siblings like ilac_detay, so an agent must infer that this is the search entry point, but the purpose itself is unambiguous.
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?
Usage is implied by the query-format list (use this when you have a name, substance, barcode, or ATC code), but there is no explicit when-to-use/when-not guidance and no routing to ilac_detay or esdeger_bul. The agent can guess the entry point but is not told what to do after a search or when a different sibling is better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Barkodla tek bir ilacın tüm bilgilerini getirir: ruhsat, askı durumu, reçete türü, temel ilaç listeleri.
| Name | Required | Description | Default |
|---|---|---|---|
| barkod | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the data categories returned, which is useful, but says nothing about behavior for an unknown barcode, error handling, or any behavioral constraint beyond what structured fields already convey.
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 well-formed sentence, front-loaded with the action and scoped with 'tek bir', followed by a compact list of what is returned. Every clause 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?
With an output schema present, return values need not be described, and annotations cover read-only/safety. For a one-parameter lookup the description is nearly complete, missing only barcode format guidance and not-found behavior.
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, and schema description coverage is 0% — 'barkod' has no schema description. The description compensates minimally by clarifying it is the barcode used to identify the drug, but gives no format or length expectation. Baseline is 3 given the single-parameter 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?
States a clear verb and resource: fetch a single drug's full details by barcode, and enumerates the field groups returned (license, suspension status, prescription type, essential drug lists). 'tek bir ilaç' implicitly contrasts with the search-oriented sibling ilac_ara, but no sibling is named explicitly.
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 phrase 'Barkodla' implies this is the tool to use when you already have a barcode, distinguishing it from ilac_ara in practice. However, no explicit when-to-use, when-not-to-use, or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Yerel verinin hangi tarihli TİTCK listelerinden kurulduğunu gösterir.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral fact that this reports provenance against dated TİTCK sources rather than live remote state, which is extra context beyond the 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 with no filler; every word contributes to identifying the resource and the returned 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?
With no parameters, a present output schema, and annotations covering safety, the description is essentially complete for calling the tool. It could add a note on when this status matters relative to siblings, but nothing needed to invoke it correctly is missing.
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 takes zero parameters, so the baseline is 4. The description correctly implies no input is needed to obtain the data-status report.
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?
It states a specific verb (gösterir) and a specific resource (yerel veri) plus exactly what is shown: which dated TİTCK lists the local data was built from. This clearly separates it from veri_guncelle (mutation) and the drug-lookup siblings without needing to open any schema.
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 purpose implies a status/provenance check, but the description never says when an agent should call it, e.g. before relying on data freshness or after veri_guncelle. Usage context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TİTCK'dan en güncel listeleri indirip yerel veritabanını yeniden kurar (yaklaşık 4 MB indirme).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a write operation (readOnlyHint=false), external network access (openWorldHint=true), and idempotency. The description adds genuinely new context: the upstream source (TİTCK), that it rebuilds rather than appends, and a ~4 MB download estimate. It stops short of saying whether existing local data is wiped or whether the rebuild is atomic, which matters for a destructive-style refresh.
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: action plus effect plus the download cost in parentheses. Every clause carries information an agent needs before invoking it.
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 no-parameter refresh tool with an output schema and annotations covering safety and network behavior, the description covers source, effect, and cost. The only gap is failure/partial-refresh behavior, which is minor given the output schema exists.
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 takes zero parameters, so there is nothing beyond the empty schema to explain. Baseline 4 applies.
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?
States specific verbs (download, rebuild) and a concrete resource (the local database seeded from TİTCK lists), so an agent knows this is a full data refresh rather than a query. It doesn't explicitly contrast with the closest sibling veri_durumu, which reports state rather than refreshing it.
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?
Usage is only implied: refresh the dataset when it's stale. There is no explicit when-to-use guidance, no mention of calling veri_durumu first to check whether a refresh is needed, and no note on whether other tools should be avoided during the rebuild.
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.
v0.1.0esdeger_bulhaftalik_degisikliklerilac_arailac_detayveri_durumuveri_guncelleScored across 6 tools
Each tool has a recognizable focus: free-text lookup (ilac_ara), single-record detail by barcode (ilac_detay), equivalence lookup (esdeger_bul), change feed, and data maintenance. The main soft overlap is that ilac_ara also accepts barcodes/ATC codes, which can make it a tempting substitute for ilac_detay or esdeger_bul, but the descriptions make the intended split clear.
All names are lowercase snake_case with a noun-then-action/qualifier shape (ilac_ara, ilac_detay, veri_guncelle, veri_durumu), and the shared ilac_/veri_ prefixes group related tools. Two tools (esdeger_bul, haftalik_degisiklikler) break the prefix grouping, which is a minor deviation rather than an inconsistency.
Six tools is a tight, purposeful set for a drug-lookup server: one search, one detail, one equivalence helper, one change feed, and two data-lifecycle tools. Nothing appears redundant and no obvious step of the workflow is missing a tool.
The surface covers the core lifecycle well: query, single-record inspection, equivalent-drug discovery, change tracking, and data freshness/refresh. Gaps are minor — there is no way to browse or filter lists (e.g. by prescription type, SGK reimbursement, or active-ingredient-only enumeration) other than free-text search.
Live US drug acquisition costs (CMS NADAC) for AI assistants. Free, no auth, weekly data.
Free health AI: drug interaction checks, medicine facts and health questions in 90+ languages
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
Look up drug names, RxCUIs, ingredients and interactions in RxNorm.