Skip to main content
Glama

Doktor MCP

Beta sürüm — Güncel sürüm için package.json ve CHANGELOG.md dosyalarına bakın.

DOI

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)

  • yargitay

  • danistay

  • aym

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-After işleme, üstel geri-çekilme (backoff), titreşim (jitter) ve istek telemetrisi içeren paylaşılan bir HttpClient ve RateLimiter yolu 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ış unavailable sonuç 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: LiveOfficialLegislationAdapter

  • resmî kaynak: T.C. Cumhurbaşkanlığı Mevzuat Bilgi Sistemi — mevzuat.gov.tr

  • arama yeteneği: resmî MevzuatDatatable arama isteği ayrıştırıcısı

  • tam-metin yeteneği: resmî MevzuatMetin doküman getirme

  • mevcut çı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 sourceMode yönlendirmesi

  • sağ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 mevcut

  • limited_value: tam metin var ama ilgililik zayıf

  • procedural_only: esasa ilişkin gerekçe yok; usuli metin, salt onama veya salt bozma

  • metadata_only: tam metin olmadan künye meta verisi

  • no_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:

dataOrigin

Anlamı

"mock"

Yanıt fixture (kurgu) verisi içerir. Gerçek mevzuat veya karar değildir.

"live"

Yanıt canlı kaynaklardan (mevzuat.gov.tr, Bedesten, Danıştay) gelmiştir.

"snapshot"

Yanıt önceden kaydedilmiş canlı kaynak snapshot'ıdır.

"computed"

Yanıt yalnızca hesaplama sonucudur (sınflandırıcı gibi). Kaynak veri içermez.

