What can you do with this server?

This server provides direct access to EU legal documents and case law via the EUR-Lex Cellar API — no API key required. It offers 11 tools for searching, fetching, and analyzing EU legal documents: * eurlex_search: Search EU legal acts by title substring, with optional filters for document type, language, and date range. * eurlex_fetch: Retrieve full text of any act by CELEX ID, ELI, or Official Journal reference, with pagination for long documents. * eurlex_metadata: Get structured metadata (dates, in-force status, authors, legal basis, EuroVoc descriptors, directory codes). * eurlex_citations: Explore citation graphs — which acts a document cites, which cite it, and amendment/repeal relationships. * eurlex_by_eurovoc: Thematic search by EuroVoc concept label or URI, even when the term doesn't appear in the title. * eurlex_consolidated: Fetch the latest in-force, amendment-merged text of regulations, directives, or decisions. * eurlex_case_law: Search CJEU judgments, orders, and Advocate General opinions by party name, ECLI, CELEX, or related legal act. * eurlex_transposition: List national implementing measures (NIMs) for a directive, filterable by member state. * eurlex_structure: Get a document outline with character offsets for chapters, articles, annexes, and judgment paragraphs — enabling targeted reading. * eurlex_summary: Retrieve the official plain-language LEGISSUM editorial summary of an act. * eurlex_sparql: Run read-only SPARQL SELECT/ASK queries directly against the Cellar endpoint for advanced custom lookups. Additional features: supports all 24 official EU languages, accepts multiple identifier formats (CELEX, ELI, OJ references), includes built-in retry with backoff and in-process caching for resilience and performance.

Which integrations are available for this server?

Search and retrieve EU law via the EUR-Lex Cellar API, providing tools for searching legal acts, fetching full text, metadata, citation graphs, EuroVoc-based discovery, and consolidated versions.

How do I use eurlex-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@eurlex-mcp-server Find EU regulations about artificial intelligence from 2024" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

eurlex-mcp-server

by Honeyfield-Org

Overview Schema Related Servers Score Discussions

TypeScript

Remote

eurlex-mcp-server

npm version License: MIT Node.js MCP

Search and retrieve EU law via the EUR-Lex Cellar API -- an MCP server that gives AI assistants direct access to EU regulations, directives, court decisions, and more. No API key required.

What You Can Do

Ask your AI assistant questions like:

"Find EU regulations about artificial intelligence from 2024"
"Show me the full text of the AI Act (32024R1689)"
"What EuroVoc topics are assigned to the GDPR?"
"Which EU acts are about cybersecurity as a topic, even if the word isn't in the title?"
"Which documents cite the Digital Services Act?"
"Search for directives about renewable energy"
"Get the consolidated version of Regulation 2016/679 (GDPR)"
"Which CJEU judgments interpret the GDPR?"
"Look up the Court of Justice ruling with ECLI ECLI:EU:C:2014:317"
"How did Germany transpose the NIS2 Directive?"
"Outline the AI Act, then show me just Article 5"
"Give me the plain-language summary of the Digital Services Act"

Related MCP server: Comprehensive EU Law MCP Server

Features

11 specialized tools for searching, fetching, and analyzing EU legal documents (see Tool Reference)
EuroVoc thesaurus search -- find documents by EU taxonomy concepts, with automatic label fallback across all 24 languages
CJEU case law -- find judgments, orders, and Advocate General opinions by ECLI, CELEX, party/title, or the act they interpret
National transposition measures (NIM) -- list how member states transposed a given directive into national law
Document outline + targeted reading -- get an act's table of contents with plain-text offsets, then jump straight to a specific article with eurlex_fetch; for CJEU case law (CELEX sector 6) the outline also lists each numbered judgment paragraph as Paragraph N, so you can jump to a specific paragraph the same way (paragraph detection is language-independent)
Plain-language summaries -- retrieve the EU's LEGISSUM summary of an act
Raw SPARQL escape hatch -- run read-only SELECT/ASK queries directly against Cellar for questions the other tools can't express
Consolidated versions -- retrieve the latest in-force text of regulations, directives, and decisions, identified by CELEX ID or by doc type + year + number
Citation graph -- explore which documents cite or are cited by a given act, with a balanced split between the two directions
Structured metadata -- dates (with null instead of Cellar's 9999-12-31 sentinel for open-ended validity), in-force status, authors, legal basis, EuroVoc descriptors, and directory codes
Flexible identifiers -- eurlex_fetch, eurlex_metadata, and eurlex_structure accept a CELEX ID, an ELI (e.g. reg/2016/679), or a post-2023 Official Journal reference (e.g. OJ:L_202401689)
Structured output -- every tool returns a machine-readable structuredContent payload validated against a published outputSchema, alongside the JSON text block
Offset-based pagination -- eurlex_fetch, eurlex_consolidated, and eurlex_summary return next_offset so long documents can be read in successive calls
All 24 official EU languages -- request titles and full text in any official EU language (default English; configurable via EURLEX_DEFAULT_LANGUAGE)
No API key required -- uses the public EUR-Lex Cellar SPARQL endpoint
Resilient by default -- automatic retry with backoff on transient Cellar errors, and in-process caching of EuroVoc labels, consolidated-CELEX lookups, and metadata to cut latency on repeat requests

Quick Start

pnpm dlx eurlex-mcp-server

Or with npx:

npx -y eurlex-mcp-server

Configuration

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "eurlex": {
      "command": "npx",
      "args": ["-y", "eurlex-mcp-server"],
      "env": {
        "EURLEX_DEFAULT_LANGUAGE": "DEU"
      }
    }
  }
}

