Skip to main content
Glama

get_admin_decision

Read-only

Récupère une décision administrative par son numéro de requête exact.

Couvre toutes les juridictions : Conseil d'État, cours administratives
d'appel (CAA), tribunaux administratifs (TA). Utilise un lookup SQL exact
sur le champ `numero` — pas de FTS5, pas de faux positifs.

⚠️ **Désambiguïsation indispensable** : un même numéro à 7 chiffres
(ex: 2200433) est partagé par 24+ tribunaux administratifs différents
(chaque TA a sa propre série annuelle qui repart à 1). **Si tu sais
quelle juridiction a rendu la décision, passe-la TOUJOURS.**

Sans `juridiction`, le repli sur l'API live n'interroge que le Conseil
d'État et les CAA : un numéro de TA peut alors ressortir « introuvable »
alors qu'il existe. Dans ce cas, réessaie en nommant le tribunal.

⚠️ **Numéros réutilisés dans le temps** : au-delà du partage entre
tribunaux, un même numéro désigne parfois plusieurs décisions de LA
MÊME juridiction, rendues à des époques différentes (7 938 numéros du
CE, mesuré le 29 août 2026). La réponse porte alors un champ
`avertissement` et un champ `homonymes`. **Ne jamais conclure d'une
seule réponse qu'une décision n'existe pas.**

Args:
    numero: numéro de requête (ex : "2200433", "2116343", "497566")
    juridiction: identifiant de la juridiction. **Recommandé pour tout
        numéro à 7 chiffres** (TA/CAA codifié). Formats acceptés :
        - **Nom long (recommandé)** : "Cour administrative d'appel de Lyon",
          "Tribunal administratif de Paris", "Conseil d'État" (avec ou sans
          accent, casse libre). Matching tolérant via extraction de ville.
        - **Code court** : "TA69", "TA75", "CAA69", "CE", "CE-CAA".
          ⚠️ Les codes courts peuvent rater les arrêts anciens (id
          CETATEXT* historiques) pour lesquels le mapping interne échoue.
          Si tu sais le nom long, préfère-le.
        Note : "Lyon" seul reste ambigu (TA Lyon ou CAA Lyon) et n'écarte
        ni l'un ni l'autre. Dès que le nom porte l'ordre de juridiction
        ("Tribunal administratif de…", "CAA…", "Conseil d'État"), il est
        CONTRÔLÉ : une décision d'un autre ordre n'est jamais servie à la
        place, le tool répond introuvable. Avant le 23 août 2026, demander
        le TA de Lyon renvoyait silencieusement la CAA de Lyon.

Returns:
    Décision avec métadonnées (id, juridiction, numero, date, titre) —
    plus `homonymes` et `avertissement` si d'autres décisions du même
    ordre de juridiction portent ce numéro. Ou `{"error": "introuvable"}`
    si aucun résultat dans JADE.

Exemples :
    get_admin_decision("2200433", juridiction="Tribunal Administratif de Lyon")
        → DTA_2200433_20230214 (TA Lyon, 14 fév 2023, RSA dérogatoire)
    get_admin_decision("473286")  # CE n'a pas de doublon, juridiction inutile
        → DCE_473286_20231123 (CE, non-admission du pourvoi sur la précédente)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
numeroYes
juridictionNo

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 critical behavioral traits: exact-match SQL lookup with no false positives, fallback scope limited to CE/CAA without jurisdiction, time-based number reuse producing `homonymes` and `avertissement` fields, and controlled order-of-jurisdiction behavior ('une décision d'un autre ordre n'est jamais servie à la place'). It also documents a historical behavior change (pre-23 Aug 2026). This goes far beyond the annotation.

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: one-line summary, coverage, critical warnings, parameter details, return behavior, and concrete call examples. It is front-loaded with the most important disambiguation warning, and the structure uses headings, bullets, and examples to make dense information scannable.

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?

Despite having an output schema, the description still explains return metadata (`homonymes`, `avertissement`, error shape `{"error": "introuvable"}`) and edge cases. Given the tool's complexity—jurisdictional ambiguity, number reuse, format variations—the description covers everything an agent needs to invoke it correctly and interpret results confidently.

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 description coverage is 0%, so the description fully compensates. It documents `numero` with formats and examples ('2200433', '2116343', '497566'), and `juridiction` exhaustively: long names, short codes ('TA69', 'CAA69', 'CE'), ambiguity of partial names ('Lyon' alone), and format recommendations. This is far more than the bare schema provides.

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 administrative par son numéro de requête exact.' It then explicitly distinguishes its scope from sibling tools by covering all administrative jurisdictions (Conseil d'État, CAA, TA) and emphasizing an exact SQL lookup ('pas de FTS5, pas de faux positifs'). This clearly separates it from the search_* and court-specific get_* siblings.

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 explicit when-to-use guidance: pass `juridiction` always when known, with the warning 'Si tu sais quelle juridiction a rendu la décision, passe-la TOUJOURS.' It also explains the consequence of omitting it (TA numbers may return 'introuvable') and instructs retrying with the tribunal name. It contrasts with FTS5-based search, implying when to use search tools instead, and gives a concrete example where `juridiction` is unnecessary (CE numbers).

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.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