Skip to main content
Glama

Search Decisions

search_decisions
Read-onlyIdempotent

Search decisions by meaning and keywords combined. Returns a shortlist: title, url, an overview (aiSummary: AI-written summary of what the decision is about, a machine paraphrase never quotable as the court's words; or snippet: the verbatim passage where your keywords matched) and metadata; get_decision reads the full text. Put constraints in the structured filters (jurisdiction, dates, articles, codes), keep the query for the legal issue. Values within one filter are OR'd; different filters are AND'd. The response carries a facets block: per filter name, a map of filter value to decision count under the current query. Reuse those keys verbatim to refine (a code from facets.jurisdiction_code, a slug from facets.legal_instrument). Hit metadata fields carry the same tokens under the same names: a hit's jurisdictionCode, legalDomain or solution passes back verbatim into the matching filter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'auto' is the right choice in almost all cases — it picks the regime from the query shape. auto: combines meaning and keyword matching on plain queries; switches to keyword-only when the query contains ET / OU / SAUF or quoted phrases. lexical: force keyword-only matching. Every term becomes required and nothing recovers a miss, so it fits a string you expect word for word (a consecrated formula, the direction of a holding, a party named in the text) and an empty answer is then an answer. Never for a docket number or a decision name, which auto resolves by exact key. semantic: force the meaning+keyword hybrid even on quoted or operator queries (where auto would fall back to keyword-only). Naming a mode, like adding ET / OU / SAUF, also keeps a docket number inside an ordinary query instead of resolving it alone.auto
sortNoResult ordering. Use 'relevance' (default) unless the user wants chronological order.relevance
limitNoMaximum number of results (default 10). Above 20 the window is clamped, not refused.
queryYesFrench query, the primary input. Two regimes — pick the right tool for the job: (a) Natural language or descriptive keywords for legal-issue searches; the engine handles synonyms and reformulations. Examples: « responsabilité hôpital infection nosocomiale » ; « étranger malade soins inaccessibles dans son pays d'origine » ; « licenciement discrimination syndicale charge de la preuve ». (b) Quoted exact phrases and ET / OU / SAUF operators for a named entity (company, municipality, person), a precise legal formula, or the direction of a holding: semantic matching ignores negations (« n'est pas X » ranks like « est X »), and only an exact phrase targets which way the court ruled. Examples: « "Société Générale" » ; « "commune de Saint-Denis" SAUF Réunion » ; « "force majeure" ET épidémie ». Using operators or quotes switches the engine to keyword-only matching for the whole query (no synonyms), so do not mix the two regimes: a quoted phrase followed by free words requires every one of them in the same decision. (c) A docket number or a decision name takes neither quotes nor operators: « 21PA01295 », « n° 19-20.682 », « arrêt Danthony » are matched by an exact key, whatever the spelling, and quoting them only costs the recovery that catches a miss.
officeNoFilter by specialised judge/office (JLD, JAF, JCP, JEX, juge des enfants, premier président, magistrat désigné). Absent value = ordinary bench.
chamberNoRestrict to one or more chambers, as a composite key "<court>|<chamber>" where <court> is a jurisdiction_code (e.g. "ca_paris|C3", "cc|C2", "cc|SOCIALE"). The court prefix is required: a chamber key names a different chamber in each court, "C1" alone existing in about 200 of them. The chamber part is slots joined by a dot, in the order they render: tag P (pôle), SC (section holding chambers), C (chambre), S (section), L (lettered section), Q (sous-sections réunies) or R (chambres réunies), then its number or letter. So "P5.C6" is pôle 5, 6e chambre, "C5.LA" section A of the 5th, "CD" chambre D, "R3-8" chambres 3/8 réunies (numbers in a reunited list always ascending). A chamber that no coordinate positions is keyed by what it judges instead ("cc|SOCIALE", "cc|CRIMINELLE"). facets.chamber lists the pairs present, and only once jurisdiction_code narrows the search to one or more courts.
date_toNoLatest decision date, inclusive (YYYY-MM-DD).
solutionNoFilter by the ruling of the operative part (référentiel solution). REJET / IRRECEVABILITE / DESISTEMENT / NON_LIEU_A_STATUER are procedural or negative endings; CONFIRMATION / INFIRMATION* / REFORMATION are appeal outcomes; CASSATION* is cassation-specific; ANNULATION covers administrative annulment; SATISFACTION_TOTALE / SATISFACTION_PARTIELLE cover first-instance civil rulings granting the claim.
ai_rerankNoWhen enabled (default), reorders results by actual relevance to the query using an LLM reranker. Keep on for agentic use — shortlist quality is significantly higher. Cost: a few seconds of extra latency. Disable only for high-rate exploratory searches where latency matters more than ranking quality.
date_fromNoEarliest decision date, inclusive (YYYY-MM-DD).
procedureNoFilter by procedural track (référés, QPC, EU referral, révision, tierce opposition…). Absent value = ordinary contentious procedure.
publicationNoFilter by publication, at the grain the Cour de cassation itself uses (any-of, membership is multiple: a decision matches every value whose code it carries). Judicial order: PUBLIE_BULLETIN, PUBLIE_RAPPORT (annual report, the strongest signal), LETTRE_CHAMBRE, COMMUNIQUE, INEDIT_BULLETIN. Administrative order: PUBLIE_LEBON, MENTIONNE_LEBON, INEDIT_LEBON. Lower courts carry no publication statement and match no value.
legal_domainNoFilter by legal domain (curated domain tree): 9 roots and their leaves (e.g. CIVIL_DROIT_LOCATIF). Selecting a root also matches all its leaves.
legal_articleNoRestrict to decisions citing a specific article of a specific code, as a composite key "<instrument>|<article>" where <instrument> is a slug or an exact text name, resolved like legal_instrument (e.g. "code-civil|1240", "code-de-justice-administrative|L761-1"). The instrument prefix is required — the same article number exists in several codes.
legal_instrumentNoRestrict to decisions citing one or more given codes or statutes. Accepts a slug from facets.legal_instrument (e.g. "code-civil") or an exact text name resolved server-side (e.g. "Code civil").
jurisdiction_codeNoRestrict to one or more precise court units by referential code. Code shapes: "cc" (Cour de cassation), "ce" (Conseil d'État), "cnda", "cedh", "cjue"; "ca_<city>", "caa_<city>", "ta_<city>", "tj_<city>", "tcom_<city>" (e.g. "ca_paris", "ta_marseille", "tj_paris", "tcom_lyon"). When unsure, guess with the city name in the code: the error names the nearest valid ones. Each code is a court; the chamber inside it is a separate filter (see chamber); use jurisdiction_type for the broad category.
jurisdiction_typeNoRestrict to one or more court categories: TJ (tribunal judiciaire), CA (cour d'appel), CC (Cour de cassation), TCOM (tribunal des activités économiques), TA (tribunal administratif), CAA (cour administrative d'appel), CE (Conseil d'État), CNDA (asylum), CONSTIT (Conseil constitutionnel), TC (Tribunal des conflits), CNIL (sanctions), CEDH and CJUE (European courts).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYes
queryYes
totalYesDecisions matched under the current filters, the whole set and not the served window: `hits` is one page of it, and `facets` counts that same set. Keyword matching is an OR bag over the query tokens, so a long query matches a large share of the corpus: narrow with filters (court, dates, chamber) rather than with more words for the number to count something.
facetsNoPer filter name, a map of filter value to decision count under the current query (jurisdiction_type, jurisdiction_code, chamber, office, legal_domain, solution, procedure, publication, date_lecture_year, legal_instrument). Reuse keys verbatim as filter values. jurisdiction_code is capped to the top 15 courts (other_courts counts the rest) and legal_instrument to the top 10 statutes. chamber appears only under a jurisdiction_code filter, and then lists every formation of the selected courts.
filterRewrittenNoA filter of the call was retired and rewritten: what was asked, what was searched, and the filter to use instead. The hits answer the rewritten call.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the operation read-only, idempotent, and non-destructive, but the description adds substantial behavioral context: the aiSummary is an AI paraphrase 'never quotable as the court's words', lexical mode makes every term required, semantic matching ignores negations, operators switch the whole query to keyword-only, and facets values can be reused verbatim for refinement. This goes far beyond what annotations convey.

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 long but every sentence earns its place: purpose and return shape first, then query-vs-filter guidance, then mode behavior, then facet reuse. There is no filler, repetition of schema content, or marketing language. Dense but structured.

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 the tool's complexity — 17 parameters, three search modes, filter combination semantics, and facet refinement — the description is remarkably complete. It explains what to return, how to phrase queries, how to combine filters, how to reuse facets, when to disable reranking, and when to hand off to get_decision. The output schema and annotations cover the remaining structural details.

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?

Schema description coverage is 100%, so the schema already documents each parameter in detail. The top-level description still adds complementary cross-parameter semantics: OR within a filter, AND across filters, how facets keys map back to filter names, and how hit metadata fields pass back verbatim into matching filters.

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 opens with a specific verb and resource: 'Search decisions by meaning and keywords combined' and immediately states what is returned. It also distinguishes itself from the sibling get_decision by noting that get_decision reads the full text, so an agent can tell the tools apart without inspecting 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?

The description gives rich, explicit usage guidance: keep constraints in structured filters, keep the query for the legal issue, and explains when lexical vs semantic vs auto modes are appropriate, including docket numbers and quoted phrases. It also names an alternative sibling (get_decision) and what to do after obtaining a shortlist.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool maps to a distinct resource or action: getting a decision, getting a legal text, searching decisions, searching legal texts, and listing user activity. Despite shared verbs like 'get' and 'search', the object nouns make the boundaries clear with no meaningful overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: get_decision, get_legal_text, list_my_activity, search_decisions, search_legal_texts. Pluralization is used consistently for search operations and singular nouns for direct retrieval, with no mixed conventions.

Tool Count5/5

Five tools is a tight, well-scoped set for a legal research server: two retrieval tools, two search tools, and one user-activity tool. Each tool earns its place and there is no redundancy or padding.

Completeness4/5

The core research workflow is covered: search and retrieve both legal texts and decisions, with citations and commentary embedded inline. The only minor gap is the lack of explicit bookmark management or citation-list navigation, but those are documented as embedded behaviors rather than dead ends.