The env block is optional. Set EURLEX_DEFAULT_LANGUAGE to change the default language every tool uses when no language parameter is passed -- see Default language below. The other MCP clients below accept the same env block.

Claude Code

claude mcp add eurlex-mcp-server -- npx -y eurlex-mcp-server

VS Code

Add to .vscode/mcp.json:

{
  "servers": {
    "eurlex": {
      "command": "npx",
      "args": ["-y", "eurlex-mcp-server"]
    }
  }
}

Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "eurlex": {
      "command": "npx",
      "args": ["-y", "eurlex-mcp-server"]
    }
  }
}

Windsurf

Add to ~/.windsurf/mcp.json:

{
  "mcpServers": {
    "eurlex": {
      "command": "npx",
      "args": ["-y", "eurlex-mcp-server"]
    }
  }
}

Default language

Language-aware tools default to English (ENG) when no language parameter is passed. Set the EURLEX_DEFAULT_LANGUAGE environment variable to change that default to any of the 24 official EU languages, given as a Cellar 3-letter code (case-insensitive, e.g. DEU, FRA, POL). It is read once at startup and applies to both transports (stdio and HTTP); for an HTTP deployment it sets the default for every session of the process. An unset or invalid value falls back to ENG (an invalid value also logs a one-line warning to stderr). A per-call language parameter always overrides this default.

EURLEX_DEFAULT_LANGUAGE=DEU

For stdio MCP clients, set it via the env block in the client config (see the Claude Desktop example above).

HTTP Transport (Remote Deployments)

When running the server over HTTP (pnpm start:http / dist/http.js) instead of stdio, it's exposed to any client that can reach it over the network. To protect against DNS rebinding attacks, set these environment variables:

Variable	Required	Description
`MCP_ALLOWED_HOSTS`	no (but strongly recommended for public deployments)	Comma-separated list of allowed `Host` header values. Must match the header exactly, including the port if the server isn't reachable on the default HTTP(S) port.
`MCP_ALLOWED_ORIGINS`	no	Comma-separated list of allowed `Origin` header values. Only enforced when `MCP_ALLOWED_ORIGINS` is set together with `MCP_ALLOWED_HOSTS`.
`EURLEX_DEFAULT_LANGUAGE`	no	Default language (Cellar 3-letter code, case-insensitive) used when a tool call omits `language`; unset or invalid falls back to `ENG`. Read once at startup and applied to all sessions. Also honored under stdio -- see Default language.

Important: If your server runs behind a reverse proxy or load balancer, ensure it forwards the original Host header unmodified (e.g. nginx proxy_set_header Host $host;), otherwise MCP_ALLOWED_HOSTS validation will reject all legitimate traffic — the SDK compares the raw Host header as an exact string.

Production example:

MCP_ALLOWED_HOSTS=mcp.honeyfield.at

This protection is opt-in. If MCP_ALLOWED_HOSTS is not set, the server starts as before and logs a one-line startup warning (MCP_ALLOWED_HOSTS not set — DNS rebinding protection disabled). Any public deployment should set MCP_ALLOWED_HOSTS to its public hostname(s).

Tool Reference

The server exposes 11 read-only tools. Every tool returns both a JSON text block and a machine-readable structuredContent payload validated against a published outputSchema, so MCP clients can consume either representation. Tools that return titles or document text accept a language parameter taking any of the 24 official EU languages as a Cellar 3-letter code (default ENG, or whatever EURLEX_DEFAULT_LANGUAGE is set to): BUL, SPA, CES, DAN, DEU, EST, ELL, ENG, FRA, GLE, HRV, ITA, LAV, LIT, HUN, MLT, NLD, POL, POR, RON, SLK, SLV, FIN, SWE.

Tool	Purpose
`eurlex_search`	Title-substring search over legislation
`eurlex_fetch`	Full text of an act (by CELEX / ELI / OJ reference)
`eurlex_metadata`	Structured metadata for an act
`eurlex_citations`	Citation graph (cites / cited-by / amends / …)
`eurlex_by_eurovoc`	Thematic search by EuroVoc concept
`eurlex_consolidated`	Latest in-force consolidated text
`eurlex_case_law`	CJEU judgments, orders, and AG opinions
`eurlex_transposition`	National transposition measures for a directive
`eurlex_structure`	Document outline with plain-text offsets
`eurlex_summary`	Plain-language LEGISSUM summary
`eurlex_sparql`	Raw read-only SPARQL escape hatch

eurlex_search

Searches EU legal acts by title substring -- a contiguous, case-insensitive phrase match against the document title, not tokenized full-text search. For thematic discovery (the term may not appear in the title) use eurlex_by_eurovoc instead. Results are sorted newest-first within the fetched sample: for very broad single-word queries this is not guaranteed to be the globally newest match -- narrow with resource_type or date_from/date_to if that matters. The response no longer echoes the internal SPARQL query.

Parameter	Type	Required	Default	Description
`query`	string	yes	--	Title substring to match (3-500 chars), e.g. `"artificial intelligence high risk"`
`resource_type`	string	no	`"any"`	Document type filter: `REG`, `DIR`, `DEC`, `JUDG`, `REG_IMPL`, `REG_DEL`, `DIR_IMPL`, `DIR_DEL`, `DEC_IMPL`, `DEC_DEL`, `ORDER`, `OPIN_AG`, `RECO`, `any`
`language`	string	no	`"ENG"`	Language for titles and full text: any of the 24 official EU languages (Cellar 3-letter code, e.g. `DEU`, `ENG`, `FRA`, `POL`, `SPA`)
`limit`	number	no	`10`	Max results (1-50)
`date_from`	string	no	--	Filter from date, format: `YYYY-MM-DD`
`date_to`	string	no	--	Filter to date, format: `YYYY-MM-DD`