"client-provided"

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:

  1. shortAnswer

  2. legalClassification

    • criminal

    • civilCompensation

    • disciplinaryAdministrative

    • patientRights

    • privacyKvkk

    • professionalEthics

  3. relevantLegislation

    • mevzuat adı

    • madde numarası

    • kaynak hükümden birebir kopyalanmış alıntı

    • olay bağlantısı

  4. verifiedHighCourtPrecedents

    • mahkeme/daire, tarih, esas/karar numaraları

    • olay özeti, hukuki değerlendirme, sonuç

    • benzerlik/farklılık notu

  5. missingInformation

  6. lawyerReviewPoints

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_only iş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"). strict modda yalnızca kaynak listeleri döner (değerlendirme yok). grounded-advisory modda, kaynağa dayalı koşullu değerlendirme içeren bir preliminaryAssessment eklenir.

  • preliminaryAssessment: summary ve sentences[] içeren opsiyonel yanıt alanı. 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 (boilerplate) değil.

  • Mevzuat yürürlük meta verisi: Hükümler inForce, lastAmendedDate ve repealed alanları 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_question

  • search_health_legislation

  • get_legislation_provisions

  • search_health_precedents

  • filter_reasoned_precedents

  • prepare_doctor_legal_information_pack

  • drill_down_pack_item — Takip sorusu: packId ile 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 query

  • matchedHealthMapping ve eşleme olmadığında denenen eşleme adayları

  • officialSearchRequest, resmî arama sonuç sayısı ve kompakt resmî sonuçlar

  • selectedSearchResult ve selectedResultReason

  • landing/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 sourceMode

  • seç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ğı

  • unavailable ve 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 query

  • source ve court (yargitay / danistay / aym)

  • searchRequest (mock adaptörler için null)

  • searchResultsCount ve selectedResult

  • documentId / sourceId

  • fullTextAvailable ve fullTextRetrievalMethod

  • retrievedAt

  • eligibilityStatus — emsal filtresi sonucu

  • eligibilityReasons — kararın karşıladığı olumlu kriterler

  • exclusionReasons — varsa, dışlanmasının belirli neden(ler)i

  • getirme 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)

  • legalReasoning boş 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 onama veya bozma (→ procedural_only)

  • Kararı sağlık-hukuku olayına bağlayan relevanceNote yok (→ 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 soru

  • selectedPrecedentCount / excludedDecisionCount

  • selectedPrecedents[] — mahkeme, daire, tarih, esas/karar numaraları, durum, eşleşen sağlık konuları ve uygunluk gerekçeleri

  • excludedDecisions[] — 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_precedents canlı Yargıtay adaptörünü kullanır; Danıştay ve AYM mock kalır.

  • sourceMode: "live" ile prepare_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ızca precedent_usable kararları girer. Diğerlerinin hepsi dışlama gerekçeleriyle precedentDiagnostics.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ış

"grounded-advisory" (varsayılan)

Paket, kaynağa dayalı koşullu cümleler içeren preliminaryAssessment'i içerir. Her cümle bir sourceRef taşır.

"strict"

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

reachable_json

bedesten.adalet.gov.tr/emsal-karar/searchDocuments - Bedesten proxy üzerinden aktif entegrasyon.

Danistay

reachable_json

karararama.danistay.gov.tr/aramalist - aktif entegrasyon.

Bedesten

reachable_json

bedesten.adalet.gov.tr/emsal-karar/searchDocuments - aktif birleşik entegrasyon.

AYM

synthetic_only

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-fixture

Probe çı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ı

non_json_response:html_shell_response

HTTP 200 + küçük HTML SPA kabuğu

non_json_response:unexpected_html_response

Login/büyük HTML

non_json_response:xml_soap_response

SOAP/XML servis yanıtı

non_json_response:captcha_or_block

CAPTCHA tespit edildi

non_json_response:empty_response

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 → hata

  • Doğ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ı

"mock"

Fixture (kurgu) verisi döner. Gerçek mevzuat veya karar değildir.

"live"

Varsayılan. Canlı resmî kaynaklardan sorgular (mevzuat.gov.tr, Yargıtay, Danıştay).

"snapshot"

Ö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 de sourceMode'u ayarlar; ikisi birden ayarlandığında DOKTOR_MCP_DEFAULT_SOURCE_MODE son 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:mcp

smoke: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 mcp

Hekim 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-report
WARNING

Benchmark'ı--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.json

    • doctor-benchmark-report.md

  • Canlı mod:

    • live-benchmark-report.json

    • live-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:

  • legislationMatchScore 0 ile 2 arası

  • priorityScore 0 ile 2 arası

  • precedentSafetyScore 0 ile 2 arası

  • sourceAvailabilityScore 0 ile 2 arası

  • auditScore 0 ile 2 arası

  • forbiddenFieldsScore 0 veya 2

  • totalScore, maxScore, scorePercent ve qualityBand

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 5

Benchmark, 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 tools
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?" }

NameRequiredDescriptionDefault
packNo
packIdNo
followUpQuestionYes

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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" }

NameRequiredDescriptionDefault
queryNo
packIdNo
decisionsNo

TDQS

A4.1/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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" }

NameRequiredDescriptionDefault
documentIdYes
sourceModeNo

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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" }

NameRequiredDescriptionDefault
sourceModeNo
documentIdsYes

TDQS

A4.1/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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" }

NameRequiredDescriptionDefault
questionYes
sourceModeNo

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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" }

NameRequiredDescriptionDefault
questionYes
sourceModeNo

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

  1. 8 tool updatesv0.59.2
    • First observedclassify_medical_legal_question
    • First observeddrill_down_pack_item
    • First observedfilter_reasoned_precedents
    • First observedget_decision_full_text
    • First observedget_legislation_provisions
    • First observedprepare_doctor_legal_information_pack
    • First observedsearch_health_legislation
    • First observedsearch_health_precedents

TDQS

A4.2/5.0

Scored across 8 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables 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.
    6
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides AI assistants with up-to-date legal documents from official sources, enabling accurate legal information retrieval and analysis.
    20
    AGPL 3.0
  • F
    license
    B
    quality
    B
    maintenance
    Enables 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
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables 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