Skip to main content
Glama

justicelibre

by io.github.Dahliyaal

get_ce_decision

Read-only

Récupère une décision du Conseil d'État par son numéro de pourvoi.

Essaie d'abord le bulk JADE DILA (lookup SQL exact), puis si introuvable
tente ArianeWeb Sinequa — les deux bases ont des couvertures complémentaires.

Pour retrouver une décision via identifiant DCE_*, utiliser
`get_decision_text` à la place.

⚠️ **Numéros réutilisés** : le CE a réattribué ses numéros de pourvoi
d'une époque à l'autre. 7 938 numéros sont portés par plusieurs
décisions (16 143 décisions concernées, mesuré le 29 août 2026). Le
n° 74052, par exemple, désigne à la fois un arrêt de 1969 sur des
quotas de mouture et l'arrêt d'Assemblée du 3 février 1989 « Compagnie
Alitalia ». Quand c'est le cas, la réponse porte un champ
`avertissement` et un champ `homonymes` listant les autres décisions du
même numéro. **Ne jamais conclure d'une seule réponse qu'un arrêt
n'existe pas** : lire `homonymes`, et désambiguïser en citant toujours
la date et la formation (« Ass., 3 février 1989, n° 74052 »).

Args:
    numero: numéro de pourvoi (ex : "497566", "358109")

Returns:
    Décision avec métadonnées — plus `homonymes` et `avertissement` si
    d'autres décisions portent le même numéro. Ou dict d'erreur
    structuré `{error, error_category: "not_found"}` si introuvable
    dans les deux bases.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
numeroYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses significant behavior: the dual-source JADE DILA/ArianeWeb fallback, the risk of reused pourvoi numbers, the homonymes and avertissement fields, and the structured not_found error category. This is rich, non-obvious behavioral context that prevents a potentially serious false-negative conclusion.

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 section earns its place: purpose, lookup strategy, alternative routing, the reused-number warning, and return/error contracts. It is well-structured with Args and Returns labels, and the critical ambiguity warning is clearly highlighted.

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 lookup tool with one required parameter, the description fully covers how to call it, what sources it consults, what the response may contain (homonymes, avertissement), and what an error looks like. The output schema exists, and the description explains the semantics that schema metadata alone would not convey.

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 carries full responsibility for parameter meaning. It defines numero as "numéro de pourvoi" and gives concrete examples ("497566", "358109"), which is exactly what an agent needs beyond the bare schema type string.

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 precise verb and resource: "Récupère une décision du Conseil d'État par son numéro de pourvoi." It clearly differentiates the tool from get_decision_text, which is used for DCE_* identifiers, and the sibling list confirms it is the dedicated pourvoi-number lookup.

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 states exactly when to use this tool (by pourvoi number) and explicitly redirects DCE_* lookups to get_decision_text. It also clarifies the lookup strategy across two complementary databases, giving an agent clear expectations about how the tool behaves when it searches.

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