eurlex_fetch

Retrieve the full text of a document, identified by exactly one of celex_id, eli, or oj_ref. Long documents are paginated: the response includes returned_chars, total_chars, and next_offset (pass it as the next call's offset to keep reading; next_offset is null once there's nothing left).

Parameter	Type	Required	Default	Description
`celex_id`	string	no*	--	CELEX identifier, e.g. `"32024R1689"` for the AI Act
`eli`	string	no*	--	European Legislation Identifier, short (`reg/2016/679`) or full (`http://data.europa.eu/eli/reg/2016/679/oj`); resolved to a CELEX via Cellar
`oj_ref`	string	no*	--	Post-2023 Official Journal reference, e.g. `"OJ:L_202401689"` (AI Act); resolved to a CELEX via Cellar
`language`	string	no	`"ENG"`	Language: any of the 24 official EU languages (Cellar 3-letter code, e.g. `DEU`, `ENG`, `FRA`, `POL`, `SPA`)
`format`	string	no	`"xhtml"`	Output format: `xhtml` (structured) or `plain` (tags stripped, whitespace collapsed, entities decoded)
`max_chars`	number	no	`20000`	Max characters returned per call (1000-50000)
`offset`	number	no	`0`	Character offset into the processed document, for pagination

* Provide exactly one of celex_id, eli, or oj_ref.

eurlex_metadata

Retrieve structured metadata for a document: document/entry-into-force/end-of-validity/transposition dates, in-force status, authors, legal basis, EuroVoc descriptors, and directory codes. Identified by exactly one of celex_id, eli, or oj_ref (same identifier inputs as eurlex_fetch).

Parameter	Type	Required	Default	Description
`celex_id`	string	no*	--	CELEX identifier, e.g. `"32024R1689"`
`eli`	string	no*	--	European Legislation Identifier, short or full form; resolved to a CELEX via Cellar
`oj_ref`	string	no*	--	Post-2023 Official Journal reference, e.g. `"OJ:L_202401689"`; resolved to a CELEX via Cellar
`language`	string	no	`"ENG"`	Language for titles and EuroVoc labels: any of the 24 official EU languages (Cellar 3-letter code, e.g. `DEU`, `ENG`, `FRA`, `POL`, `SPA`)

* Provide exactly one of celex_id, eli, or oj_ref.

Notes on the response:

authors lists the resolved agent names (e.g. "European Parliament", "Council of the European Union") instead of an empty array.
legal_basis lists the CELEX IDs of the acts this document is based on.
Date fields (date_document, date_entry_into_force, date_end_of_validity, date_transposition) are null when absent -- including Cellar's 9999-12-31 sentinel for acts with no defined end of validity, which is normalized to null.
directory_codes are human-readable ("{code-tail}: {label}", where code-tail is the fragment after the last / of the directory-code URI), not raw URIs.

eurlex_citations

Explore the citation graph of a document -- which acts it cites, which acts cite it, and amends/based-on/repeals relations.

Parameter	Type	Required	Default	Description
`celex_id`	string	yes	--	CELEX identifier, e.g. `"32024R1689"`
`language`	string	no	`"ENG"`	Language for titles: any of the 24 official EU languages (Cellar 3-letter code, e.g. `DEU`, `ENG`, `FRA`, `POL`, `SPA`)
`direction`	string	no	`"both"`	`cites` (outgoing), `cited_by` (incoming), or `both`
`limit`	number	no	`20`	Max results (1-100)

With direction: "both", the two directions are queried and split evenly (roughly limit / 2 each) so that a burst of recent cited_by entries can't crowd out cites results. The response includes a counts: { cites, cited_by } object reporting how many of each were actually found.

eurlex_by_eurovoc

Find documents by EuroVoc thesaurus concept (label or URI).

Parameter	Type	Required	Default	Description
`concept`	string	yes	--	EuroVoc concept: label (e.g. `"artificial intelligence"`) or URI (e.g. `"http://eurovoc.europa.eu/4424"`)
`resource_type`	string	no	`"any"`	Document type filter (same values as `eurlex_search`)
`language`	string	no	`"ENG"`	Language: any of the 24 official EU languages (Cellar 3-letter code, e.g. `DEU`, `ENG`, `FRA`, `POL`, `SPA`)
`limit`	number	no	`10`	Max results (1-50)

eurlex_consolidated

