Skip to main content
Glama

justicelibre

by io.github.Dahliyaal

get_cc_decision

Read-only

Récupère une décision du Conseil constitutionnel par son numéro.

Format attendu : "AA-NNN NATURE" ou juste "AA-NNN" (ex : "79-105 DC",
"2020-800 DC", "2023-1048 QPC"). Lookup EXACT sur le numéro (aucune
recherche plein texte : une décision qui se contente d'en CITER une
autre ne doit jamais être servie à sa place).

⚠️ La nature n'est pas décorative : un même numéro existe en plusieurs
natures (2019-778 **DC** du 21 mars 2019 et 2019-778 **QPC** du 10 mai
2019). Sans nature et si le numéro est ambigu, le tool refuse de choisir
et renvoie la liste des candidats.

💡 Les deux usages sont séparés, et complémentaires :
· CETTE décision           → `get_cc_decision("2019-778 DC")`
· les décisions qui la CITENT (sa postérité, les revirements, les
  confirmations) → `search_cc(query='"2019-778 DC"')`, qui renvoie la
  décision elle-même ET celles qui la visent.
L'ancien lookup mélangeait les deux par accident et servait la citante
à la place de la citée.

Args:
    numero: numéro de décision CC (ex : "79-105 DC")
    nature: filtre optionnel (QPC, DC, L, etc.) — cf search_cc

Returns:
    `{id, titre, date, juridiction, nature, numero, numero_demande,
    ecli, text}` — `numero` est le numéro RÉELLEMENT servi, à comparer
    mécaniquement à `numero_demande`. Ou dict d'erreur structuré
    `{error, error_category}` si introuvable ou ambigu.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
natureNo
numeroYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation: it discloses exact-number matching, the risk of serving a citing decision instead of the cited one, the requirement to compare numero against numero_demande, and the structured error behavior for ambiguous or missing results. This is strong, actionable behavioral context.

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 longer than average, but each section earns its place: format, exact-match behavior, ambiguity warning, the get vs search distinction, and return structure. The key guidance is front-loaded and the bullet-and-warning layout makes it easy to parse.

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?

The description covers input format, disambiguation behavior, the main sibling tool to use instead, return fields, and error responses. For a simple two-parameter read tool with a readOnlyHint annotation, nothing essential for correct invocation 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?

The schema gives no descriptions for numero or nature, so the description has to compensate. It explains the expected format with examples, marks nature as optional, and explains why nature matters for ambiguous numbers, although the full set of nature values is left vague by 'QPC, DC, L, etc.'.

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 explicitly identifies the tool as retrieving a Conseil constitutionnel decision by its number, and clarifies the exact input format. It also distinguishes itself from the full-text search behavior, making the tool's scope unmistakable.

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 separates the two main uses: getting a decision itself via get_cc_decision, and searching for cases that cite that decision via search_cc. It also warns against full-text lookup and explains how ambiguity with respect to nature is handled, so an agent can route correctly.

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

All justicelibre toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

The tools are mostly distinct by legal source (admin, CC, CEDH, CJUE, etc.) and by action (search vs. retrieve). However, pairs like search_admin vs. search_conseil_etat both target Council of State jurisprudence, and get_decision_text could be mistaken for a generic decision retriever, creating some potential confusion despite detailed descriptions.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case pattern with action-first naming (get_, search_, list_, build_, resolve_, about_). The get_decision_* and search_* prefixes clearly separate retrieval from search, and modifiers like _libre and _recent are applied systematically.

Tool Count2/5

With 31 tools, the server is heavy, exceeding the 25+ threshold for 'too many.' While the breadth of French legal sources justifies many search/retrieval tools, the three recent admin variants and the redundant PISTE vs. libre duplicates suggest the set could be consolidated. The count feels disproportionate to the core purpose of legal research.

Completeness4/5

The tool set covers the full read lifecycle for legal research: orientation (about), search across all major sources, full-text retrieval for each source, law article lookup with historical versions, and URL building. Minor gaps exist, such as lacking a structured code browse or a direct way to enumerate all articles in a section, but these are workarounds via search_legi and get_law_article.

Resources