Doktor MCP
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., "@Doktor MCPHasta hakları ve aydınlatılmış onam hakkında güncel mevzuat ve Yargıtay kararlarını getir"
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.
Doktor MCP
Beta sürüm — Güncel sürüm için package.json ve CHANGELOG.md dosyalarına bakın.
Proje sayfası: avfatihsozer.com/projeler/doktor-mcp · English: README.en.md
doktor-mcp, hekimlere yönelik kaynak-temelli hukuki bilgilendirme paketleri üreten,
bağımsız bir TypeScript/Node.js MCP iskeletidir. Kategorik nihai hukuki görüş vermez ve
hekime ne yapacağını söylemez. Soruları resmî mevzuat metniyle ve gerekçeli yüksek mahkeme
karar metniyle eşleştirir; kesin hüküm vermeden, kaynağa dayalı koşullu değerlendirmeler
(ör. "kaynaklar bu yönde eğilim göstermektedir") sunabilir.
Adaptör sınırları şunlar için hazırlanmıştır:
legislation(mevzuat)yargitaydanistayaym
Genel internet makaleleri, bloglar, haberler, hukuk bürosu tanıtım sayfaları ve forumlar bu projenin kaynak girdileri değildir.
Kaynak Motoru Aktarımı (Source Engine Port)
Kaynak-motoru katmanı, canlı adaptörlerin ihtiyaç duyduğu sağlamlaştırmayı sağlar:
Bedesten istekleri; sınırlı yeniden deneme,
Retry-Afterişleme, üstel geri-çekilme (backoff), titreşim (jitter) ve istek telemetrisi içeren paylaşılan birHttpClientveRateLimiteryolu kullanır.Canlı kaynak hataları yapılandırılmış ve yalnızca-JSON kalır. Kaynak tanılaması; CLI JSON çıktısına log yazmadan yeniden deneme sayısı, backoff süresi, durum ve içerik tipini taşıyabilir.
src/sources/sourceRegistry.ts, mevzuat ve emsal kaynakları için sadeleştirilmiş kaynak yeteneği, hız limiti ve önbellek politikası meta verisini sunar.Bedesten/Yargıtay adaptörleri yalnızca-meta veri içeren kararları doğrulanmış emsal çıktısından uzak tutar; resmî mevzuat ise resmî arama, doküman getirme veya madde çıkarımı bir alıntıyı destekleyemediğinde yapılandırılmış
unavailablesonuç döndürür.
Related MCP server: Law7 MCP
Canlı Mevzuat Durumu
Canlı resmî mevzuat adaptörü, opsiyonel MCP araç akışlarına bağlanmıştır:
adaptör:
LiveOfficialLegislationAdapterresmî kaynak: T.C. Cumhurbaşkanlığı Mevzuat Bilgi Sistemi —
mevzuat.gov.trarama yeteneği: resmî
MevzuatDatatablearama isteği ayrıştırıcısıtam-metin yeteneği: resmî
MevzuatMetindoküman getirmemevcut çıkarım kanıtı: eşlenmiş mevzuat için PDF metin çıkarımı ve madde ayrıştırma
Sağlık mevzuatı ilk canlı eşleme yoludur. Hasta hakları ve aydınlatılmış onam soruları,
Hasta Hakları Yönetmeliği 4847 için resmî üretilmiş PDF yolunu kullanır (eşlenmiş madde
24 ve 26 dahil). Sağlık hukuku eşlemeleri ayrıca Tıbbi Deontoloji Nizamnamesi, Tababet
ve Şuabatı San'atlarının Tarzı İcrasına Dair Kanun ve Sağlık Hizmetleri Temel Kanunu'nu da
kapsar. KVKK madde 6, kişisel-sağlık-verisi ve mahremiyet soruları için, sağlığa özel
kaynaklardan sonra destekleyici genel mevzuat olarak kullanılabilir.
Resmî bir doküman çıkarılabilir bir formatta gelmediğinde veya eşlenmiş bir madde
çıkarılamadığında, canlı adaptör bir hüküm üretmek yerine yapılandırılmış unavailable
çıktısı döndürür.
Canlı kaynak hataları şu sözleşmeyi kullanır:
{
"status": "unavailable",
"source": "mevzuat.gov.tr",
"errorCode": "provision_not_found",
"message": "Official text was retrieved but the mapped article could not be extracted.",
"retryable": false,
"recommendedNextStep": "Inspect the official text parser before using this provision in an answer."
}MVP Kapsamı
İskelet şunları içerir:
MCP sunucu kaydı ve araç işleyici iskelesi
resmî mevzuat delili, mahkeme kararı delili, sınıflandırma, emsal durumu ve hukuki bilgilendirme paketi için tip sözleşmeleri
mock mevzuat ve yüksek mahkeme adaptörleri
resmî kaynak doğrulaması için canlı resmî mevzuat adaptörü
canlı mevzuat için MCP
sourceModeyönlendirmesisağlık-öncelikli mevzuat eşlemeleri ve kaynak izleme (source trace) meta verisi
sağlık hukuku boru hattı parçaları:
soru sınıflandırıcı
mevzuat eşleyici
emsal filtresi
cevap derleyici
yerel JSON smoke komutu
ilk kaynak-güvenliği kuralları için Vitest kapsamı
Emsal filtresi şu an şu durumları sunar:
precedent_usable: tam metin, hukuki gerekçe ve olay ilgililiği mevcutlimited_value: tam metin var ama ilgililik zayıfprocedural_only: esasa ilişkin gerekçe yok; usuli metin, salt onama veya salt bozmametadata_only: tam metin olmadan künye meta verisino_reasoning: tam metin var ama hukuki gerekçe yok
Derlenen pakette doğrulanmış emsal bölümüne yalnızca precedent_usable kayıtları girer.
Yanıt Sözleşmesi (Response Contract)
Tüm araç yanıtları dataOrigin alanı taşır. Bu alan, yanıtın kaynağını belirtir:
| Anlamı |
| Yanıt fixture (kurgu) verisi içerir. Gerçek mevzuat veya karar değildir. |
| Yanıt canlı kaynaklardan (mevzuat.gov.tr, Bedesten, Danıştay) gelmiştir. |
| Yanıt önceden kaydedilmiş canlı kaynak snapshot'ıdır. |
| Yanıt yalnızca hesaplama sonucudur (sınflandırıcı gibi). Kaynak veri içermez. |
| Yanıt, istemci tarafından sağlanan girdiye dayanır. |
dataOrigin: "mock" olduğunda, yanıt ayrıca mockDataWarning alanı taşır:
{
"dataOrigin": "mock",
"mockDataWarning": "BU YANIT KURGU (FIXTURE) VERİSİDİR. Gerçek mevzuat veya mahkeme kararı DEĞİLDİR. Gerçek kaynaklar için sourceMode: 'live' kullanın."
}Bu uyarı, mock verinin gerçek mevzuat alıntısı gibi görünmesini önlemek için
kaçırılamaz şekilde eklenmiştir. shortAnswer gibi hekime-dönük metin alanlarına
ek önek eklenmez; üst-seviye dataOrigin ve mockDataWarning alanları yeterlidir.
prepare_doctor_legal_information_pack yanıtı ayrıca bir packId alanı taşır.
Bu, "pack-" önekiyle başlayan 6 haneli bir hex kimliktir (ör. "pack-3f9a2c").
drill_down_pack_item aracına packId ileterek paketi yeniden oluşturmadan
belirli bir madde veya kararı detaylandırabilirsiniz. packId, sunucu belleğinde
30 dakika süreyle saklanır.
Yapılandırılmış paket, istenen hekime-dönük bölümler etrafında şekillenir:
shortAnswerlegalClassificationcriminalcivilCompensationdisciplinaryAdministrativepatientRightsprivacyKvkkprofessionalEthics
relevantLegislationmevzuat adı
madde numarası
kaynak hükümden birebir kopyalanmış alıntı
olay bağlantısı
verifiedHighCourtPrecedentsmahkeme/daire, tarih, esas/karar numaraları
olay özeti, hukuki değerlendirme, sonuç
benzerlik/farklılık notu
missingInformationlawyerReviewPoints
Her mevzuat girdisi bir kaynak doküman id'si ve birebir kaynak alıntısı taşır. Her doğrulanmış emsal girdisi, gerekçeli-emsal filtresinden geçmek zorundadır.
Bilinçli Olarak Kapsam Dışı
MVP şunları içermez:
canlı AYM yüksek mahkeme istemcisi (AYM kararlar bilgi bankası HTML-only arayüzdür; JSON API yoktur —
synthetic_onlyişaretlidir)kaynak referansı veya koşullu dil olmaksızın kategorik risk seviyesi puanlaması ("risk seviyesi yüksek/düşük")
acil eylem talimatları
dilekçe veya savunma yazımı
nihai hukuki sonuçlar
"sorumluluk vardır" veya "sorumluluk yoktur" gibi kategorik ifadeler
Araç, kaynağa dayalı koşullu değerlendirmeler (ör. "kaynaklar şu yönde eğilim gösteriyor") sunabilir; ama asla kategorik nihai hüküm vermez
MCP kaynak kayıtlarıyla doğrulanmamış, yalnızca-modele dayalı hukuki önermeler
v0.44.0'da Yeni
assessmentTone: Opsiyonel parametre ("strict"|"grounded-advisory", varsayılan:"grounded-advisory").strictmodda yalnızca kaynak listeleri döner (değerlendirme yok).grounded-advisorymodda, kaynağa dayalı koşullu değerlendirme içeren birpreliminaryAssessmenteklenir.preliminaryAssessment:summaryvesentences[]içeren opsiyonel yanıt alanı. Her cümledetext,sourceRefvesourceLabelbulunur. Cümleler emsallerden gerçek sonuç/gerekçeyi ve mevzuattan birebir alıntı parçalarını kullanır — asla kalıp (boilerplate) değil.Mevzuat yürürlük meta verisi: Hükümler
inForce,lastAmendedDateverepealedalanları taşır (varsayılan olarak asla "yürürlükte" varsaymaz).Karar deduplikasyonu: Çapraz-kaynak tekrarları (ör. aynı kararın Yargıtay ve Bedesten'den gelmesi) deduplike edilir; en zengin sürüm tutulur.
Tam Türkçe diakritik politikası: Tüm hekime-dönük metinler doğru Türkçe karakterleri kullanır (ASCII ikamesi yok).
Tam sürüm geçmişi için CHANGELOG.md. Kararlılık katmanları için COMPATIBILITY.md.
Hız limiti canlı istemciler için ayrılmıştır: amaçlanan davranış, gerçek bir blok veya kaynak hatasından sonra adaptif backoff ile pratik kamu-kaynağı trafiğidir; baskı kanıtı olmadan agresif bir kısıtlama değildir.
MCP Araçları
classify_medical_legal_questionsearch_health_legislationget_legislation_provisionssearch_health_precedentsfilter_reasoned_precedentsprepare_doctor_legal_information_packdrill_down_pack_item— Takip sorusu:packIdile paketi yeniden oluşturmadan belirli bir madde/kararı detaylandırır. Örnek:{ "packId": "pack-3f9a2c", "followUpQuestion": "madde 24 ne diyor?" }get_decision_full_text— Belirli bir mahkeme kararının tam metnini getirir. Örnek:{ "documentId": "yargitay:99001", "sourceMode": "live" }
Yanıt Sözleşmesi Notları
Tüm araç yanıtları dataOrigin alanı taşır ("mock", "live", "snapshot", "computed", "client-provided"). Mock modda mockDataWarning alanı eklenir.
prepare_doctor_legal_information_pack çağrısında includeDiagnostics: true parametresi eklenerek tam denetim izi (seçim tanılaması, kaynak izi vb.) alınabilir.
Mevzuata-dönük MCP girdileri opsiyonel sourceMode kabul eder:
{
"question": "kişisel sağlık verisi mahremiyet",
"sourceMode": "live"
}sourceMode varsayılan olarak "live"'dır (0.59.0'dan beri); fixture verisi için "mock" açıkça istenmelidir.
search_health_legislation, get_legislation_provisions ve
prepare_doctor_legal_information_pack "live" kullanabilir. Canlı bilgilendirme paketi
aynı MVP şeklini korur ve sourceUnavailable'ı yalnızca resmî mevzuat kaynağı doğrulanmış
bir hüküm döndüremediğinde ekler.
Mock mod yerel fixture hükümlerini kullanır. Canlı mod, mevzuat.gov.tr'den resmî mevzuat
metnini, ayrıca canlı Yargıtay ve Danıştay emsal adaptörlerini kullanır. AYM yalnızca-mock'tur
ve canlı modda bir geri-dönüş (fallback) olarak kullanılmak yerine devre dışı bırakılır.
Sağlık Mevzuatı Önceliği
Canlı eşleme katmanı hekim sorularını sağlık-hukuku konu kümelerine ayırır:
aydınlatılmış onam / onam
tıbbi müdahale
hasta hakları
hasta mahremiyeti
kişisel sağlık verisi
kayıt, dosya ve epikriz
acil müdahale
sevk ve konsültasyon
hekimin özen yükümlülüğü
meslek etiği
Her eşleme; hedef mevzuatı, hedef madde numaralarını, arama terimlerini, bir seçim gerekçesini ve bir sağlık-hukuku önceliğini taşır. Birden çok eşleme uyduğunda, paket birincil sağlık mevzuatını destekleyici genel mevzuattan önce sıralar. Örneğin bir kişisel-sağlık-verisi mahremiyet sorusu, KVKK'dan önce Hasta Hakları Yönetmeliği'ni döndürebilir; KVKK, ilgisiz hekim soruları için geniş bir geri-dönüş olarak kullanılmaz.
Kaynak İzleme (Source Trace)
sourceTrace, hukuki gerekçe sağlamak yerine canlı mevzuat çıktısını denetler. Her iz, bir
hükmün sağlık-hukuku eşlemesinden resmî dokümana ve madde çıkarım adımına nasıl geçtiğini gösterir:
orijinal
querymatchedHealthMappingve eşleme olmadığında denenen eşleme adaylarıofficialSearchRequest, resmî arama sonuç sayısı ve kompakt resmî sonuçlarselectedSearchResultveselectedResultReasonlanding/detay URL'i ve doğrudan ya da üretilmiş PDF URL'i
contentType, çıkarım yöntemi, çıkarılan madde numaraları ve getirme süresi
Canlı search_health_legislation, seçilen hükümlerin yanında izi de içerir. Canlı
get_legislation_provisions, dönen her hükümde iz taşır. Canlı
prepare_doctor_legal_information_pack, izi hem ilgili mevzuat girdilerinde hem de
pakete-düzey sourceTrace dizisinde tutar; böylece derlenen alıntı, aynı çıkarılmış
hükme karşı kontrol edilebilir.
Bir unavailable canlı paket de denetim bağlamını korur:
{
"sourceUnavailable": [
{
"status": "unavailable",
"source": "mevzuat.gov.tr",
"errorCode": "document_not_found",
"sourceTrace": [
{
"query": "bilinmeyen konu",
"matchedHealthMapping": null,
"attemptedHealthMappings": ["mevzuat:7.5.4847", "mevzuat:1.5.6698"]
}
]
}
]
}matchedHealthMapping ve selectedResultReason; konu kümesini, sağlık-hukuku önceliğini ve
seçilen eşlemenin birincil sağlık mevzuatı mı yoksa destekleyici genel mevzuat mı olduğunu
gösterir. İz alanları yalnızca kaynak seçimini ve çıkarımı açıklar. Hukuki önerme üretmezler
ve birebir resmî hüküm metninin yerini asla almazlar.
Hüküm Sıralaması (Provision Ranking)
Canlı hüküm sıralaması, resmî madde çıkarımından sonra deterministik puanlama çalıştırır. Paket için kompakt bir kaynak-madde kümesi seçer; madde metni, hukuki tavsiye veya kategorik hukuki sonuç üretmez.
Sıralama sinyalleri:
hekim sorgu terimleri
eşlenen sağlık-hukuku konu kümesi
eşleme arama terimleri
çıkarılan madde kullanılabilir bir başlıkla başladığında madde başlığı metni
çıkarılan madde metni içindeki anahtar kelime eşleşmeleri
eşlenmiş madde-listesi bonusu
sağlık-hukuku önceliği ve birincil/destekleyici rol sıralaması
Canlı iz; candidateArticleNumbers, rankedArticleNumbers, rejectedArticleNumbers ve
rankingMethod'u gösterir. Dönen her canlı hüküm ayrıca kendi deterministik skorunu, eşleşen
terimleri, sıralama gerekçelerini ve manuel eşlenmiş madde listesinden gelip gelmediğini
taşır. Canlı adaptör tek bir mevzuat dokümanını küçük bir sıralanmış madde kümesiyle
sınırlar — şu an en fazla üç hüküm. Çıkarılan eşlenmiş maddeler önce gelir; yüksek-sinyalli
sıralanmış yedek maddeler yalnızca eşlenmiş maddeler çıkarımda yoksa değerlendirilir. İz hem
seçilen hem reddedilen aday izini korur.
KVKK, kişisel-sağlık-verisi ve mahremiyet soruları için supporting_general kalır.
Sıralamada veya paket sıralamasında birincil sağlık mevzuatının yerini almaz. Yargıtay,
Danıştay ve AYM adaptörleri mock adaptör olarak kalır.
Seçim Tanılaması (Selection Diagnostics)
Seçim tanılaması, kaynak seçimi için kısa bir denetim görünümü sağlar: sourceTrace hâlâ
resmî isteği, dokümanı, çıkarımı, adayı, sıralamayı ve unavailable detayını içerirken,
tanılama tam bir iz okuması gerektirmeden neyin seçildiğini özetler.
Kompakt tanılama şunları içerir:
query ve
sourceModeseçilen mevzuat ve hüküm sayıları
her seçilen mevzuatın rolü, konu kümesi, önceliği, madde numaraları, reddedilen madde-numarası özeti ve seçim gerekçesi
her seçilen hükmün skoru, eşleşen terimleri, en iyi sıralama gerekçeleri ve eşlenmiş-madde bayrağı
unavailableve uyarı sayıları
Örnek canlı özet:
{
"selectionDiagnostics": {
"query": "kisisel saglik verisi mahremiyet",
"sourceMode": "live",
"selectedLegislationCount": 2,
"selectedProvisionCount": 2,
"selectedLegislations": [
{
"legislationName": "Hasta Haklari Yonetmeligi",
"legislationRole": "health_primary",
"topicCluster": "patient_privacy",
"selectedArticleNumbers": ["21"]
},
{
"legislationName": "Kisisel Verilerin Korunmasi Kanunu",
"legislationRole": "supporting_general",
"topicCluster": "personal_health_data",
"selectedArticleNumbers": ["6"]
}
],
"unavailableCount": 0
}
}Tanılama yalnızca denetim meta verisidir. Resmî hüküm alıntılarının yerini almaz, hukuki önerme üretmez ve KVKK'yı destekleyici-genel rolünde tutar. Yargıtay, Danıştay ve AYM adaptörleri mock adaptör olarak kalır.
Karar Kaynak İzi (Decision Source Trace)
DecisionSourceTrace, her mahkeme kararı adayı için karar boru hattını denetler.
LegislationSourceTrace'in emsal-tarafı karşılığıdır. Her iz şunları taşır:
orijinal
querysourcevecourt(yargitay / danistay / aym)searchRequest(mock adaptörler için null)searchResultsCountveselectedResultdocumentId/sourceIdfullTextAvailablevefullTextRetrievalMethodretrievedAteligibilityStatus— emsal filtresi sonucueligibilityReasons— kararın karşıladığı olumlu kriterlerexclusionReasons— varsa, dışlanmasının belirli neden(ler)igetirme başarısız olduysa
error
Karar kaynak izleri yalnızca denetim meta verisidir. Hukuki gerekçe üretmezler ve karar tüm uygunluk kriterlerini geçmedikçe pakete asla bir mahkeme kararı eklemezler.
Gerekçeli-Karar Uygunluğu
assessDecisionEligibility (src/health/decisionEligibility.ts içinde) emsal filtresi
kurallarını uygular ve durum, olumlu uygunluk gerekçeleri ve dışlama gerekçeleriyle
yapılandırılmış bir EligibilityResult döndürür.
Bir karar, aşağıdakilerden herhangi biri geçerliyse doğrulanmış-emsaller bölümünden dışlanır:
fullTextAvailable: false— tam karar metni mevcut değil (→metadata_only)legalReasoningboş veya eksik (→no_reasoning)Karar metni salt usuli işaret içeriyor:
salt onama,salt bozma,usul karar(→procedural_only)Hukuki gerekçe, esasa ilişkin içerik olmadan yalnızca
onamaveyabozma(→procedural_only)Kararı sağlık-hukuku olayına bağlayan
relevanceNoteyok (→limited_value)
Paketin verifiedHighCourtPrecedents bölümüne yalnızca precedent_usable kararları girer.
limited_value, procedural_only, no_reasoning ve metadata_only kararları dışlanır.
Emsal Tanılaması (Precedent Diagnostics)
PrecedentSelectionDiagnostics, karar seçimi için kompakt denetim görünümüdür; mevzuat
tarafındaki LegislationSelectionDiagnostics'in karşılığıdır. Her
prepare_doctor_legal_information_pack yanıtında ve filter_reasoned_precedents araç
yanıtında precedentDiagnostics olarak görünür.
Tanılama şunları içerir:
query— orijinal soruselectedPrecedentCount/excludedDecisionCountselectedPrecedents[]— mahkeme, daire, tarih, esas/karar numaraları, durum, eşleşen sağlık konuları ve uygunluk gerekçeleriexcludedDecisions[]— mahkeme, tarih, durum ve dışlama gerekçeleri
Tanılama yalnızca seçimi ve dışlamayı özetler. Hukuki yorum sağlamaz ve pakete hiçbir karar eklemez.
Canlı Yargıtay Adaptörü
İlk canlı mahkeme kararı adaptörü: LiveYargitayAdapter
(src/sources/yargitay/liveYargitayAdapter.ts). Danıştay ve AYM mock adaptör olarak kalır.
Kaynak ve uç nokta: https://bedesten.adalet.gov.tr/emsal-karar/searchDocuments adresini
YARGITAYKARARI filtresiyle hedefler. Sağlık hukuku arama terimini içeren JSON POST gövdesi.
429 ve 5xx hataları için adaptif backoff ile üç kez yeniden dener.
sourceMode: "live" emsal davranışı:
search_health_precedentscanlı Yargıtay adaptörünü kullanır; Danıştay ve AYM mock kalır.sourceMode: "live"ileprepare_doctor_legal_information_pack, canlı mevzuata ek olarak canlı Yargıtay kararlarını arar.Sağlık hukuku arama terimleri sınıflandırılmış sorudan eşlenir:
riza/rıza/onam→"aydınlatılmış rıza",tibbi/müdahale→"tıbbi müdahale", vb.verifiedHighCourtPrecedents'e yalnızcaprecedent_usablekararları girer. Diğerlerinin hepsi dışlama gerekçeleriyleprecedentDiagnostics.excludedDecisions'a kaydedilir.
DecisionSourceTrace canlı örneği:
{
"query": "aydınlatılmış rıza",
"source": "yargitay",
"court": "yargitay",
"searchRequest": {
"url": "https://bedesten.adalet.gov.tr/emsal-karar/searchDocuments",
"phrase": "aydınlatılmış rıza",
"pageSize": 5
},
"searchResultsCount": 12,
"selectedResult": { "documentId": "yargitay:99001" },
"selectedResultReason": "Health law term 'aydınlatılmış rıza' matched Yargıtay emsal search.",
"fullTextAvailable": true,
"fullTextRetrievalMethod": "html-text",
"retrievedAt": "2026-05-22T10:00:00.000Z",
"eligibilityStatus": "precedent_usable",
"eligibilityReasons": [
"Tam karar metni mevcut.",
"Hukuki gerekçe alanı dolu.",
"Sağlık hukuku olayıyla bağlantı kurulmuş.",
"Emsal olarak kullanılabilir."
],
"exclusionReasons": []
}Canlı kaynak hatası davranışı: bedesten.adalet.gov.tr erişilemezse veya ayrıştırılamayan
bir yanıt dönerse, adaptör yapılandırılmış bir unavailable sonucu döndürür:
{
"status": "unavailable",
"source": "yargitay.gov.tr",
"errorCode": "source_error",
"message": "Yargıtay request failed: fetch failed",
"retryable": true,
"recommendedNextStep": "Retry after checking network access to bedesten.adalet.gov.tr.",
"sourceTrace": [{ "query": "aydınlatılmış rıza", "searchRequest": { ... } }]
}Hiçbir karar uydurulmaz. Paket, mock Danıştay ve AYM sonuçlarıyla çalışmaya devam eder ve
Yargıtay kaynağı için precedentDiagnostics'te 0 seçilmiş emsal gösterir.
Danıştay ve AYM adaptörleri mock adaptör olarak kalır.
Çok-Kaynaklı Canlı Emsal Boru Hattı
Canlı Danıştay adaptörü, merkezi sağlık hukuku sorgu genişletme modülü, kaynak-başına
tanılama (sourceSummaries) ve dosya-tabanlı sonuç önbelleği.
Canlı Danıştay Adaptörü
LiveDanistayAdapter (src/sources/danistay/liveDanistayAdapter.ts)
https://karararama.danistay.gov.tr/aramalist adresini hedefler. Yargıtay adaptörüyle aynı
yeniden deneme, HTML tam-metin çıkarımı ve uygunluk değerlendirme desenini izler. court
"danistay" olarak ayarlanır ve doküman id'leri danistay: ön ekiyle başlar.
Adaptör, kendi terim haritasını tutmak yerine merkezi sorgu genişletme modülünden
pickHealthLawQuery kullanır.
precedentSources Parametresi
prepare_doctor_legal_information_pack ve search_health_precedents artık canlı modda hangi
mahkemelerin sorgulanacağını seçmek için opsiyonel bir precedentSources dizisi kabul eder:
{
"question": "aydınlatılmış rıza",
"sourceMode": "live",
"precedentSources": ["yargitay", "danistay"]
}Geçerli değerler: "yargitay", "danistay", "aym". Belirtilmezse varsayılan üçü birden.
AYM bir mock adaptör olarak kalır.
Bir kaynak erişilemez olduğunda, diğerleri devam eder. Paket asla tek bir adaptör hatasına takılıp bloke olmaz.
assessmentTone Parametresi (v0.44.0)
prepare_doctor_legal_information_pack ayrıca opsiyonel bir assessmentTone parametresi kabul eder:
{
"question": "hasta hakları nelerdir",
"sourceMode": "mock",
"assessmentTone": "grounded-advisory"
}Değer | Davranış |
| Paket, kaynağa dayalı koşullu cümleler içeren |
| Eski davranış: yalnızca kaynak listeleri döner. Değerlendirme metni üretilmez. |
preliminaryAssessment alanı summary (genel bakış) ve sentences[] (tekil değerlendirme
maddeleri) içerir. Her cümlede text, sourceRef ve sourceLabel bulunur. Cümleler
emsallerden gerçek sonuç/gerekçeyi ve mevzuattan birebir alıntı parçalarını kullanır — asla
kalıp değil. Kararlılık garantileri için COMPATIBILITY.md.
Sağlık Hukuku Sorgu Genişletme
src/health/healthLawQueryExpansion.ts, hem Yargıtay hem Danıştay adaptörleri tarafından
paylaşılan deterministik terim eşlemesi sağlar:
riza/onam/aydinlat→"aydınlatılmış rıza"komplikasyon→"komplikasyon tıbbi müdahale"malpraktis→"malpraktis hekim kusur"hekim→"hekimin özen yükümlülüğü"hasta→"hasta hakları"veri/mahrem→"sağlık verisi mahremiyet"kusur→"hizmet kusuru tıbbi müdahale"acil→"acil müdahale hekim yükümlülüğü"
pickHealthLawQuery, sınıflandırılmış bir soru için en yüksek öncelikli eşlenmiş terimi
döndürür. pickHealthLawQueries, çok-terimli aramalar için en fazla N adet farklı terim döndürür.
precedentDiagnostics içinde sourceSummaries
PrecedentSelectionDiagnostics artık kaynak-başına dökümle sourceSummaries[] içerir:
{
"precedentDiagnostics": {
"query": "aydınlatılmış rıza",
"selectedPrecedentCount": 1,
"excludedDecisionCount": 2,
"sourceSummaries": [
{
"source": "yargitay",
"mode": "live",
"searched": true,
"searchResultsCount": 5,
"candidateCount": 2,
"selectedCount": 1,
"excludedCount": 1,
"unavailableCount": 0,
"errorCodes": []
},
{
"source": "danistay",
"mode": "live",
"searched": false,
"searchResultsCount": null,
"candidateCount": 0,
"selectedCount": 0,
"excludedCount": 0,
"unavailableCount": 1,
"errorCodes": ["source_error"]
}
]
}
}selectedPrecedents[] ve excludedDecisions[] girdileri artık her kararı hangi adaptörün
ürettiğini belirtmek için bir source alanı (court ile aynı değer) da içerir.
Dosya-Tabanlı Önbellek
PrecedentCache (src/sources/precedentCache.ts), canlı adaptör sonuçlarını bir saatlik TTL
ile önbellek dizinindeki precedents/ altına (varsayılan ~/.cache/doktor-mcp/precedents/) önbelleğe alır. Önbellek dosyaları kaynak, sorgu ve sayfa boyutuna
göre anahtarlanır. Önbellek yazma hataları ölümcül değildir.
smoke:precedents üç önbellek bayrağını destekler:
# Önbelleği kullan (varsayılan)
npm run smoke:precedents -- "aydınlatılmış rıza"
# Önbellek okuma ve yazmalarını atla
npm run smoke:precedents -- "aydınlatılmış rıza" --no-cache
# Taze getirmeyi zorla ve önbellek girdisinin üzerine yaz
npm run smoke:precedents -- "aydınlatılmış rıza" --refreshÖnbellek depo dışında tutulur; eski sürümlerin kullandığı .cache/ .gitignore'da durmaya devam ediyor.
Emsal Kaynak Kalibrasyonu
Derin probe analizi ve normalleştirici sağlamlaştırma. Tam kalibrasyon iş akışı için
docs/LIVE_SOURCE_CALIBRATION.md.
Doğrulanmış uç nokta davranışı (2026-05-22)
Kaynak | Durum | Uç nokta |
Yargitay |
|
|
Danistay |
|
|
Bedesten |
|
|
AYM |
| Canlı uç nokta yok. Yalnızca mock adaptör. |
Probe CLI
# HTML/SOAP analizi ve fixture kaydıyla derin probe
npm run probe:precedents -- "aydınlatılmış rıza" -- --source yargitay --save-fixture
npm run probe:precedents -- "hizmet kusuru tıbbi müdahale" -- --source danistay --save-fixtureProbe çıktısı şunları içerir: HTTP durumu, content-type, HTML/SOAP analizi (başlık, form
aksiyonları, uç nokta ipuçları, gövde uzunluğu, captcha/login tespiti), calibrationStatus
ve recommendedNextStep.
JSON-olmayan yanıt sınıflandırması
Bir canlı adaptör JSON-olmayan bir yanıt aldığında, DecisionSourceTrace.error şunu içerir:
Kod | Anlamı |
| HTTP 200 + küçük HTML SPA kabuğu |
| Login/büyük HTML |
| SOAP/XML servis yanıtı |
| CAPTCHA tespit edildi |
| Boş gövde |
Ham fixture politikası
fixtures/raw/gitignore'dadır — ham yanıt gövdelerini asla commit etme.fixtures/live-samples/sanitize edilmiş/sentetik fixture'ları tutar — commit etmek güvenli.Sanitize edilmiş fixture formatı için
fixtures/live-samples/README.md.
Pack audit genişletilmiş kontrolleri
audit:pack artık şunları da kontrol eder:
sourceSummaries'te erişilemez kaynaklar → hata kodlarıyla uyarıDoğrulanmış bir emsalde
decisionSourceTrace.fullTextAvailable === false→ hataDoğrulanmış bir emsalde
decisionSourceTrace.eligibilityStatus !== "precedent_usable"→ hata
Tam kontrol referansı için docs/PACK_AUDIT.md.
Üretim Kurulumu
npm ile kurulum
Node.js 20 ya da üstü gerekir. Paketi kurmadan npx ile çalıştırabilirsiniz. Claude Code'a
eklemek için:
claude mcp add doktor -- npx -y doktor-mcpÖnbellek dosyaları kullanıcının önbellek dizinine yazılır: DOKTOR_MCP_CACHE_DIR verilmişse
oraya, yoksa $XDG_CACHE_HOME/doktor-mcp ya da ~/.cache/doktor-mcp altına.
Kaynak modu
sourceMode varsayılan olarak "live"'dır (0.59.0'dan beri): tool çağrısında sourceMode
belirtilmezse sorgular canlı resmî kaynaklara gider. Fixture (kurgu) verisiyle denemek için
çağrıda sourceMode: "mock" verin ya da DOKTOR_MCP_DEFAULT_SOURCE_MODE=mock ortam
değişkenini ayarlayın; bu durumda yanıta mockDataWarning alanı eklenir.
Örnek: Claude Desktop Yapılandırması
{
"mcpServers": {
"doktor-mcp": {
"command": "npx",
"args": ["-y", "doktor-mcp"]
}
}
}Geçerli Değerler
Değer | Anlamı |
| Fixture (kurgu) verisi döner. Gerçek mevzuat veya karar değildir. |
| Varsayılan. Canlı resmî kaynaklardan sorgular (mevzuat.gov.tr, Yargıtay, Danıştay). |
| Önceden kaydedilmiş canlı kaynak snapshot'ını kullanır. |
Geçersiz bir değer ayarlanırsa (DOKTOR_MCP_DEFAULT_SOURCE_MODE=production gibi),
stderr'ye uyarı yazılır ve varsayılan "live" kullanılır.
Not:
DOKTOR_MCP_DEFAULT_SOURCE_MODE,DOKTOR_MCP_SOURCE_MODE'un daha keşfedilebilir bir karşılığıdır. İkisi desourceMode'u ayarlar; ikisi birden ayarlandığındaDOKTOR_MCP_DEFAULT_SOURCE_MODEson işleme alınır.
Geliştirme
npm install
npm test
npm run build
npm run smoke -- "Aydinlatilmis riza kaydi eksikse hangi resmi kaynaklar eslesir?"
npm run smoke:legislation -- "kisisel saglik verisi mahremiyet"
npm run smoke:legislation -- "aydınlatılmış rıza"
# Hem Yargıtay hem Danıştay smoke (varsayılan)
npm run smoke:precedents -- "aydınlatılmış rıza"
# Belirli kaynaklar
npm run smoke:precedents -- "hizmet kusuru" --precedentSources yargitay,danistay
# Önbellek kontrolü
npm run smoke:precedents -- "aydınlatılmış rıza" --no-cache
npm run smoke:precedents -- "aydınlatılmış rıza" --refresh
npm run smoke:mcp -- "kişisel sağlık verisi mahremiyet" -- --sourceMode live
npm run smoke:mcp -- "hasta haklari tibbi mudahale" -- --sourceMode live
npm run smoke:mcp -- "riza belgesi" -- --sourceMode mock
npm run dev:mcpsmoke:precedents, canlı Yargıtay ve Danıştay adaptörlerini paralel sorgular, sonuçları
önbelleğe alır ve her aday karar için sourceTraces ve eligibilityStatus içeren
kaynak-başına results ile JSON yazdırır. Bir kaynak erişilemezse, onun yapılandırılmış
unavailable sonucu diğer kaynağın çıktısının yanında yazdırılır. JSON ayrıştırılabilirliği
her zaman korunur.
smoke:mcp, tam prepare_doctor_legal_information_pack işleyicisini çağırır.
sourceMode: "live" ile hem canlı mevzuatı hem canlı Yargıtay + Danıştay adaptörlerini
kullanır. Opsiyonel precedentSources parametresi hangi adaptörlerin kullanılacağını seçer.
AYM yalnızca-mock'tur ve canlı modda devre dışıdır.
npm run build sonrası, derlenmiş stdio MCP sunucusunu şununla çalıştırın:
npm run mcpHekim Sorusu Benchmark Paketi
Tipik hekim-merkezli hukuki sorulara odaklanan, canlı-kaynak değerlendirme metrikleri içeren kapsamlı bir kalite değerlendirme ve regresyon-test benchmark paketi.
Amaç
Kalite Ölçümü: 15 ayrı tıbbi-hukuki kategoride 15-20 hedef sorunun performansını, mevzuat eşlemesini, emsal sayısını ve şema uyumunu sistematik olarak değerlendirir.
Regresyon Önleme: Şu gibi katı güvenlik kısıtlarını zorlar:
Kisisel Verilerin Korunmasi Kanunu (KVKK)'nın mahremiyet-dışı paketlerde bulunmaması, ret durumlarında hekim-merkezli deontoloji kurallarının genel hasta-haklarına önceliği, ve canlı modda mock-emsal geri-dönüşü olmaması.
Nasıl Çalıştırılır
Testleri çalıştırmak ve rapor çıktılarını görmek için benchmark runner script'ini kullanın:
# Tam benchmark'ı mock modda çalıştır (varsayılan)
npm run benchmark:doctor-questions
# Canlı modda çalıştır (canlı mevzuat ve emsalleri sorgular, canlı-kaynak metriklerini raporlar)
npm run benchmark:doctor-questions -- --sourceMode live
# Eşdeğer canlı kısayol
npm run benchmark:doctor-questions:live
# Çalıştırmayı ilk N soruyla sınırla
npm run benchmark:doctor-questions -- --limit 5
# Özel bir rapor dizini belirt (varsayılan exports/doctor-benchmark)
npm run benchmark:doctor-questions -- --out exports/my-custom-reportBenchmark'ı--sourceMode live ile çalıştırmak, Cumhurbaşkanlığı Mevzuat (mevzuat.gov.tr) ve yüksek mahkeme servislerine (bedesten.adalet.gov.tr ve karararama.danistay.gov.tr) gerçek HTTP istekleri yapar. Bu sunucuların hız limiti (HTTP 429) veya IP kısıtlamasından kaçınmak için stabil bir internet bağlantınız olduğundan ve istek hacmini makul tuttuğunuzdan emin olun.
Mock vs Canlı Benchmark
Mock mod deterministik bir regresyon koruyucusudur. Beklenen mevzuat, öncelik, audit veya güvenlik invariyantları regresyona uğradığında komutu başarısız kılabilir.
Canlı mod bir değerlendirme çalıştırmasıdır. Aynı güvenlik invariyantlarını korur, ancak
kaynak kesintileri, boş sonuçlar, hız limitleri ve sourceUnavailable girdileri otomatik
başarısızlık yerine metrik ve uyarı olarak raporlanır. Güvensiz emsal kullanımı, yasak MVP
alanları, canlı modda mock geri-dönüşü veya audit hataları sert regresyon başarısızlığı
olarak kalır.
Benchmark Raporları ve Dışa Aktarımlar
Çalıştırmalar exports/doctor-benchmark/'ta (gitignore'da) ayrıştırılabilir JSON ve Markdown
raporları üretir:
Mock mod:
doctor-benchmark-report.jsondoctor-benchmark-report.md
Canlı mod:
live-benchmark-report.jsonlive-benchmark-report.md
Raporlar şunları içerir: startedAt, completedAt, durationMs, passedRegressionCount,
failedRegressionCount, liveSourceUnavailableCount, audit sayıları, mevzuat/emsal kapsama
sayıları ve soru-başına puanlama.
Raporlar, seçilen her doğrulanmış emsal için canlı benchmark kalite audit alanlarını içerir: mahkeme, daire, karar tarihi, esas/karar numaraları, erişim kaynağı, doküman id/kaynak id, varsa kaynak URL'i, tam-metin erişilebilirliği, gerekçe tespiti, uygunluk durumu/gerekçeleri, sağlık-hukuku ilgililik skoru, eşleşen terimler ve karar kaynak izi varlığı. Rapor tam karar metnini yazdırmaz.
Canlı modda mock geri-dönüşü sert bir regresyondur. AYM devre dışı/yalnızca-mock kalır ve
sessizce canlı doğrulanmış emsal sağlayamaz. sourceUnavailable, boş canlı arama sonuçları
ve geçici üst-kaynak hataları; bir güvensiz emsal veya şema/audit ihlaline yol açmadıkça
kalite metriği ve uyarı olarak kalır.
Puanlama
Her soru şunları alır:
legislationMatchScore0 ile 2 arasıpriorityScore0 ile 2 arasıprecedentSafetyScore0 ile 2 arasısourceAvailabilityScore0 ile 2 arasıauditScore0 ile 2 arasıforbiddenFieldsScore0 veya 2totalScore,maxScore,scorePercentvequalityBand
qualityBand: good, acceptable, needs_tuning veya unsafe. Canlı kaynak
erişilemezliği kaliteyi düşürebilir, ama bir maddeyi unsafe yapan yalnızca güvenlik
ihlalleri veya audit hatalarıdır.
Doğrulanmış emsal puanlaması bilinçli olarak katıdır. Seçilen bir doğrulanmış emsal
precedent_usable olmalı, doğrulanmış tam metne, tespit edilmiş hukuki gerekçeye sahip
olmalı ve bir karar kaynak izini korumalıdır. Yalnızca-meta veri, yalnızca-usuli,
gerekçesiz, tam-metni-yok veya mock-erişim kayıtları canlı modda doğrulanmış emsal kredisi
alamaz. Zayıf sağlık-hukuku ilgililiği, emsal güvenlik kredisini sınırlar ve yüksek bir
toplam skorun arkasına gizlenmek yerine bir tuning uyarısı olarak raporlanır.
Benchmark, bu audit katmanının üzerine emsal ilgililik tuning'i içerir. Soru ve kaynağa göre
zayıf ilgililiği, örnek karar id'lerini, eşleşen konu terimlerini, eksik beklenen konu
terimlerini, bir whyWeak açıklamasını ve önerilen takip sorgu terimlerini raporlar. Ayrıca
goodCleanCount'ı goodWithWarningsCount'tan ayırır ve ortalama/medyan sağlık-hukuku
ilgililik skorlarını raporlar.
Zayıf ilgililik, kararın sert emsal güvenlik kapılarını geçtiği ama karar metninin yalnızca
geniş sağlık kelimeleriyle eşleştiği veya sorunun konu profiliyle güçlü örtüşmediği anlamına
gelir. Konu profilleri şunları içerir: aydınlatılmış onam, malpraktis/komplikasyon, acil
bakım, tedavi reddi, mahremiyet/kayıtlar, psikiyatrik mahremiyet, şiddet/tehdit, sevk, özel
hastane ücret uyuşmazlıkları, kamu disiplini, yoğun bakım ve gebelik acili. Canlı kaynak
erişilemezliği bir metrik/uyarı olarak kalır; unsafe ise mock geri-dönüşü, eksik tam
metin/gerekçe/iz veya kullanılamaz emsal durumlarının doğrulanmış çıktıya sızması gibi
güvenlik ihlalleri için ayrılmıştır.
Performans Benchmark Komutu
npm run benchmark:doctor-questions:performance
# veya limitle:
npm run benchmark:doctor-questions:performance -- --limit 5Benchmark, 15 hekim sorusunun tamamını iki kez çalıştırır. Soğuk (cold) çalıştırma canlı ağa
gider ve yerel dosya önbelleğini (.cache/precedents-perf/) doldurur. Sıcak (warm)
çalıştırma aynı sorguları hemen önbellekten yeniden oynatır. Rapor şunları gösterir:
Soğuk vs sıcak toplam süre ve iyileşme %
Kaynak-başına soğuk/sıcak ortalama ms, p95, önbellek isabetleri, ağ istekleri
Önbellek etkinliği: isabet oranı %, önbellekten-sunulan sayısı, ortalama önbellek yaşı
Yeniden deneme/backoff özeti: toplam yeniden deneme, backoff süresi, hız-limiti olayları, timeout sayısı
En yavaş 10 sorgu denemesi (soğuk + sıcak birleşik)
Performans uyarıları (bloke etmez; sert başarısızlıklar test/build/audit olarak kalır)
p50/p95/p99 Yorumlama
Değer | Anlamı |
p50 | Medyan sorgu süresi — sorguların yarısı bu sürede veya daha kısa sürede tamamlanır |
p95 | 95. yüzdelik — kuyruk gecikmesi; çoğu sorgu bundan hızlıdır |
p99 | 99. yüzdelik — aykırı gecikme; ara sıra yavaş sorgular |
Soğuk p95 > 60s yavaş bir kaynağa işaret eder (genellikle Yargıtay/Bedesten PDF getirme). Sıcak p95 > 10s, en yavaş sorgular için önbelleğin etkili olmadığını gösterir (olası TTL süre dolması veya adaptör içindeki tam-metin getirmeler için önbellek ıskası).
Önbellek Entegrasyonu
Önbellek normal canlı benchmark ve smoke CLI çalıştırmalarında varsayılan olarak devre
dışıdır. Performans benchmark'ı için paylaşılan bir PrecedentCache (TTL 2s, dizin
.cache/precedents-perf/) enjekte edilir. Önbellek, (source, query, pageSize) anahtarı
başına tüm searchAndNormalize sonucunu saklar. Sıcak çalıştırma yeniden oynatması
eksiksizdir — önbelleğe alınmış sorgular için hiç ağ çağrısı yapılmaz.
.cache/ gitignore'dadır. Önbellek girdileri commit edilmez.
Sürüm geçmişi için bkz. CHANGELOG.md.
Lisans
GNU Affero Genel Kamu Lisansı sürüm 3 ile lisanslanmıştır (AGPL-3.0-only); tam
metin LICENSE dosyasındadır. Yazılımı değiştirip ağ üzerinden başkalarına
hizmet olarak sunarsanız, değiştirdiğiniz kaynak kodu da o kullanıcılara aynı lisansla
sunmanız gerekir. Güvenlik açıklarının nasıl bildirileceği SECURITY.md
dosyasında anlatılıyor.
Telif hakkı © 2026 Alpaslan Fatih Sözer
Available Tools
8 toolsclassify_medical_legal_questionA
Advanced/granular tool: prefer prepare_doctor_legal_information_pack for end-to-end questions; use this only when you specifically need medical-legal question classification in isolation. Classifies a physician question into legal dimensions (patient_rights, professional_ethics, criminal, privacy_kvkk, civil_compensation, etc.) and extracts search terms. Example: { "question": "Hasta onami olmadan mudahale edilirse ne olur?" }
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| sourceMode | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool classifies into legal dimensions and extracts search terms, which is useful output behavior, but it does not explain sourceMode (mock/live/snapshot), whether live mode makes external calls, or whether the operation has side effects.
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 front-loaded with the usage preference, then states purpose, then gives a compact example. Every sentence contributes, though the example is somewhat optional because the schema already defines the question field.
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 has no output schema and no annotations, so the description does most of the contextual work. It adequately describes the classification output categories, but it omits any explanation of sourceMode behavior, which is important for an enum that includes live external execution.
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 conveys that 'question' is a physician question and gives an example, but it says nothing about the sourceMode parameter or its mock/live/snapshot enum, leaving one of two parameters entirely unexplained.
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 and resource: it classifies a physician question into legal dimensions and extracts search terms. It also lists concrete output categories (patient_rights, professional_ethics, criminal, privacy_kvkk, civil_compensation) and explicitly distinguishes itself from prepare_doctor_legal_information_pack.
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 gives explicit routing guidance: prefer prepare_doctor_legal_information_pack for end-to-end questions and use this tool only when medical-legal classification is specifically needed in isolation. That is exactly the when/when-not/alternative structure an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
drill_down_pack_itemA
Follow-up tool — call ONLY after prepare_doctor_legal_information_pack. Pass the packId from that response plus a follow-up question mentioning a specific article number, law name, chamber, or decision number to retrieve just that item without rebuilding the pack. Example: { "packId": "pack-3f9a2c", "followUpQuestion": "madde 24 ne diyor?" }
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | ||
| packId | No | ||
| followUpQuestion | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the prerequisite state dependency and that it retrieves just one item without rebuilding the pack, which is useful, but it does not describe return format, failure behavior for invalid packId or unmatched items, or whether the pack is consumed or remains available.
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 front-loaded with the critical prerequisite and purpose, then gives the required inputs and a concrete example. Every sentence adds actionable information, and the example clarifies the expected call shape without unnecessary length.
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 description covers the prerequisite and the two main invocation inputs, which is enough to make a basic call. However, the tool has a nested `pack` parameter and no output schema, and the description neither explains the pack object nor describes what the retrieval returns, leaving gaps for an unfamiliar agent.
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 explain all three parameters. It explains packId and followUpQuestion well, including an example, but it never mentions the nested `pack` object even though the schema includes it with relevantLegislation and verifiedHighCourtPrecedents fields. That leaves a complex parameter 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?
The description states a specific verb and resource: follow-up retrieval of a single item from an existing legal information pack without rebuilding it. It clearly distinguishes this from prepare_doctor_legal_information_pack by requiring that sibling as a prerequisite, so an agent can tell which tool to use.
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 gives explicit when-to-use guidance: call ONLY after prepare_doctor_legal_information_pack, and pass the packId from that response. It also specifies what the follow-up question should mention, such as article number, law name, chamber, or decision number, which is enough routing guidance for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
filter_reasoned_precedentsA
Advanced/granular tool: prefer prepare_doctor_legal_information_pack for end-to-end questions; use this only when you specifically need to filter/classify court decisions for reasoned analysis. Takes a list of decisions and filters them by eligibility (full text, legal reasoning, relevance). Optionally accepts a packId to operate on a previously prepared pack's decisions. Example: { "decisions": [...], "query": "hekim ihmal" }
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| packId | No | ||
| decisions | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clarifies that this is a filtering/classification operation rather than an end-to-end pack builder and identifies eligibility criteria, but it does not state whether the operation is read-only, whether it mutates a pack, what happens when both decisions and packId are supplied, or what the result shape is.
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 compact and front-loaded: it leads with the preferred sibling and the condition for using this tool, then explains the inputs. The example adds useful clarification without bloat.
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 definition gives enough context to select the tool and understand its basic filtering role, but for a complex tool with no annotations, no output schema, and 0% schema description coverage, it leaves important invocation details unstated, such as return behavior and the interaction between decisions and packId.
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 explains that decisions is a list of decisions to filter and that packId refers to a previously prepared pack, and the example shows query as a search string, but it does not clarify query semantics, precedence between decisions and packId, or the nested decision eligibility fields.
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 and resource: it filters/classifies court decisions for reasoned analysis, filtering by eligibility criteria such as full text, legal reasoning, and relevance. It also distinguishes this advanced/granular tool from the higher-level sibling prepare_doctor_legal_information_pack.
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 explicitly says to prefer prepare_doctor_legal_information_pack for end-to-end questions and to use this tool only when the agent specifically needs filtering/classification of decisions. It also explains the optional packId path for operating on previously prepared packs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_decision_full_textA
Fetch the full verbatim text of a single court decision by its documentId (from search_health_precedents or a pack's verifiedHighCourtPrecedents). Use for deep-dive into one decision instead of re-running the whole pack. Example: { "documentId": "yargitay:99001", "sourceMode": "live" }
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | ||
| sourceMode | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; "verbatim text" implies a read, but nothing states that it is non-mutating, whether the call can be slow or rate-limited in live mode, or what happens when the documentId is unknown. The embedded example at least shows the sourceMode value in use, which is more than nothing.
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?
Three short sentences: purpose first, routing second, concrete example last. Given the zero schema coverage, the example payload earns its place by showing shape and an enum value in a single line; nothing is redundant.
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 two-param, no-annotation, no-output-schema tool, the definition covers purpose, ID provenance, and an example. It omits what the returned "full text" looks like (size, format, truncation), the sourceMode semantics, and failure behavior for a bad documentId — gaps an agent will hit on first call.
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 0%, so the description must compensate. It does well on documentId (origin from search_health_precedents or verifiedHighCourtPrecedents), but sourceMode appears only as the literal "live" in the example — the meaning and consequences of mock/live/snapshot are never explained, leaving half the 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 ("Fetch the full verbatim text of a single court decision") and pins the key ("by its documentId"), which is exactly what distinguishes it from the search/filter siblings. It also tells the agent where documentIds come from, so the tool is unambiguous at selection time.
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?
Explicitly scopes usage: "Use for deep-dive into one decision instead of re-running the whole pack," which is a real when-to-use plus a when-not-to-use (don't re-run the pack). It stops short of naming the other candidates (drill_down_pack_item, filter_reasoned_precedents) that could also serve a deep-dive, so the routing is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_legislation_provisionsA
Advanced/granular tool: prefer prepare_doctor_legal_information_pack for end-to-end questions; use this only when you specifically need legislation provisions by document ID in isolation. Fetches full text of legislation provisions by document IDs. Example: { "documentIds": ["mevzuat:hastahaklari-yonetmelik:madde-5"], "sourceMode": "mock" }
| Name | Required | Description | Default |
|---|---|---|---|
| sourceMode | No | ||
| documentIds | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It communicates that this is a read/fetch operation returning full text, but it does not explain sourceMode behavior, error handling, or output shape. For a simple read tool this is minimally adequate, but clear gaps remain.
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 routing advice is front-loaded, followed by the core operation and a concrete example. Every sentence adds value, and nothing is padded.
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 two-parameter read tool with no annotations, no output schema, and zero schema description coverage, the description is mostly sufficient but leaves sourceMode semantics unexplained. An agent can call it correctly for documentIds but may not understand the sourceMode enum.
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 explains documentIds through prose and an example document ID, but sourceMode is only shown as 'mock' in the example; the enum values mock/live/snapshot and their effects are not explained.
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 and resource: 'Fetches full text of legislation provisions by document IDs.' It also explicitly distinguishes this tool from the sibling prepare_doctor_legal_information_pack by positioning it as the granular, document-ID-isolated alternative.
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 gives explicit routing guidance: prefer prepare_doctor_legal_information_pack for end-to-end questions, and use this only when legislation provisions are needed by document ID in isolation. This names both the preferred alternative and the condition for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_doctor_legal_information_packA
PRIMARY ENTRY POINT — use this tool first for any physician legal question. Prepares a complete source-grounded legal information pack: classification, verbatim legislation provisions, verified high-court precedents, missing information, and lawyer review points. Returns a packId for follow-up drill-down. Set sourceMode:'live' to query official sources (mevzuat.gov.tr, Yargitay, Danistay); this is the default mode; sourceMode='mock' returns clearly-marked fixture data for testing only. Example: { "question": "Hasta tedaviyi reddederse hekimin sorumluluğu nedir?", "sourceMode": "live" }
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| sourceMode | No | ||
| assessmentTone | No | grounded-advisory | |
| precedentSources | No | ||
| includeDiagnostics | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that live mode queries official sources by name (mevzuat.gov.tr, Yargitay, Danistay), that mock returns "clearly-marked fixture data for testing only," and that a packId is returned. It omits latency, failure behavior, and whether the external queries incur cost or rate limits.
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 critical routing cue ("PRIMARY ENTRY POINT") is front-loaded and the sentence order follows the agent's decision flow. It is dense and slightly run-on, but nearly every clause adds real information, and the worked example aids invocation.
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 multi-source orchestration tool with no annotations and no output schema, the description does well to enumerate the returned pack contents and the packId. However, three undocumented parameters and no note on behavior when live sources fail leave gaps an agent would need filled.
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 only partly does. It explains sourceMode well (live/mock) and the question parameter via example, but assessmentTone, precedentSources, and includeDiagnostics are never mentioned — three of five parameters left fully 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?
The description names a specific verb and resource ("Prepares a complete source-grounded legal information pack") and enumerates exactly what the pack contains: classification, verbatim legislation, verified high-court precedents, missing information, and lawyer review points. It also declares itself the "PRIMARY ENTRY POINT" that returns a packId, cleanly distinguishing it from the drill-down 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?
It gives explicit routing guidance ("use this tool first for any physician legal question") and explains the sourceMode branch — live by default, mock for testing only. It does not name the sibling tools or state when to skip it in favor of them, leaving that to inference, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_health_legislationA
Advanced/granular tool: prefer prepare_doctor_legal_information_pack for end-to-end questions; use this only when you specifically need legislation search in isolation. Searches health-related legislation by keywords. Returns legislation titles, document IDs, and matched provisions. Example: { "searchTerms": ["hasta haklari", "tedaviyi red"], "sourceMode": "mock" }
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| sourceMode | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It does disclose the return fields and hints at a mode switch, but never explains what mock/live/snapshot actually mean, whether results are ranked or truncated, or any auth/rate constraints. Read-only nature is inferable from "search" but never stated.
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?
Front-loads the selection guidance, then purpose, then return shape, then an example — a sensible order with little filler. The example itself is misleading, but the prose 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?
No output schema, and the description partly compensates by naming returned fields. However, the wrong parameter name in the example and the unexplained sourceMode values leave real gaps for a tool whose schema documents nothing.
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 0%, so the description must carry parameter meaning, and it partly fails: the example passes "searchTerms", a parameter that does not exist in the schema (the schema has "question"). sourceMode appears in the example but its three enum values are never explained.
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?
Specific verb+resource ("Searches health-related legislation by keywords") plus the return shape (titles, document IDs, matched provisions). It also explicitly separates itself from prepare_doctor_legal_information_pack, so an agent can choose between the two without opening schemas.
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?
Explicit routing: prefer the sibling pack tool for end-to-end questions, use this one only when legislation search is needed in isolation. Both the when-to-use and the alternative are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_health_precedentsA
Advanced/granular tool: prefer prepare_doctor_legal_information_pack for end-to-end questions; use this only when you specifically need court precedent search in isolation. Searches health-related court decisions from Yargitay and Danistay. Returns decision summaries, document IDs, and relevance scores. Example: { "searchTerms": ["hekim sorumlulugu", "tedaviyi red"], "sourceMode": "mock" }
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| sourceMode | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses the sources and return shape (decision summaries, document IDs, relevance scores), but it does not explain sourceMode semantics or any access/limitation considerations, so meaningful gaps remain.
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 compact and front-loads the usage preference before describing the search and return values. The example is concise, though its parameter mismatch is a semantic issue rather than a conciseness problem.
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 simple two-parameter search tool, the description gives strong routing and return-value information. However, it omits explanation of the required input parameter and the sourceMode enum, and the example conflicts with the schema, leaving invocation details incomplete.
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 explain parameters, but it does not explain the required 'question' parameter. Worse, the example uses 'searchTerms', which is not a schema parameter, creating a direct mismatch that could mislead invocation.
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 clearly states a specific verb and resource: searching health-related court decisions from Yargitay and Danistay. It also distinguishes itself from the sibling tool prepare_doctor_legal_information_pack by positioning itself as the isolated precedent-search tool.
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 gives explicit routing guidance: prefer prepare_doctor_legal_information_pack for end-to-end questions, and use this tool only when court precedent search is specifically needed in isolation. This is exactly the when/when-not/alternative guidance needed.
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.
8 tool updates
v0.59.2- First observed
classify_medical_legal_question - First observed
drill_down_pack_item - First observed
filter_reasoned_precedents - First observed
get_decision_full_text - First observed
get_legislation_provisions - First observed
prepare_doctor_legal_information_pack - First observed
search_health_legislation - First observed
search_health_precedents
TDQS
Scored across 8 tools
Most tools have clearly distinct resource/action targets: pack preparation, pack drill-down, decision full-text retrieval, legislation search/fetch, and precedent search/filter/classification. The only mild ambiguity is that several granular tools are explicitly subsumed by prepare_doctor_legal_information_pack, so an agent may occasionally wonder whether to use the umbrella tool or an isolated component.
All tool names use consistent snake_case and follow a predictable verb_noun or verb_object pattern. The naming is verbose but uniform across the set.
Eight tools is well-scoped for a domain-specific legal information server. Each tool corresponds to a meaningful operation or drill-down path, with no apparent padding.
The surface covers the full workflow: question classification, legislation search and provision retrieval, precedent search and filtering, full decision retrieval, pack assembly, and follow-up drill-down. No obvious lifecycle gaps are present for the stated physician legal information purpose.
Maintenance
Related MCP Connectors
Resolve, search and verify legal citations against the official sources, with provenance.
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Grounded MENA legal search, reasoning, citation resolution, and citation-graph traversal.
Current law as data for AI: search, read and verify statutes and citations. CIS countries first.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to search and analyze legal documents from multiple jurisdictions including US federal and state law, case law, EU regulations, UK legislation, Canadian law, Congress bills, SEC filings, and FDA data through free government APIs.6MIT
- AlicenseNot gradedqualityBmaintenanceProvides AI assistants with up-to-date legal documents from official sources, enabling accurate legal information retrieval and analysis.20AGPL 3.0
- FlicenseBqualityBmaintenanceEnables legal analysis and decision preparation for French territorial authorities by providing 14 tools to search official legal sources, check citations, compare document versions, and control evidence for tracing proof.14-
- AlicenseNot gradedqualityBmaintenanceEnables Brazilian legal practitioners to search and verify case law, súmulas, and federal legislation against official sources, and to audit entire draft documents citation by citation with source provenance, collection dates, and verification status. Every response carries its own verification flag so a failed source lookup never silently becomes "no results", and citations blocked by anti-bot protections are returned as pending manual review with an official search link.MIT