Skip to main content
Glama

LibreJustice

by fr.librejustice

Get Legal Text

get_legal_text
Read-onlyIdempotent

Fetch a legal article as it stood on a given date, by its url (any /texte/ link), or — lacking a url — by code + article, or by textId: one of those three is required. Returns the version in force at date (omit for today): full text, status, validity dates, and the timeline of all versions — say which version you quote. The text carries inline markdown links to cross-referenced articles (/texte/, open with get_legal_text; when served at a date, the links point to the same date). commentaires carries institutional commentary anchored on the article (analyses inline, links otherwise). A text with no articles — circulaire, publication decree — is read at its root /texte/{code}, and comes back whole, without num. Covers French codes and statutes, plus curated foreign codes and treaties.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoA librejustice.fr article URL `/texte/{code}/{article}`: take it from a search_legal_texts hit or an inline citation link, or compose it — {code} is the code slug ("code-civil", as in facets.legal_instrument), {article} the lowercase article key ("l761-1" for L. 761-1, "1240" for 1240). `/texte/{code}` alone addresses the text itself, which is how a text with no articles (circulaire, publication decree) is read.
codeNoCode slug, when you hold the code and the article apart rather than as a url ("code-civil"). Alone, addresses the text itself.
dateNoConsultation date (YYYY-MM-DD) — returns the version in force at that date. Omit for the version currently in force.
textIdNoLégifrance article id (LEGIARTI…), resolved to the article it designates. LEGITEXT and CID are not accepted.
articleNoLowercase article key, alongside `code` ("l761-1" for L. 761-1, "1240" for 1240).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
numNoArticle key. Absent when the url addressed the root of a text: with no articles the payload is the whole text, `text` carrying its body; with articles it is the table of contents, `articles` carrying it.
urlYes
codeYes
etatNo
notaNo
textNoFull text; cross-references to other articles render as inline markdown links (/texte/ urls, open with get_legal_text).
titleYes
dateFinNo
omittedNoArticles served without their body because the text or division exceeds the inline reading budget: their `url` fetches them.
articlesNoContents of a text root or of one of its divisions, in reading order. Each `url` goes back to get_legal_text; a `section` entry returns all its articles at once, which is the cheapest way to read a chapter. `text` is joined only within the inline reading budget.
versionsYes
dateDebutNo
sourceUrlNo
articleCountNoNumber of articles the text carries. Present only on the root of a text with articles.
commentairesNoInstitutional commentary anchored on this document: court-written analyses served inline (`body`), plus outbound links (`url`) to the rapporteur public's conclusions and to related institutional documents (reports, opinions, press releases). Context, never the ruling itself — quote the decision text, not a commentaire, as the court's words.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive behavior, and the description adds substantial detail beyond that: version-at-date semantics, returned fields such as full text, status, validity dates and timeline, date-consistent inline cross-reference links, commentary payload behavior, and root-path handling for texts without articles. This is rich behavioral context and does not contradict the annotations.

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 dense but efficient: the lead clause states the core action, identifier alternatives are grouped logically, and edge cases such as root /texte/{code} and date-consistent links each receive one purposeful sentence. Every sentence contributes to correct invocation, with 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?

For a complex fetch tool with 5 parameters and an output schema, the description covers required identifier combinations, date behavior, return contents, cross-linking behavior, commentary handling, and no-article texts. Combined with the rich input schema and output schema, an agent has the information needed to select and call the tool correctly.

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 coverage is 100%, so individual parameters are already documented, but the description adds cross-parameter meaning: the url vs code+article vs textId alternatives, the requirement that one of those routes be supplied, and the dual use of url/code as a root address for texts without articles. This guidance goes beyond what the schema alone 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 action and resource: 'Fetch a legal article as it stood on a given date', then lists the three accepted identifier routes. It also names the sibling search_legal_texts as the source for URLs and directs inline /texte/ links to this tool, clearly distinguishing fetching from searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit selection rules among identifier modes ('one of those three is required'), explains date omission for the current version, and routes cross-reference links to get_legal_text rather than search_legal_texts. It does not explicitly state when to prefer get_decision or search_decisions, but the legal-text fetch scope and linkage to search_legal_texts makes the appropriate context clear.

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

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

Resources