eurlex-mcp-server

eurlex_summary

Read-onlyIdempotent

Retrieve the EU's plain-language LEGISSUM summary of a legal act by CELEX ID and language, giving non-lawyers its aim, key points, and application dates instead of the binding text.

Instructions

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.

Input 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv2.4.4Oct 29, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / offset / maximum
```
Added value: +9007199254740991
```
- changedOutput schema / properties / next_offset / anyOf
```
Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
```
- addedOutput schema / properties / offset / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / offset / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / returned_chars / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / returned_chars / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / total_chars / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / total_chars / minimum
```
Added value: +-9007199254740991
```
- addedOutput schema / properties / total_summaries / maximum
```
Added value: +9007199254740991
```
- addedOutput schema / properties / total_summaries / minimum
```
Added value: +-9007199254740991
```

Changed2 schema fields changedv2.4.2Sep 7, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed1 schema field changedv2.3.0Jul 22, 2026
- changedInput schema / properties / language / default
```
Previous value: -"DEU"New value: +"ENG"
```
First observedv2.2.0Jul 10, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds substantial behavioral context beyond those flags. It discloses the output fields, the obsolete flag, other_summaries handling, the clear 'no summary' outcome, and pagination behavior via max_chars/offset and next_offset.

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 front-loaded with the core purpose and then efficiently covers scope, parameters, pagination, missing summaries, and alternatives. Every sentence contributes operational information without redundancy.

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?

An output schema exists, so the description need not carry the full return-value explanation, but it still provides enough context about returned fields and pagination. Combined with clear alternatives and edge-case handling, the definition is complete 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 description coverage is 100%, so the schema already documents celex_id, language, max_chars, and offset. The description still adds useful semantics by giving concrete celex_id examples, noting language availability across the 24 official EU languages, and explaining pagination continuation via next_offset.

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 states a specific verb and resource: it returns the EU's official plain-language LEGISSUM summary of a legal act. It explicitly distinguishes this from the binding legal text and names eurlex_fetch and eurlex_metadata as alternatives, so an agent can identify the tool's role without inspecting the schema.

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?

It explains when to use this tool versus alternatives: use eurlex_fetch for full legal text and eurlex_metadata for structured metadata. It also covers edge cases, including acts with no summary and acts with multiple summaries where the most current non-obsolete one is returned.

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

Deploy Server