Skip to main content
Glama

eur-lex-mcp-server

by io.github.cyanheads

Search EU Documents

eurlex_search_documents
Read-only

Search EU legislation, treaties, and preparatory acts across the CELLAR corpus by document type, date range, EuroVoc subject, author institution, and in-force status. Keyword matches English titles and CELEX strings only — there is no full-text body search. Returns a page of CELEX numbers, work URIs, type labels, dates, and titles, newest first, each flagged with is_consolidated. At least one filter is required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (1–100). Defaults to 20.
offsetNoPagination offset — number of results to skip. Defaults to 0.
date_toNoEnd of date range (YYYY-MM-DD), matched against document date. Omit for no upper bound.
keywordNoKeyword matched against English document titles via the full-text index (multi-word input is treated as a phrase), or against CELEX substrings.
in_forceNoIf true, restrict to acts currently in force. Omit to return all regardless of in-force status.
date_fromNoStart of date range (YYYY-MM-DD), matched against document date. Omit for no lower bound.
document_typeNoDocument category: REG=Regulations, DIR=Directives, DEC=Decisions, TREATY=Treaties, JUDG=Judgments, OPIN_AG=AG Opinions, PROP=Proposals, REC=Recommendations. Each category includes its explicit CELLAR authority variants (for example, delegated and implementing regulations). Omit to search all types. Consolidated texts are excluded unless include_consolidated is true.
eurovoc_conceptNoEuroVoc concept URI to filter by subject (e.g. http://eurovoc.europa.eu/2828), obtained from eurlex_browse_subjects. Omit for no subject filter.
author_institutionNoAuthor institution name (e.g. "European Parliament", "Council", "European Commission"), matched against the English names of EU corporate bodies.
include_consolidatedNoWhen true and document_type is set, also match consolidated texts whose basic act belongs to that document category. No effect when document_type is omitted. Consolidated rows are always tagged is_consolidated: true.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit that was applied to this page.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of documents returned in this page.
totalNoNumber of documents returned in this page (not a corpus-wide count).
offsetNoPagination offset used for this response.
documentsNoMatching EU documents ordered by date descending.
truncatedNoTrue when the returned page was capped at the limit and more documents may exist.
query_echoNoEcho of filters applied to this search. Useful for diagnosing empty results.

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already provide readOnlyHint and openWorldHint, so no contradiction exists. The description adds valuable behavioral detail beyond those annotations: keyword matching is limited to English titles and CELEX strings with no full-text body search, results are returned newest first with a page of CELEX numbers, work URIs, type labels, dates, titles, and an is_consolidated flag, and a filter must be supplied.

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 four sentences with no filler. It front-loads the tool's purpose, follows with the key search limitation, then the return shape and ordering, and ends with the essential usage requirement. Every sentence earns its place.

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's 10 optional parameters, high schema coverage, and presence of an output schema, the description is sufficiently complete. It provides the central search workflow, the mandatory-filter rule, the crucial absence of full-text body search, and an accurate summary of the result payload, leaving no critical gap for correct invocation.

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 the baseline is 3, but the description adds non-obvious parameter semantics: it specifies that keyword matching is limited to English titles and CELEX strings, explicitly rules out full-text body search, and imposes the global constraint that at least one filter is required. These details meaningfully augment the already rich 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 opens with a specific verb and resource: 'Search EU legislation, treaties, and preparatory acts across the CELLAR corpus.' It also distinguishes itself from sibling retrieval/search tools by stating that keyword matches target titles and CELEX strings only, and that there is no full-text body search, making its role as a structured search endpoint clear.

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 gives clear invocation context: searching by document type, date range, EuroVoc subject, author institution, and in-force status, plus the explicit constraint that at least one filter is required. However, it does not name sibling tools or explicitly state when to prefer alternatives such as eurlex_get_document or eurlex_query_sparql.

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

All eur-lex-mcp-server 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.4/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: subject browsing, case search, document retrieval, relation traversal, identifier resolution, raw SPARQL, and legislation search. The few potentially similar tools (search_documents vs get_cases) are clearly separated by corpus and description.

Naming Consistency5/5

All tools follow the consistent eurlex_verb_noun pattern in lowercase snake_case, such as eurlex_get_document, eurlex_search_documents, and eurlex_lookup_celex. Verbs vary but the pattern is uniform and predictable.

Tool Count5/5

Seven tools is well-scoped for an EU legal research server covering search, retrieval, relationship traversal, and identifier resolution. Each tool has a clear role and none feel redundant or excessive.

Completeness4/5

The core research workflow is covered: browse subjects, search legislation, search cases, fetch documents, resolve identifiers, and traverse relations. Minor gaps exist such as no full-text body search and no explicit case-law full-text retrieval, but the raw SPARQL escape hatch partially mitigates these.

Resources