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., "@diaskor-mcp 62 yaşında hastamın DSS skorunu hesapla: URR 67, K 5.2, albumin 3.3"
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.
Hemodiyaliz hastasında "bu hasta kötüleşiyor mu?" sorusuna sahadan bakan, 28 puanlık bir klinik karar destek skoru. Claude Desktop gibi MCP destekleyen araçlarda doğrudan kullanılabilen bir MCP sunucusu olarak paketlendi.
⚠️ Bu bir klinik karar destek aracıdır, hekim kararının yerini almaz. Skor henüz prospektif olarak valide edilmemiştir. Geliştirmeye ve tartışmaya açıktır.
Diyaliz hastası aynı anda üç kanaldan kötüleşebilir: diyaliz yeterliliği, metabolik yük ve kronik zemin. Tek tek laboratuvar değerleri normal görünürken hasta "gidiyor" olabilir. DSS bu sinyalleri tek bir sayıda toplar. Bunu yaparken tek bir öldürücü değerin toplam içinde kaybolmasına da izin vermez.
Related MCP server: Medical Calculator MCP Server
Glasgow Koma Skalası mantığı: toplamalı, tavanlı, yüksek puan = iyi.
Parametre | Puan |
URR | 0–2 |
Volüm (kişisel sodyum sapması + kuru ağırlık trendi) | 0–2 |
Prediyaliz potasyum | 0–2 |
Albumin | 0–4 |
Hemoglobin (MCV / EPO bağlamıyla) | 0–2 |
CRP (kişisel baseline'a göre) | 0–2 |
Demir (TSAT + ferritin) | 0–2 |
Mineral-kemik (Ca×P + PTH) | 0–2 |
Bikarbonat | 0–2 |
Primer tanı + kontrol durumu (HbA1c, komplikasyon) | 0–4 |
Kırılganlık (Clinical Frailty Scale; yoksa biyolojik yaş) | 0–2 |
Son 90 gün klinik olay | 0–2 |
Toplam | 0–28 |
Karar: 19–28 stabil · 10–18 yakından izle · <10 acil değerlendir
Kırmızı bayrak: K ≥ 6.5 veya albumin < 2.5 olduğunda toplam puan kaç olursa olsun alarm verir.
Trend: 3 aylık gidiş kötüyse yeşil parametre sarıya iner ve "↓ kötüleşiyor" etiketi alır.
Bağlam mesajları: Skor sadece sayı vermez, hekime bir cümle de yazar. Örnekler: "Hb düşük + MCV < 80 → demir eksikliği", "Ca×P yüksek ama diyaliz yeterli → diyet ve bağlayıcıya bakın", "CRP 2 kat + ferritin ve lökosit yüksek → enfeksiyon olasılığı".
Tüm eşikler src/skor.js içindeki ESIK nesnesinde tek bir yerde durur.
Araç hiçbir veri saklamaz, ağ bağlantısı kurmaz, isim ya da kimlik numarası istemez. Değerleri alır, puanı hesaplar, sonucu döndürür.
git clone https://github.com/turgutkecik/diaskor-mcp.git
cd diaskor-mcp
npm install
npm testclaude_desktop_config.json:
{
"mcpServers": {
"diaskor": {
"command": "node",
"args": ["C:/yol/diaskor-mcp/src/index.js"]
}
}
}dss_hesapla: skoru hesaplar; parametre puanlarını, renkleri, trendleri, kırmızı bayrakları ve bağlam mesajlarını döner.
dss_yontem: tüm eşikleri ve karar aralıklarını döner.
Kod içinden de kullanılabilir:
import { hesapla } from 'diaskor-mcp';
const sonuc = hesapla({ yas: 62, diyaliz_suresi_yil: 6, primer_tani: 'dm', hba1c: 6.8, lab: { urr: 67, k: 5.2, albumin: 3.3 } });Nexgene Research ekibinin Nexonco MCP çalışmasından ilham alındı.
Dr. A. Turgut Keçik — hemodiyaliz hekimi (2008'den beri). Arca (Claude) ile birlikte geliştirildi.
PolyForm Noncommercial 1.0.0. Hekimler, araştırmacılar, akademik kurumlar ve kar amacı gütmeyen kuruluşlar aracı serbestçe kullanabilir, değiştirebilir ve paylaşabilir. Ticari kullanım için (yazılım firmaları, ücretli ürün ya da hizmet içine yerleştirme gibi) önce izin alınması gerekir: diasera.com.tr/iletisim
English summary: DSS is a 28-point, additive, GCS-style stability score for hemodialysis patients (higher = better), exposed as an MCP server. It combines dialysis adequacy, metabolic/inflammatory burden, chronic background and frailty. Red flags (K ≥ 6.5, albumin < 2.5) override the total score. It stores no data. Clinical decision support only; not yet validated. Open to discussion and contributions. Licensed under PolyForm Noncommercial 1.0.0; commercial use requires permission.
Hemodiyaliz hastası için Diyaliz Stabilite Skoru (DSS v2.0.0) hesaplar. 0–28 puan, yüksek puan = iyi. 19–28 stabil, 10–18 yakından izle, <10 acil değerlendir. Kırmızı bayraklar (K ≥ 6.5, albumin < 2.5) toplamdan bağımsız alarm verir. Her parametre için puan, renk, trend ve hekime yönelik bağlam mesajı döner. Eksik parametreler raporlanır. Hasta kimliği (isim, TC) GİRİLMEMELİDİR; araç veri saklamaz. Klinik karar desteğidir, hekim kararının yerini almaz.
| Name | Required | Description | Default |
|---|---|---|---|
| cfs | No | Clinical Frailty Scale 1–9 (varsa biyolojik yaş yerine kullanılır) | |
| lab | No | Güncel laboratuvar değerleri | |
| yas | No | Kronolojik yaş (yıl) | |
| hba1c | No | HbA1c % (DM hastalarında) | |
| onceki | No | Önceki ölçümler | |
| olaylar | No | Son 90 gündeki klinik olaylar | |
| primer_tani | No | Primer böbrek hastalığı: dm=diyabetik nefropati, kv=kardiyovasküler/iskemik, rcc=renal hücreli karsinom, ht=hipertansif nefroskleroz, nefrit=kronik glomerülonefrit, pkb=polikistik böbrek | |
| kuru_agirlik | No | Güncel kuru ağırlık (kg) | |
| rezidual_diurez | No | Rezidüel diürez var mı | |
| diyaliz_suresi_yil | No | Diyalizde geçen süre (yıl) | |
| komplikasyon_sayisi | No | DM/KV komplikasyon sayısı (retinopati, nöropati, ayak yarası, MI, KKY, inme, PAH vb.) | |
| kuru_agirlik_3ay_once | No | 3 ay önceki kuru ağırlık (kg) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: severity thresholds (19–28 stabil, 10–18 izle, <10 acil), independent red flags (K ≥ 6.5, albumin < 2.5), the per-parameter return contents (score, color, trend, clinician message), handling of missing parameters, and an explicit no-storage/PII prohibition. It stops short of stating determinism, validation-error behavior, or that it is a pure side-effect-free computation, which keeps it out of the top band.
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?
Six dense sentences with essentially no filler: purpose, scale, red flags, return contents, missing-data handling, and safety disclaimer each add information. It is delivered as one undifferentiated block, so thresholds and the return-value sentence are not as visually front-loaded as they could be.
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 12-parameter, nested-object tool with no output schema, the description covers output shape, alarm semantics, and partial-data behavior well enough to call it correctly. The remaining gap is input-importance prioritization and the relationship to dss_yontem, which an agent would need in order to decide between the two.
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 coverage is 100%, so baseline is 3, and the description adds genuine meaning beyond the schema by tying concrete lab values to alarm behavior (K ≥ 6.5, albumin < 2.5) and by warning that patient identity must not be supplied even though the object schema accepts free-form values. It still does not clarify which of the 12 optional inputs actually move the score versus merely adding context (the schema hints Kt/V is 'bağlam için', but the description is silent).
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?
Names a specific verb and resource with a version marker: "Diyaliz Stabilite Skoru (DSS v2.0.0) hesaplar" for a hemodialysis patient. It immediately defines the output scale (0–28, higher = better) and the interpretation bands, so an agent knows exactly what the tool produces without consulting the 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 eligible population is implied (hemodialysis patients) and the tool self-describes as clinical decision support, but there is no explicit when-to-use/when-not guidance and no mention of the sibling dss_yontem (methodology), so an agent must infer the routing between the two. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diyaliz Stabilite Skoru'nun parametrelerini, puan eşiklerini ve karar aralıklarını döner.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'döner' (returns) implies a pure read with no side effects, which is reassuring, but it says nothing about caching, versioning, or whether the returned thresholds are fixed constants.
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 compact sentence that front-loads the subject and enumerates the three return categories with no filler.
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 output schema and no parameters, the description does provide the key content an agent needs — that it returns parameters, thresholds, and decision ranges — though it does not describe the shape or format of that returned data.
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 for the description to disambiguate; the baseline of 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?
The description names a specific resource (Diyaliz Stabilite Skoru) and specifies exactly what is returned: parameters, score thresholds, and decision ranges. It is clearly a reference/lookup tool, though it never names the sibling dss_hesapla to make the distinction explicit.
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 — an agent can infer this is the tool to consult for DSS scoring rules before calling dss_hesapla, but the description states no explicit when-to-use condition or comparison with the alternative.
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.
v2.0.0dss_hesapladss_yontemScored across 2 tools
The two tools have clearly distinct purposes: dss_hesapla performs the score calculation, while dss_yontem returns methodology, parameters, thresholds, and decision ranges. An agent can easily choose between calculating a result and looking up how the score works.
Both tools use the same dss_ prefix and are readable as a related pair. One name is action-oriented (hesapla) while the other is noun-oriented (yontem), so the pattern is slightly mixed but still predictable.
Two tools is on the low end, but appropriate for a narrow single-score clinical calculator: one calculates and one explains the method. No unnecessary tools are included.
The surface covers the core lifecycle of this domain: computing the DSS and exposing the scoring method, thresholds, and interpretation. Calculation-side features such as missing-parameter reporting, red flags, and per-parameter context are included in the calculation result.
Remote MCP server for deterministic educational practice-assessment score conversions.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Hosted MCP for denial, prior auth, reimbursement, workflow validation, batch scoring, and feedback.
Deterministic eligibility scoring for AI agents: CLEAR/HOLD/FAIL verdicts, published weights.
