Skip to main content
Glama
Sign In
afsozer

Emsal MCP

by afsozer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

search_local_corpus

Discover legal precedents in the local corpus by concept when exact wording is unknown. Returns matched passages for quick relevance checks before verifying citations live.

Instructions

Concept DISCOVERY over the local corpus.

Searches the local corpus (decisions already fetched this session or via the corpus crawl) for a legal CONCEPT when the exact wording is unknown. Each result carries related_quotes — matched passages — so you can spot relevant precedent without fetching every full text.

Roles are complementary: THIS tool = DISCOVERY over the local corpus; search_decisions = live CURRENT search + citation verification. The corpus may lag; always confirm any decision you cite with search_decisions + get_document first.

QUERY FORM: 2–6 legal keywords, NOT a sentence. All terms are required (AND) and match anywhere in the text, so narrative filler only shrinks the result set. Quote words to require them adjacent: kıdem tazminatı zamanaşımı · "tahliye taahhüdü" geçerlilik. Unlike Bedesten this index folds diacritics (kamulastirma = kamulaştırma).

Args: query: 2–6 legal keywords; "quoted spans" match as phrases. mode: 'lexical' (default; FTS5/BM25, sub-second), 'rrf' (BM25+TF-IDF fusion; SLOW — minutes on a large corpus), 'semantic' (dense embeddings), 'hybrid'. limit: Max results. filters: Optional dict with source, court, chamber, content_status. provider: Embedding provider name for semantic modes (ignored for lexical). source/court/chamber/date/esas_no/karar_no/document_id: Flat filters — equivalent to putting them in filters. content_status/draft_usable/quote_usable: Content filters. sort: 'relevance' (default) or 'date' — lexical mode only.

Input Schema

NameRequiredDescriptionDefault
dateNo
modeNolexical
sortNorelevance
courtNo
limitNo
queryYes
sourceNo
chamberNo
esas_noNo
filtersNo
karar_noNo
providerNo
document_idNo
draft_usableNo
quote_usableNo
content_statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.9/5.0
Behavior5/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, and it delivers: corpus staleness, the mandated verification workflow, per-mode latency ('rrf' SLOW — minutes on a large corpus), AND-match semantics, and diacritic folding. It also discloses the return shape via 'related_quotes — matched passages', which is valuable with no output schema.

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

Conciseness5/5

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

Front-loaded with the one-line purpose, then cleanly sectioned into Roles, QUERY FORM, and Args. The length is justified by the 16 undocumented parameters and the query-syntax rules; there is no filler.

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?

Given 16 params, 0% schema coverage, no annotations, and no output schema, the description still tells an agent how to phrase the query, which mode to pick and its cost, how to filter, and what the results contain. Nothing essential to a correct call is missing.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must compensate, and it does for the high-impact params: query form and quoting, every mode value with performance trade-offs, limit, sort ('lexical mode only'), provider, and the group of flat filters explained as equivalents to 'filters'. Minor gaps remain (accepted values for content_status, date format, the bundled content filters), which keeps it short of a 5.

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 'Concept DISCOVERY over the local corpus' and specifies the resource (decisions fetched this session or via corpus crawl) and the trigger condition (when exact wording is unknown). It explicitly differentiates itself from the sibling search_decisions, so an agent can choose between them without reading either 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?

States the complementary roles directly: 'THIS tool = DISCOVERY over the local corpus; search_decisions = live CURRENT search + citation verification.' It gives an explicit caveat ('the corpus may lag') and a required follow-up ('always confirm any decision you cite with search_decisions + get_document first'), which is precisely the when/when-not/alternative guidance.

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

Deploy Server

Other Tools