Skip to main content
Glama

eurlex_structure

Read-onlyIdempotent

Retrieve structured outline of EU legal acts with character offsets for chapters, articles, and paragraphs, enabling targeted retrieval of specific sections without scanning the full text.

Instructions

Returns the outline (table of contents) of an EU legal act — its chapters, sections, articles and annexes — each with a character offset into the document's plain text. Use it as a map for targeted reading: read an article's offset from the outline, then call eurlex_fetch(celex_id, format:"plain", offset, max_chars) with that offset to jump straight to that article instead of paging from the top of a long act. Identify the act by celex_id (e.g. "32024R1689"), eli, or oj_ref — provide exactly one. Each outline entry has: level (1=part/title/annex, 2=chapter, 3=section, 4=article), label (e.g. "Article 5", "CHAPTER III"), title (the heading's subtitle, e.g. "Prohibited AI practices"), and offset. total_headings is the full count; the returned list is capped at 300 for very large acts (truncated=true). Heading offsets are specific to the chosen language and to plain (tag-stripped) text — pass the SAME language to the follow-up eurlex_fetch call and keep format:"plain". Heading recognition covers English, German and French documents. For case-law documents (CELEX sector 6, e.g. CJEU judgments) the outline additionally lists each numbered judgment paragraph as "Paragraph N" (level 4); numbered-paragraph detection works in any language (it keys on the paragraph number, not heading words) — so you can get the offset of, say, paragraph 72 of a judgment and jump eurlex_fetch straight to it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eliNoEuropean Legislation Identifier (ELI), short or full form, e.g. "reg/2016/679" or "http://data.europa.eu/eli/reg/2016/679/oj" (GDPR). Resolved to a CELEX ID via Cellar. Provide exactly one of celex_id, eli, or oj_ref.
oj_refNoOfficial Journal reference in the post-2023 scheme, e.g. "OJ:L_202401689" (AI Act). Resolved to a CELEX ID via Cellar. Provide exactly one of celex_id, eli, or oj_ref.
celex_idNoCELEX identifier, e.g. "32024R1689" (AI Act). Provide exactly one of celex_id, eli, or oj_ref.
languageNoLanguage of the document to outline, as a Cellar 3-letter code (any of the 24 official EU languages, e.g. DEU, ENG, FRA). Heading labels are language-specific; the returned offsets index the plain text of THIS language, so pass the same language to the follow-up eurlex_fetch call.DEU

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoPresent only when no headings were found or the outline was truncated
outlineYesHeadings in document order
celex_idYesThe resolved CELEX ID (echoed for the follow-up eurlex_fetch)
languageYes
returnedYesNumber of headings in `outline` (<= total_headings)
truncatedYesTrue when `outline` was capped below total_headings
source_urlYes
total_charsYesLength of the plain text the offsets index into (matches eurlex_fetch total_chars)
total_headingsYesTotal headings detected before the returned-list cap
Behavior5/5

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

Discloses beyond annotations: truncation at 300 headings for large acts, language-specific offsets, case-law paragraph detection works in any language, identifier mutual exclusivity. No contradiction with readOnlyHint etc.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured, front-loaded with purpose, every sentence adds value. Slightly long but informative.

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?

Complete coverage: usage, parameters, output schema explained, edge cases (truncation, case-law, language dependency), ties to sibling eurlex_fetch.

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?

Adds meaning beyond schema: explains mutual exclusivity of identifiers, language parameter must match follow-up fetch, output format details (level, label, title, offset, total_headings, truncated). Schema coverage 100% but description adds critical constraints.

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 clearly states it returns the outline of an EU legal act with character offsets, and distinguishes from sibling tools like eurlex_fetch (fetch text) by explicitly describing how to use the outline for targeted reading.

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?

Provides explicit usage guidance: use as a map for targeted reading, provide exactly one identifier, pass same language to eurlex_fetch. Does not explicitly mention when not to use, but implies context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Honeyfield-Org/eurlex-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server