Retrieve the consolidated (in-force) version of a regulation, directive, or decision. Identify the act with either celex_id or doc_type + year + number -- provide exactly one of the two forms. Like eurlex_fetch, the content is paginated via offset/max_chars/next_offset. The response also includes consolidated_celex (e.g. "02016R0679-20160504") and consolidation_date ("2016-05-04", parsed from that CELEX's date suffix; null if the resolved CELEX has none).

Parameter	Type	Required	Default	Description
`celex_id`	string	no*	--	CELEX ID of the original act, e.g. `"32016R0679"` (GDPR). Alternative to `doc_type`+`year`+`number`; must be a sector-3 CELEX (`3YYYY[R\|L\|D]NNNN`)
`doc_type`	string	no*	--	Document type: `reg` (regulation), `dir` (directive), `dec` (decision). Alternative to `celex_id`; provide together with `year` and `number`
`year`	number	no*	--	Year of the act (1950-2100), e.g. `2024`. Required together with `doc_type` and `number` when `celex_id` is not used
`number`	number	no*	--	Document number, e.g. `1689`. Required together with `doc_type` and `year` when `celex_id` is not used
`language`	string	no	`"ENG"`	Language: any of the 24 official EU languages (Cellar 3-letter code, e.g. `DEU`, `ENG`, `FRA`, `POL`, `SPA`)
`format`	string	no	`"xhtml"`	Output format: `xhtml` or `plain`
`max_chars`	number	no	`20000`	Max characters returned per call (1000-50000)
`offset`	number	no	`0`	Character offset into the processed document, for pagination

* Exactly one of celex_id or the doc_type+year+number triple must be provided.

eurlex_case_law

Search Court of Justice of the EU case law -- judgments, orders, and Advocate General opinions of the Court of Justice and the General Court. Provide at least one of query, celex_id, ecli, or related_celex (they may be combined). Each result gives celex, ecli, title, date, type, and eurlex_url. Use this for case law; eurlex_search covers only legislation.

Parameter	Type	Required	Default	Description
`query`	string	no*	--	Title/party substring (3-500 chars). CJEU titles start with a `"Judgment of the Court …"` prefix, so party names appear after it
`celex_id`	string	no*	--	Sector-6 CELEX of a specific ruling, e.g. `"62012CJ0131"` (Google Spain)
`ecli`	string	no*	--	European Case Law Identifier, e.g. `"ECLI:EU:C:2014:317"`
`related_celex`	string	no*	--	CELEX of a legal act (e.g. `"32016R0679"` GDPR); returns the case law interpreting that act
`court`	string	no	`"any"`	`COURT_JUSTICE`, `GENERAL_COURT`, or `any`
`type`	string	no	`"any"`	`JUDG`, `ORDER`, `OPIN_AG`, or `any`
`language`	string	no	`"ENG"`	Language of the title: any of the 24 official EU languages (Cellar 3-letter code)
`limit`	number	no	`10`	Max results (1-50)
`date_from`	string	no	--	Filter from this judgment date, format `YYYY-MM-DD`
`date_to`	string	no	--	Filter up to this judgment date, format `YYYY-MM-DD`

* Provide at least one of query, celex_id, ecli, or related_celex.

eurlex_transposition

List the national implementing measures (NIMs) EU member states enacted to transpose a directive into national law -- for transposition and compliance tracking. Each result gives the member state, the national measure's title (in that state's own official language, not translated), its date, the sector-7 NIM CELEX, and a EUR-Lex URL. total_found reports the full count; results is capped at limit. Regulations and decisions generally have no NIMs.

Parameter	Type	Required	Default	Description
`celex_id`	string	yes	--	Sector-3 CELEX of the directive, e.g. `"32022L2555"` (NIS2) or `"31995L0046"` (Data Protection Directive)
`country`	string	no	--	Filter by EU 2-letter member-state code (ISO 3166-1 alpha-2, except Greece = `EL`), e.g. `"DE"`, `"FR"`. Omit for all member states
`language`	string	no	`"ENG"`	Sets the locale of each `eurlex_url` (Cellar 3-letter code); does not translate NIM titles
`limit`	number	no	`20`	Max measures returned (1-100)

eurlex_structure

Return the outline (table of contents) of an 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, then call eurlex_fetch(celex_id, format:"plain", offset, max_chars) to jump straight to that article. Pass the same language to the follow-up fetch and keep format:"plain" -- offsets are language- and plain-text-specific. Heading recognition covers English, German, and French. 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 is language-independent (it keys on the paragraph number, not heading words), so you can get the offset of e.g. paragraph 72 of a judgment and jump eurlex_fetch straight to it. Each outline entry has level (1=part/title/annex, 2=chapter, 3=section, 4=article/paragraph), label (e.g. "Article 5", "Paragraph 72"), title, and offset; total_headings is the full count and the list is capped at 300 for very large acts (truncated=true).

Parameter	Type	Required	Default	Description
`celex_id`	string	no*	--	CELEX identifier, e.g. `"32024R1689"`
`eli`	string	no*	--	European Legislation Identifier, short or full form; resolved to a CELEX via Cellar
`oj_ref`	string	no*	--	Post-2023 Official Journal reference, e.g. `"OJ:L_202401689"`; resolved to a CELEX via Cellar
`language`	string	no	`"ENG"`	Language of the document to outline (Cellar 3-letter code); heading labels and offsets are language-specific

* Provide exactly one of celex_id, eli, or oj_ref.

eurlex_summary

Return the EU's own plain-language "summary of legislation" (LEGISSUM) for an act -- a good quick overview before reading the full legal text. Paginated like eurlex_fetch (offset/max_chars/next_offset). total_summaries is 0 when no summary exists (many acts have none); when several exist, the primary summary's text is returned and the rest are listed in other_summaries.

Parameter	Type	Required	Default	Description
`celex_id`	string	yes	--	CELEX of the act to summarize, e.g. `"32016R0679"` (GDPR) or `"32022R2065"` (Digital Services Act)
`language`	string	no	`"ENG"`	Language of the summary (Cellar 3-letter code); summaries are typically available in all 24 languages
`max_chars`	number	no	`20000`	Max characters returned per call (1000-50000)
`offset`	number	no	`0`	Character offset into the processed summary, for pagination

eurlex_sparql

