Skip to main content
Glama

search_decisions

Search live Turkish court decisions, case law, and legislation from official sources like Bedesten, AYM, and Danıştay.

Instructions

✅ PRIMARY, MANDATORY TOOL FOR ALL CASE-LAW / DECISION / MEVZUAT RESEARCH.

For ANY question about court decisions, precedents, case law, or legislation you MUST call THIS tool first. It is the ONLY tool that retrieves real, current documents LIVE from the official source (online — e.g. Bedesten/Yargıtay, Mevzuat).

HARD RULES — no exceptions, no interpretation:

  • Do NOT answer case-law questions from memory, training data, or web search.

  • Do NOT use search_local_corpus to FIND decisions — it searches ONLY the local corpus and cannot discover anything not fetched here first.

  • Every esas/karar number, date, and chamber you cite MUST come from a document returned by THIS tool and verified via get_document full text.

  • If you have not called this tool yet, you have NO case law to cite.

--- QUERY HYGIENE (CRITICAL) ---

  • Do NOT paste the user's question in. Solr matches tokens, not natural language. Reduce it to 2–5 legal keywords: "işçi alacağı zamanaşımı" ✓, not "işçinin fazla mesai ve kıdem tazminatı konusunda zamanaşımı süresi".

  • Preserve Turkish diacritics exactly; stripping them silently drops matches. "kararı" ✓ not "karari" ✗.

--- BEDESTEN SOLR OPERATOR COOKBOOK --- ⚠️ THE DEFAULT OPERATOR IS OR — whitespace between bare terms means UNION. tahliye taahhüdü geçerlilik matches ANY of the three words. To require all, prefix each with + or join with UPPERCASE AND.

+required must appear (+tazminat) -excluded must not (-bölge) "exact" phrase ("iş kazası") AND/OR/NOT UPPERCASE only (grouping) sub-expressions