Expert escape hatch: run a raw, read-only SPARQL query directly against the Cellar endpoint for questions the other tools cannot express. Requires knowledge of the CDM ontology -- see the eurlex_guide prompt for a property cheat sheet. Read-only: only SELECT and ASK are accepted; SPARQL Update and federated SERVICE clauses are rejected. A SELECT with no top-level LIMIT gets LIMIT 50 appended; a top-level LIMIT above 100 is rejected. The response carries vars/bindings (SELECT) or boolean (ASK) plus row_count, returned_rows, and a truncated flag (bindings are dropped whole to stay within a ~40,000-char budget).

Parameter	Type	Required	Default	Description
`query`	string	yes	--	A raw SPARQL 1.1 `SELECT`/`ASK` query (10-5000 chars) against the Cellar endpoint

CELEX Number Schema

CELEX identifiers uniquely identify EU legal documents. The format is:

[sector][year][type][number]

Sector (1 digit): 3 = legislation, 6 = case law, 7 = national transposition measures (the sectors these tools cover)
Year (4 digits): year of the document
Type (1-2 letters): R = regulation, L = directive, D = decision, J = judgment, etc.
Number: sequential number

Examples:

CELEX	Document
`32024R1689`	AI Act (Regulation 2024/1689)
`32016R0679`	GDPR (Regulation 2016/679)
`32022R2065`	Digital Services Act (Regulation 2022/2065)
`62014CJ0131`	Court of Justice case C-131/14

Development

Setup

git clone https://github.com/Honeyfield-Org/eurlex-mcp-server.git
cd eurlex-mcp-server
pnpm install
pnpm build

Commands

Command	Description
`pnpm dev`	Start dev server with hot reload
`pnpm build`	Compile TypeScript
`pnpm test`	Run unit tests
`pnpm test:watch`	Run tests in watch mode
`pnpm test:integration`	Run integration tests (hits real API)
`pnpm start`	Start production server

Testing

pnpm test              # unit tests
pnpm test:integration  # integration tests (hits real API)

Limitations

Rate limits: The EUR-Lex Cellar API is public but may throttle excessive requests.
Document availability: Not all documents have full text in all languages.
Consolidated versions: Only available for regulations, directives, and decisions.
Response size: Full text is returned per call in max_chars slices (default 20,000 characters) to stay within LLM context limits -- use offset/next_offset on eurlex_fetch/eurlex_consolidated/eurlex_summary to read the rest.
SPARQL timeouts: Complex queries may occasionally time out on the Cellar endpoint despite the built-in retry with backoff; narrow broad eurlex_search/eurlex_by_eurovoc queries with resource_type or date filters if this happens.
Search ordering: eurlex_search results are sorted newest-first within the fetched sample only -- for very broad queries this is not guaranteed to be the single globally newest match.

Contributing

See CONTRIBUTING.md for development setup, architecture overview, and submission guidelines.

License

MIT

Available Tools

6 tools

eurlex_by_eurovocA

Read-onlyIdempotent

Searches EU legal acts by EuroVoc thematic concept — the right tool for "documents about X" when the term may not appear in the title. Accepts a concept label in any official EU language (e.g. "artificial intelligence") or a EuroVoc URI; label resolution automatically falls back across all 24 official EU languages if the request language has no match, so the example works regardless of the default language.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results
`concept`	Yes	EuroVoc concept: a label (e.g. 'artificial intelligence') or a URI (e.g. 'http://eurovoc.europa.eu/4424')
`language`	No	Language of the title and EuroVoc labels, as a Cellar 3-letter code (any of the 24 official EU languages, e.g. DEU, ENG, FRA, POL, SPA)	ENG
`resource_type`	No	Document type filter	any

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes	Number of results in `results`
`results`	Yes	Acts tagged with the EuroVoc concept

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral details: it accepts labels or URIs, performs automatic language fallback across all 24 EU languages, and searches by concept rather than exact string match. No contradiction with 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 three sentences, front-loaded with purpose and use case. Every sentence adds value without redundancy. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema (so return values are covered) and rich annotations, the description covers core functionality, input formats, and language fallback. It hints at differentiation from siblings via the 'right tool' statement but does not fully contrast with all sibling tools. Overall, it is complete for a search tool with this parameter set.

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 description coverage is 100%, so baseline is 3. The description adds meaningful context for the 'concept' parameter by explaining it accepts labels or URIs and that label resolution falls back across languages. This goes beyond the schema's description. Other parameters (limit, language, resource_type) are not elaborated but schema already covers them well.

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 the tool searches EU legal acts by EuroVoc thematic concept. It distinguishes itself as the right tool when the term may not appear in the title, contrasting with potential title-based searches. The verb 'searches' is specific and the resource 'EU legal acts by EuroVoc concept' is well-defined.

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?

The description indicates when to use this tool ('documents about X' when term not in title) and provides context on language fallback. It implies it is not for title-based searches but does not explicitly name alternatives or exclusions. Overall, usage context is clear.

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

eurlex_case_lawA

Read-onlyIdempotent

Finds Court of Justice of the EU (CJEU) case law — judgments (JUDG), orders (ORDER), and Advocate General opinions (OPIN_AG) of the Court of Justice and the General Court. Look up rulings four ways (at least one required, combinable): query=title/party substring (e.g. "Schrems"), celex_id=a sector-6 CELEX (e.g. "62012CJ0131"), ecli=a European Case Law Identifier (e.g. "ECLI:EU:C:2014:317"), or related_celex=a legal act's CELEX (e.g. "32016R0679") to get the case law interpreting that act. Narrow with court (COURT_JUSTICE/GENERAL_COURT), type, language, and date_from/date_to. Unlike eurlex_search (which searches legislation by title), this tool is scoped to case law and understands ECLIs and act-to-case-law relations. Each hit returns celex, ecli, title, date, type, and eurlex_url.

ParametersJSON Schema

Name	Required	Description	Default
`ecli`	No	European Case Law Identifier, e.g. "ECLI:EU:C:2014:317" (Google Spain).
`type`	No	Procedure type filter: JUDG=judgment, ORDER=court order, OPIN_AG=Advocate General opinion, any=all case-law document types (incl. procedural notices).	any
`court`	No	Court filter: COURT_JUSTICE=Court of Justice, GENERAL_COURT=General Court, any=both.	any
`limit`	No	Maximum number of results
`query`	No	Title substring to search for among case law, e.g. "Schrems" or a party name. Matched as a contiguous phrase, case-insensitive. Note: CJEU titles begin with a boilerplate prefix ("Judgment of the Court …"); party names appear after it.
`date_to`	No	Filter up to this judgment date, format YYYY-MM-DD
`celex_id`	No	Sector-6 CELEX identifier of a specific ruling, e.g. "62012CJ0131" (Google Spain).
`language`	No	Language of the title, as a Cellar 3-letter code (any of the 24 official EU languages, e.g. DEU, ENG, FRA, POL, SPA). A ruling with no title in this language yields no result.	ENG
`date_from`	No	Filter from this judgment date onward, format YYYY-MM-DD
`related_celex`	No	CELEX of a legal act (e.g. "32016R0679" for the GDPR); returns the case law that interprets that act.

Output Schema

ParametersJSON Schema

Name	Required	Description
`total`	Yes	Number of entries in `results`
`results`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds significant behavioral detail: CJEU title prefix pattern, query matching as contiguous and case-insensitive, language-specific result behavior, and the fact that party names appear after the prefix.

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 a single paragraph of about 100 words, front-loaded with the main function. Every sentence adds distinct information, and there is no redundant or filler content.

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?

Given 10 parameters, enums, and an output schema, the description covers all lookup modes, filters, and result fields. It references the output schema implicitly by listing return fields (celex, ecli, etc.), making it complete for an agent to understand usage.

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?

Despite 100% schema coverage, the description adds value by explaining how lookup methods are combinable, that at least one is required, and provides clarifying examples (e.g., '62012CJ0131' for Google Spain). It also notes that date filters are for judgment dates and that query matches a contiguous phrase.

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 the tool finds CJEU case law, lists specific document types, and distinguishes from sibling tool eurlex_search which searches legislation. It gives four explicit lookup methods with examples.

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?

The description explicitly contrasts with eurlex_search, stating this tool is scoped to case law and understands ECLIs. It implies when to use each lookup method but could be more explicit about when not to use.

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

eurlex_fetchA

Read-onlyIdempotent

Fetches the full text of an EU legal act. Identify it by celex_id (e.g. "32024R1689"), by eli (e.g. "reg/2016/679" or a full ELI URL), or by oj_ref (post-2023 Official Journal reference, e.g. "OJ:L_202401689") — provide exactly one. Paginate long documents with offset and max_chars: pass the previous response's next_offset to continue reading until it is null.

ParametersJSON Schema