⚠️ CHARACTER WHITELIST (measured live): Bedesten accepts ONLY letters, digits, spaces and the operators above. Wildcards (* ?), fuzzy (~), boost (^) and ANY punctuation (/ . , ' : ; _ …) are rejected outright with INVALID_QUERY — there is NO wildcard search, write the full word. Article numbers: "83 a" not 83/a (the index stores 83/a as the two tokens 83 and a). The tool strips/converts such characters before sending (83/a → "83 a", maaş. → maaş) and reports it in warnings + query_sanitized; write them clean to avoid surprises.

⚠️ THE INDEX IS NOT STEMMED — each inflected form is its own token: +taahhüdü ≈ 16 700 hits vs +taahhüt ≈ 43 800. Prefer noun stems or quoted phrases, and keep the diacritics (+taahhut ≈ 10 hits).

TWO-PASS BEHAVIOUR: A plain multi-word query with NO operators is first tried with every term required (+t1 +t2 ...). If that pass cannot fill limit — normal for 3+ inflected terms on an unstemmed index — the ORIGINAL query re-runs as OR. Nothing is lost (OR is a superset, and Solr ranks multi-term matches higher). Reported in warnings and as fallback_to_or, so a starved AND pass never looks like "no precedent".

Worked examples (query string → what it does): +işçi +tazminat → BOTH "işçi" AND "tazminat" +"iş kazası" +tazminat → phrase "iş kazası" AND "tazminat" (+işçi OR +memur) +tazminat -manevi → (işçi OR memur) AND tazminat, not "manevi"

⚠️ Quote each concept rather than listing bare inflected words: +"tahliye taahhüdü" +"adli tatil" ✓. A +-joined query returning 0 is a real finding about the phrasing — retry broader or with the stem, not with more terms.

Notes:

  • A single common term ("karar") returns noise; add a specific constraint.

  • At least ONE criterion is required (query, esas_no, karar_no, birimAdi, or a date range). court_types alone is rejected — it is a filter.

Args: source: Optional source identifier. Available sources: - 'bedesten' (default) — combined Yargıtay + Danıştay sweep - 'resmigazete' — Resmî Gazete. With query and NO single day (no date, or a karar_tarihi_start / karar_tarihi_end range) it searches the local TITLE index (2000-06-27 →, titles only, not full text; accent-insensitive, prefix match, "quoted phrase" ok) across all issues, paginated; sort_by='date' = newest first. Only karar_tarihi_start = start..today. One issue: give start==end, or no query and only start (default today) to list/filter that day live. Index missing → single-day fallback + warning. Ids: 20260731-1, mükerrer 20230309m1-1. - 'aym' — Anayasa Mahkemesi (bireysel başvuru + norm denetimi kararları, tam metin) - 'aihm' — AİHM/ECHR via HUDOC (EXPERIMENTAL ama arama ve get_document CANLI çalışır; Türkiye aleyhine kararlar). Varsayılan olarak Türkçe çeviriler (dil='TUR') döner; Türkçe yoksa ENG/FRE'ye düşer ve warnings'e yazar. karar_tarihi_start/_end HUDOC kpdate alanına bağlanır. Kısa anahtar kelime/dava adı yazın (ör. "Kavala"). - 'btk' — BTK Kurul Kararları (PARTIAL; HTML card scraping with PDF download for full text) query: Search query string (optional when filtering by docket no / chamber / date). For best results, craft a short 2–5 term keyword query using the operators above. limit: Max results (default 10, must be positive). page: Page number for pagination (default 1). court_types: Optional list of court item types for multi-court search in a single call. Bedesten values (exact spelling — verified live): YARGITAYKARARI (Yargıtay), DANISTAYKARAR (Danıştay, no trailing I), YERELHUKUK (yerel hukuk mahkemeleri), ISTINAFHUKUK (bölge adliye hukuk daireleri), KYB (kanun yararına bozma). Defaults to ["YARGITAYKARARI", "DANISTAYKARAR"] when source=bedesten and omitted. An unrecognised value is rejected with INVALID_COURT_TYPE — Bedesten answers a bogus itemType with a silent total=0 that is indistinguishable from "no such precedent", so we never forward one. birimAdi: Optional chamber code. Yargıtay H1–H23 / C1–C23 (hukuk / ceza daireleri), HGK, CGK, BGK; Danıştay D1–D17, IDDK, VDDK; AYIM. Full list: list_sources(detail="birim_codes"). karar_tarihi_start: Optional ISO start date, inclusive (e.g. "2023-01-01"). karar_tarihi_end: Optional ISO end date, inclusive (e.g. "2024-12-31"). esas_no: Optional case file number, YIL/SIRA ("2023/1234"). karar_no: Optional decision number, YIL/SIRA ("2023/5678"). sort_by: Result ordering — "relevance" (Solr score, default when a query/phrase is present) or "date" (newest first, default when only filters like esas_no/karar_no/date range are given). When omitted, the source infers: non-empty query → relevance, filter-only lookup → date. include_snippets: When true, fetch the full text of the first 5 results and attach a snippet (~360-char passage centred on the query terms) to each. Lets you triage relevance without calling get_document per result. Results already in the local corpus get a snippet for free even when this is false. dil: Yalnızca source='aihm': belge dili. Verilmezse önce Türkçe çeviriler ('TUR'), sonuç yoksa ENG/FRE. 'ENG', 'FRE', 'TUR', virgülle çoklu ('ENG,FRE') ya da 'HEPSI' (tüm diller; Almanca, Rumence vb. üçüncü dil çevirileri dahil). include_raw: When true, keep the raw upstream metadata block. Default false: fields duplicated by the flat keys (esas_no, karar_no, decision_date, chamber, ...) are dropped to save context. Nothing unique is lost.

Returns: Dict with results, pagination metadata, and optional warnings. The results key holds the list of matching document dicts. total_results (int or null) is the total count across pages, page (int) the current page, and total_pages (int or null) the total number of pages. When the source cannot provide a total (e.g. Mevzuat search), total_results and total_pages are null and a warning is appended. Example::

    {
      "results": [ /* SearchResult dicts */ ],
      "total_results": 543,
      "page": 1,
      "total_pages": 55
    }

Input Schema

NameRequiredDescriptionDefault
dilNo
pageNo
limitNo
queryNo
sourceNo
esas_noNo
sort_byNo
birimAdiNo
karar_noNo
court_typesNo
include_rawNo
include_snippetsNo
karar_tarihi_endNo
karar_tarihi_startNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: two-pass AND→OR fallback reported via warnings/fallback_to_or, character whitelist and query sanitization, INVALID_COURT_TYPE rejection to avoid indistinguishable silent zero-results, unstemmed-index token behavior, and the AİHM TUR→ENG/FRE language fallback. This is unusually rich operational disclosure.

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

Conciseness3/5

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

The purpose and rules are front-loaded and organized under headers, which helps with 14 parameters. However the prose is bloated with dramatized emphasis ('HARD RULES — no exceptions', repeated ⚠️ blocks, emoji) that adds length without adding actionable detail, making it heavier than necessary for the information conveyed.

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

Completeness5/5

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

For a 14-parameter, zero-annotation research tool, the description is complete: query construction, source switching, filtering, pagination, and fallback semantics are all covered, and an output schema exists to carry the return structure. Nothing essential to correct invocation is missing.

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

Parameters5/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 and largely does: it enumerates valid source values with their distinct behaviors, exact court_types spellings, birimAdi chamber codes, date format and inclusivity, esas_no/karar_no YIL/SIRA format, sort_by inference rules, and the effects of include_snippets/include_raw/dil. Nearly all 14 parameters gain meaning beyond their bare typed names.

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?

Opens with a specific verb+resource+scope: it retrieves live court decisions, precedents, case law and legislation from official sources. It explicitly differentiates itself from siblings, stating it is the only tool that fetches live from Bedesten/Yargıtay/Mevzuat, and names search_local_corpus as the tool that cannot discover decisions. An agent can identify its role without reading the schema.

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?

Gives explicit when-to-use ('For ANY case-law question ... you MUST call THIS tool first'), when-not-to-use ('Do NOT answer from memory', 'Do NOT use search_local_corpus to FIND decisions'), and the follow-up workflow (verify via get_document). Alternatives and preconditions are spelled out rather than inferred.

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