Name	Required	Description	Default
`eli`	No	European 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.
`format`	No	Output format: xhtml=structured XHTML, plain=text with XHTML tags stripped	xhtml
`offset`	No	Character offset for pagination (0-based)
`oj_ref`	No	Official 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_id`	No	CELEX identifier, e.g. "32024R1689" (AI Act). Provide exactly one of celex_id, eli, or oj_ref.
`language`	No	Language of the full text, as a Cellar 3-letter code (any of the 24 official EU languages, e.g. DEU, ENG, FRA, POL, SPA)	ENG
`max_chars`	No	Maximum number of characters returned

Output Schema

ParametersJSON Schema

Name	Required	Description
`offset`	Yes	The offset this window was sliced from
`content`	Yes	The document text in the requested window/format
`celex_id`	Yes	The resolved CELEX ID the text was fetched for
`language`	Yes	Cellar 3-letter language code of the text
`truncated`	Yes	True when more text remains beyond this window
`source_url`	Yes	Cellar REST URL of the fetched resource
`next_offset`	Yes	Offset to request next, or null when there is no more content
`total_chars`	Yes	Length of the full processed document
`returned_chars`	Yes	Length of `content`

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds context about pagination behavior and identifier resolution via Cellar, but does not disclose other traits like rate limits or return format details beyond the schema.

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 one paragraph of four sentences, front-loaded with purpose, then identifier options, then pagination. Every sentence is necessary and there is no redundant text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, pagination, output schema exists), the description covers identification and pagination well. It does not detail the language parameter or format options, but those are covered in schema. Missing explicit mention of full-text scope (already clear from purpose).

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 baseline is 3. The description adds meaning by explaining the exclusive OR relationship among celex_id, eli, and oj_ref, and the pagination flow with next_offset, which goes beyond individual parameter descriptions.

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 uses a specific verb ('Fetches the full text') and resource ('EU legal act'), and clearly distinguishes from siblings like eurlex_summary or eurlex_structure by emphasizing full text retrieval and multiple identifier options.

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?

The description explicitly states 'provide exactly one' of the identifiers and gives examples for each. It also explains pagination with offset and max_chars, linking to next_offset. However, it does not explicitly exclude usage in favor of sibling tools.

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

eurlex_structureA

Read-onlyIdempotent

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.

ParametersJSON Schema

Name	Required	Description	Default
`eli`	No	European 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_ref`	No	Official 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_id`	No	CELEX identifier, e.g. "32024R1689" (AI Act). Provide exactly one of celex_id, eli, or oj_ref.
`language`	No	Language 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.	ENG

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No	Present only when no headings were found or the outline was truncated
`outline`	Yes	Headings in document order
`celex_id`	Yes	The resolved CELEX ID (echoed for the follow-up eurlex_fetch)
`language`	Yes
`returned`	Yes	Number of headings in `outline` (<= total_headings)
`truncated`	Yes	True when `outline` was capped below total_headings
`source_url`	Yes
`total_chars`	Yes	Length of the plain text the offsets index into (matches eurlex_fetch total_chars)
`total_headings`	Yes	Total headings detected before the returned-list cap

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and destructiveHint; description adds behavioral details like truncation at 300 entries, language-specific offsets, and case-law paragraph detection, enhancing transparency.

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?

The description is thorough but not overly verbose; it is front-loaded with purpose and logically structured, though some detail on heading recognition could be shortened.

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?

Given the tool complexity and presence of output schema, the description covers all necessary aspects: usage pattern, parameter constraints, edge cases (capping, language/law-type specifics).

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?

While schema coverage is 100% with descriptions for each parameter, the description adds meaning beyond by explaining how offsets interact with eurlex_fetch and the language dependency.

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 (table of contents) of an EU legal act, distinguishing it from sibling tools like eurlex_fetch by explaining its use as a map 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 Guidelines5/5

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

Explicitly describes when to use (to get offsets for targeted reading) and how to chain with eurlex_fetch, providing clear alternatives and context.

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

eurlex_summaryA

Read-onlyIdempotent

Returns the EU's official plain-language summary (LEGISSUM) of a legal act — a short editorial overview written for non-lawyers ("what is the aim", "key points", "from when does it apply"), NOT the binding legal text. Input is the act's celex_id (e.g. "32016R0679" for the GDPR, "32022R2065" for the Digital Services Act) and a language (any of the 24 official EU languages; summaries are usually available in all of them). Output is the summary text (plain, HTML stripped) plus its LEGISSUM id, title, last-update date, an obsolete flag, and source_url (the EUR-Lex summary page). Long summaries paginate via max_chars/offset exactly like eurlex_fetch — pass the previous response's next_offset to continue. Several thousand major acts have a summary; many acts have none (you get a clear "no summary" message). When an act has several summaries the most current non-obsolete one is returned and the rest are listed in other_summaries. For the full legal text use eurlex_fetch; for structured metadata use eurlex_metadata.

ParametersJSON Schema

Name	Required	Description	Default
`offset`	No	Character offset for pagination (0-based)
`celex_id`	Yes	CELEX identifier of the EU act to summarize, e.g. "32016R0679" (GDPR) or "32022R2065" (Digital Services Act). LEGISSUM summaries exist for several thousand major acts; many acts have none.
`language`	No	Language of the summary text, as a Cellar 3-letter code (any of the 24 official EU languages, e.g. DEU, ENG, FRA, POL, SPA). Summaries are typically available in all 24 languages.	ENG
`max_chars`	No	Maximum number of characters returned

Output Schema

ParametersJSON Schema

Name	Required	Description
`date`	No	ISO date of the returned summary, or ''
`title`	No
`offset`	No	The offset this window was sliced from
`content`	No	Summary text (plain, HTML stripped), sliced to window
`celex_id`	Yes	The act CELEX that was queried
`language`	Yes
`obsolete`	No	True when the returned summary is flagged obsolete
`truncated`	No	True when more content remains beyond this window
`source_url`	No	EUR-Lex legislative-summary (LSU) page for the act
`legissum_id`	No	LEGISSUM id of the returned (primary) summary
`next_offset`	No	Offset to request next, or null when there is no more content
`total_chars`	No	Length of the full processed summary
`returned_chars`	No	Length of `content`
`other_summaries`	No	Other summaries for the same act (present only when total_summaries > 1)
`total_summaries`	Yes	Total LEGISSUM summaries linked to this act; 0 means none was found

TDQS

A4.9/5.0

Behavior5/5

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

Adds substantial context beyond annotations: pagination behavior, obsolete flag, multiple summary handling, non-binding nature, and that summaries are available in all 24 languages. No contradictions with 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?

Every sentence serves a purpose; front-loaded with main action, followed by input, output, pagination, edge cases. No wasted words.

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?

Covers all aspects: input, output, pagination, edge cases (no summary, multiple summaries), and sibling differentiation. Output schema exists so return values need no additional explanation.

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 baseline is 3. Description adds value with concrete examples (GDPR, DSA), explains Cellar 3-letter codes, and clarifies pagination, but few additional details beyond schema.

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 the tool returns a plain-language summary (LEGISSUM) of an EU act, distinguishes from siblings like eurlex_fetch and eurlex_metadata, and provides specific verb-resource combination.

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?

Explicitly tells when to use (to get summary) and when not (for full legal text or metadata), including alternatives. Also notes that many acts have no summary and explains pagination.

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

eurlex_transpositionA

Read-onlyIdempotent

Lists the national implementing measures (NIMs) EU member states enacted to transpose a given EU directive into national law — the answer to "how did member state X implement directive Y" for transposition and compliance tracking. Input celex_id is the directive's sector-3 CELEX (e.g. "32022L2555" for NIS2, "31995L0046" for the Data Protection Directive); optionally filter by country (2-letter member-state code, e.g. "DE"). Each result gives the member state, the national measure's title (in that state's own official language — not translated), its date, the sector-7 NIM CELEX reference, and a EUR-Lex URL. total_found reports the full count; results is capped at limit. For the directive itself use eurlex_fetch/eurlex_metadata; regulations and decisions have no NIMs.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of measures to return (1–100). The response also reports total_found (the full count).
`country`	No	Optional filter: EU 2-letter member-state code (ISO 3166-1 alpha-2, except Greece which is "EL" in EU usage), e.g. "DE", "AT", "FR". Omit to return measures from all member states.
`celex_id`	Yes	Sector-3 CELEX of the EU directive whose national transposition measures you want, e.g. "32022L2555" (NIS2) or "31995L0046" (Data Protection Directive). Member states transpose directives (CELEX type letter L); regulations and decisions generally have no national implementing measures.
`language`	No	Sets the locale of each result's eurlex_url (as a Cellar 3-letter code, any of the 24 official EU languages). NOTE: a national implementing measure's title is stored only in the member state's own official language and is returned as-is — this field does NOT translate titles.	ENG

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes
`celex_id`	Yes	The directive CELEX that was queried
`returned`	Yes	Number of measures in `results` (<= limit)
`total_found`	Yes	Full number of matching measures; when > returned, `results` was truncated

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds that results are capped at limit, total_found reports full count, titles are in original language, and language only affects URL locale. It also notes that member states transpose directives only.

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?

The description is a single paragraph with 4-5 sentences covering essential points without fluff. It could be more structured (e.g., separating input/output) but is still efficient and front-loaded.

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?

Given the complexity (4 params, output schema exists), the description provides a thorough overview: it mentions response fields (member state, title, date, CELEX, URL, total_found, results capped), differentiates from siblings, and covers key constraints (titles not translated, directives only). It is complete for an agent to use 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% with descriptions for all parameters. The description adds useful context: celex_id must be sector-3 CELEX for directives, country codes are ISO 3166-1 alpha-2 with Greece as 'EL', and language does not translate titles. This goes beyond baseline 3.

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 lists national implementing measures for EU directives, specifies the input (celex_id for directives), and differentiates from siblings by noting that for the directive itself one should use eurlex_fetch/eurlex_metadata and that regulations/decisions have no NIMs.

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?

Explicitly says when to use (transposition/compliance tracking) and when not to (directive itself, regulations/decisions). Also mentions optional country filtering and the purpose of the language parameter.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct aspect of EU legal research: concept search, full-text retrieval, case law, national implementation, structure, and summaries. No overlap in purpose.

Naming Consistency5/5

All tools follow the 'eurlex_' prefix with a clear snake_case noun describing their function (e.g., eurlex_fetch, eurlex_case_law), providing a predictable pattern.

Tool Count5/5

Six tools cover the essential needs of legal research without being overwhelming. Each tool serves a unique and necessary role, well-scoped for the domain.

Completeness4/5

Covers core operations: search, retrieval, case law, implementation tracking, structure navigation, and summaries. Minor gap: no general keyword search, but concept search and citation lookup mitigate this.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

eur-lex-mcp-server A
io.github.cyanheads
Search EU legislation, CJEU case law, and treaties; traverse CELLAR graph; browse EuroVoc concepts.
Legal & Compliance Government Data Search
726
Lex — Temporal Luxembourg and EU Law A
io.github.SFHAJJI
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Legal & Compliance Search Government Data
1019
SourceActs
com.sourceacts
Official EUR-Lex, UK, US, and gazette search, metadata fetch, and change-only watches.
Legal & Compliance Search
1
kvasir — verifiable German, Austrian, Swiss & EU law
legal.kvasir
Resolve, search and verify legal citations against the official sources, with provenance.
Legal & Compliance Search
2

Related MCP Servers

mcp-eur-lex
Legal & Compliance Government Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables searching and quoting EU legislation with verifiable EUR-Lex citations, including GDPR, NIS2, DORA, and the EU AI Act.
Updated 9 days ago (2026-08-26 17:05 UTC)
8
MIT
Comprehensive EU Law MCP
Legal & Compliance Documentation Access Government Data
Ansvar-Systems
A
license
Not graded
quality
F
maintenance
Provides structured access to EU treaties, regulations, directives, and CJEU case law via 14 tools for searching, retrieving, and analyzing legislation and court decisions.
Updated a month ago (2026-08-03 17:35 UTC)
Apache 2.0
LexAPI MCPofficial
Legal & Compliance Search
Lex-API
A
license
A
quality
B
maintenance
Enables querying EU legal documents, case law, and citation graphs through natural language using the LexAPI.
Updated a month ago (2026-07-21 13:49 UTC)
10
86
3
MIT
BOE & EUR-Lex MCP Server
Legal & Compliance Government Data
anamtb
A
license
A
quality
D
maintenance
Enables querying and analyzing Spanish (BOE) and EU (EUR-Lex) legal documents, with advanced search, PDF extraction, and cross-reference detection.
Updated 6 months ago (2026-02-21 02:05 UTC)
8
23
2
MIT

Appeared in Searches

Zugriff auf öffentliche Daten der Europäischen Union

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

eurlex-mcp-server

What You Can Do

Features

Quick Start

Configuration

Claude Desktop

Claude Code

VS Code

Cursor

Windsurf

Default language

HTTP Transport (Remote Deployments)

Tool Reference

eurlex_search

eurlex_fetch

eurlex_metadata

eurlex_citations

eurlex_by_eurovoc

eurlex_consolidated

eurlex_case_law

eurlex_transposition

eurlex_structure

eurlex_summary

eurlex_sparql

CELEX Number Schema

Development

Setup

Commands

Testing

Limitations

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

LexAPI MCPofficial

Appeared in Searches

Latest Blog Posts

MCP directory API