eur-lex-mcp-server
Server Details
Search EU legislation, CJEU case law, and treaties; traverse CELLAR graph; browse EuroVoc concepts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/eur-lex-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: browsing thesaurus, searching cases, fetching documents, traversing relations, looking up citations, running SPARQL, and searching legislation. No overlap or ambiguity.
All tool names follow a consistent 'eurlex_verb_noun' pattern in snake_case, making them predictable and easy to understand.
Seven tools is well-scoped for a legal database server covering EU law, providing essential operations without being too many or too few.
The tool set covers major functionalities like searching, fetching, and traversing relations. Minor gaps exist (e.g., no full-text search), but overall it is comprehensive for read-only access to EU law.
Available Tools
7 toolseurlex_browse_subjectsBrowse EuroVoc SubjectsARead-onlyIdempotentInspect
Search the EuroVoc thesaurus, resolving a keyword into concept URIs usable in the eurovoc_concept subject filter of eurlex_search_documents. Returns each concept URI, its preferred label in the requested language, code, and broader (parent) label, ordered alphabetically by label.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of EuroVoc concepts to return (1–50). Defaults to 20. | |
| offset | No | Pagination offset — number of concepts to skip. Defaults to 0. | |
| keyword | Yes | Search term to match against EuroVoc concept labels (e.g. "privacy", "agriculture", "trade"). | |
| language | No | Language code for concept labels (e.g. "en", "fr", "de"). Case-insensitive — "EN" and "en" behave identically. Defaults to English. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied to this response. |
| shown | No | Number of concepts returned in this response. |
| total | Yes | Number of concepts returned in this response. |
| offset | Yes | Pagination offset used for this response. |
| concepts | Yes | Matching EuroVoc concepts ordered alphabetically by label. |
| truncated | No | True when the returned list was capped at the limit and more concepts may exist. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds detail on return fields (URI, label, code, broader label) and ordering (alphabetically), which provides useful context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by output specifics. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, output format, and integration with another tool. Given the presence of an output schema and annotations, the description is mostly complete. It lacks mention of pagination behavior (limit/offset) but that is covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 minimal extra parameter information beyond the schema, only referencing 'requested language' which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('EuroVoc thesaurus'), clearly states the output is usable for the eurovoc_concept filter in eurlex_search_documents, and distinguishes it from sibling tools by focusing on thesaurus browsing and concept URI resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (to get concept URIs for filtering in eurlex_search_documents), providing context. However, it does not explicitly mention when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurlex_get_casesSearch CJEU/GC Case LawARead-onlyInspect
Search CJEU and General Court case law — judgments, orders, and Advocate General opinions — by case number, court, case type, keyword, and date range. By default only these primary records are returned; derivative judicial information notices, case abstracts, summaries, and corrigenda are excluded so distinct cases fill the page (set include_derivative to include them). Keyword matches English case titles (which carry party names) and CELEX strings; there is no full-text body search. Returns each case with its court, date, and type, plus — parsed from the title where present — the parties, subject matter, and case reference.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | Court filter: CJEU = Court of Justice of the EU, GC = General Court. Omit to search both. | |
| limit | No | Maximum number of results to return (1–100). Defaults to 20. | |
| offset | No | Pagination offset — number of results to skip. Defaults to 0. | |
| date_to | No | End of date range in ISO 8601 format (YYYY-MM-DD). Leave blank or omit for no upper bound. | |
| keyword | No | Keyword to match against case titles and CELEX strings. | |
| case_type | No | Case type: judgment, order (procedural decision), or ag_opinion (Advocate General opinion). Omit to search all. | |
| date_from | No | Start of date range in ISO 8601 format (YYYY-MM-DD). Leave blank or omit for no lower bound. | |
| case_number | No | Case number in standard format: C-{num}/{year} for CJEU or T-{num}/{year} for General Court (e.g. C-131/12). | |
| include_derivative | No | Include derivative sector-6 records — judicial information notices, case abstracts, case summaries, and corrigenda — alongside primary judgments, orders, and AG opinions. Default false: these are excluded so distinct primary cases fill the page. Ignored when case_type is set (that path already returns a single primary type). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied to this page. |
| cases | Yes | Matching case law records ordered by date descending. |
| shown | No | Number of cases returned in this page. |
| total | Yes | Number of cases returned in this page (not a corpus-wide count). |
| offset | Yes | Pagination offset used for this response. |
| truncated | No | True when the returned page was capped at the limit and more cases may exist. |
| query_echo | Yes | Echo of filters applied to this search. Useful for diagnosing empty results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds valuable detail: default exclusion of derivative records, keyword matching only in titles and CELEX (no full-text search), information parsed from titles (parties, subject matter, case reference), and the effect of the include_derivative parameter. This goes beyond annotation minima.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, starting with the main purpose, then detailing default behavior, search limitations, and return fields. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 100% schema coverage, and an output schema, the description covers the essential behavioral details, defaults, and search constraints. Minor gaps like pagination behavior or error conditions are not addressed, but overall completeness is high given the annotations and schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds meaning beyond the schema by explaining default behaviors (e.g., include_derivative default false, keyword scope), case_number format, and interaction between parameters (include_derivative ignored when case_type set). This adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches CJEU and General Court case law, specifying record types (judgments, orders, AG opinions) and filter criteria (case number, court, case type, keyword, date range). It distinguishes itself from siblings like eurlex_search_documents by focusing on primary case records and excluding derivative records by default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behavior (excludes derivative records) and provides guidance on the include_derivative parameter, but does not explicitly compare this tool with sibling tools or state when to use alternatives. Usage context is implied but not formalized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurlex_get_documentGet EU DocumentARead-onlyIdempotentInspect
Fetch the metadata and full text of an EU act by CELEX number, ELI URI, or work URI. Returns structured metadata (title, date, type, author institution, legal basis, EuroVoc subjects, in-force status) plus the act body as HTML, Markdown, or Formex4 XML, defaulting to English with automatic fallback. Large bodies are paged by default (offset/limit with has_more) or returned whole with content_mode "full"; use outline: true for a heading map and select to pull specific articles, chapters, recitals, or annexes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum characters to return in this window ("paged" mode only). Default 25000, max 100000. For the entire body in one response, use content_mode "full". | |
| format | No | Content format: "html" for the act text as served by EUR-Lex (default), "markdown" for that HTML converted to clean Markdown server-side, or "xml" for Formex4 structured XML. | html |
| offset | No | Character offset into the body where the returned window starts ("paged" mode only). Page forward by setting offset = content_offset + content_chars_returned from the previous call. Offsets are format-specific: an offset is only valid against the same format it was measured in — keep format constant when paging. | |
| select | No | Return only the text of specific sections by type and number, instead of a raw character window (Roman and Arabic numbers are equivalent). Sections are located in the body of the requested format, so pair select with the same format used for any outline. A section that cannot be located is reported in selection.missed with no wrong text returned. Ignored when outline is true or in content_mode "metadata_only". | |
| eli_uri | No | Work-level ELI URI of the act to fetch (e.g. http://data.europa.eu/eli/reg/2016/679, with or without the /oj suffix). Provide exactly one of celex_number, eli_uri, or work_uri. | |
| outline | No | Return a structural outline of the act — chapters, sections, articles, annexes, and recitals as a heading list, each with its character offset — instead of body text. Read a section by paging with its offset, keeping the same format: outline offsets are measured in the requested format's body and land in the wrong place under any other format. Ignores offset/limit and select; no detectable structure returns an empty outline. Not applied in content_mode "metadata_only". | |
| resolve | No | Which version to serve for a base act with newer consolidated versions. "as_requested" (default) returns the exact CELEX requested; "current_consolidated" serves the newest consolidated version instead (echoing the request in requested_celex), a no-op when none exists. Either way, is_superseded / current_consolidated_celex / consolidated_as_of flag a stale base act. | as_requested |
| language | No | Language code for document content (ISO 639-1 uppercase, e.g. EN, FR, DE). Defaults to EN, and falls back to EN if the requested language is unavailable. | EN |
| work_uri | No | CELLAR work resource URI to fetch (e.g. http://publications.europa.eu/resource/cellar/3e485e15-11bd-11e6-ba9a-01aa75ed71a1) — the form returned by eurlex_lookup_celex, eurlex_get_relations, and eurlex_search_documents. Provide exactly one of celex_number, eli_uri, or work_uri. | |
| celex_number | No | CELEX number of the act to fetch (e.g. 32016R0679 for GDPR). Provide exactly one of celex_number, eli_uri, or work_uri. | |
| content_mode | No | How much of the body to return. "paged" (default) returns a bounded character window (see offset/limit); "full" returns the entire body in one call (large acts can be hundreds of KB); "metadata_only" skips the content fetch. offset and limit apply only to "paged". | paged |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | No | Document date in ISO 8601 format (YYYY-MM-DD). |
| title | No | Document title in the requested language (absent for some older works and judgments). |
| content | No | Body content of the act in the requested format and language. In "paged" mode a character window (see content_offset / content_chars_returned / has_more); in "full" mode the entire body; omitted in "metadata_only" mode, when the window is empty, or when content is unavailable. |
| outline | No | Structural outline of the act. Present only when outline is true; an empty array means no structure was detected. |
| has_more | Yes | True when body content exists beyond the returned window. Page forward with offset = content_offset + content_chars_returned, or request content_mode "full". Always false in "metadata_only" mode. |
| in_force | No | Whether the act is currently in force. |
| language | Yes | Language code of the returned content. |
| work_uri | No | CELLAR work URI. |
| selection | No | Outcome of a structural selection. Present only when select was used; content holds the matched sections joined in document order. |
| legal_basis | No | Legal basis acts for this work. |
| celex_number | Yes | Confirmed CELEX number for the retrieved work. |
| content_mode | Yes | Content mode applied to this response: "metadata_only", "paged", or "full". |
| is_superseded | No | True when a newer consolidated version of the requested base act exists (an unofficial reading aid merging later amendments), so the returned text may not include those amendments. Not a repeal/replacement signal — the base act remains the law and may still be in force (see in_force). Absent when the act has no consolidated version, or is itself one. |
| resource_type | No | Human-readable document type label (e.g. "Regulation", "Directive"). Absent for some older works. |
| content_format | Yes | Format of the returned content: "html", "markdown", or "xml". |
| content_offset | No | Character offset where the returned content window begins. Present when a body was fetched and available. |
| requested_celex | No | The originally requested CELEX, echoed when resolve "current_consolidated" served a different (consolidated) work. celex_number holds the CELEX actually served. Absent when the served work is the one requested. |
| eurovoc_subjects | No | EuroVoc subject classifications. |
| content_available | Yes | Whether body content was fetched from EUR-Lex. False in "metadata_only" mode (no fetch attempted) — use content_mode to distinguish "not requested" from "unavailable upstream". |
| language_fallback | No | Human-readable note explaining the fallback that occurred (e.g. "Requested FR content unavailable; returned EN"). Present only when a fallback happened. |
| author_institution | No | Human-readable name of the primary (first) originating EU institution (e.g. "European Parliament", "Council of the EU"). For co-legislated acts, prefer author_institutions for the complete set. Absent when not recorded. |
| consolidated_as_of | No | Consolidation date of current_consolidated_celex in ISO 8601 (YYYY-MM-DD). Present only when is_superseded is true. |
| structure_detected | No | Whether any act structure was parsed from the body. Present when outline or select was used; false means no detectable chapter/article/annex structure — read it via offset/limit or content_mode "full". |
| author_institutions | No | All originating EU institutions, for co-legislated acts adopted by more than one body (e.g. ["European Parliament", "Council of the EU"]). Absent when none recorded. |
| content_chars_total | No | Total character length of the full document body. Present when content was fetched and available; use with content_offset to page through the entire act. |
| content_chars_returned | No | Number of body characters returned in this response (equals content length). Present when a body was fetched and available. |
| current_consolidated_celex | No | CELEX of the newest consolidated version of the requested base act (e.g. 02014R0833-20260424) — fetch it with eurlex_get_document, or pass resolve "current_consolidated". Present only when is_superseded is true. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations (readOnly, openWorld, idempotent) by detailing paging behavior, outline, select, resolve versioning, and language fallback, providing rich behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that efficiently front-loads purpose and covers key behaviors, though it could be slightly more structured (e.g., bullet points) for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested objects, output schema), the description is comprehensive, covering all modes, parameters, and behaviors, leaving no critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already covers all parameters with 100% description coverage, the description adds value by explaining paging, outline, and select usage, enhancing understanding beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches metadata and full text of an EU act by CELEX number, ELI URI, or work URI, differentiating it from sibling tools like search or lookup by providing a specific resource and output focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to retrieve a known document by one of three identifiers) and provides detailed parameter guidance (e.g., exactly one identifier required, paging vs. full mode), but lacks explicit exclusion of when to use alternatives like search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurlex_get_relationsGet CELLAR Relationship GraphARead-onlyIdempotentInspect
Traverse the one-hop CDM relationship graph of an EU act: what it amends or is amended by, what it repeals or is repealed by (explicit and implicit), its consolidated versions, its legal basis, and works that cite it. Returns direct relations only, paginated per relation type and direction. Requires a CELEX number or CELLAR work URI.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum related works per relation type and direction (1–100, default 100). Incoming edges are ordered newest-first, so the cap keeps the newest — page with offset for older ones. When truncated is true, at least one direction filled its cap. | |
| offset | No | Pagination offset applied per relation type and direction — related works to skip (default 0). Page forward by adding limit; incoming edges are newest-first, so higher offsets reach older works. | |
| work_uri | No | CELLAR work resource URI to traverse (e.g. http://publications.europa.eu/resource/cellar/3e485e15-11bd-11e6-ba9a-01aa75ed71a1). Used directly without CELEX resolution. Provide exactly one of celex_number or work_uri. | |
| celex_number | No | CELEX number of the work to traverse (e.g. 32016R0679). Provide exactly one of celex_number or work_uri. | |
| relation_types | No | Subset of relation types to return; omit for all. Types: cites, amends, amended_by, repeals, repealed_by, implicitly_repeals, implicitly_repealed_by, legal_basis (treaty/article this act rests on), consolidated_version (consolidated texts of this act). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The per-direction cap applied to this page. |
| shown | No | Number of relations returned in this page. |
| total | Yes | Number of relations returned in this page (not a corpus-wide count). A direction that filled its cap sets truncated — page with offset for the rest. |
| offset | Yes | Pagination offset applied to this response (per relation type and direction). |
| work_uri | Yes | CELLAR URI of the source work (the work_uri input, or resolved from the CELEX). |
| relations | Yes | Direct CDM relations for the requested work. |
| truncated | No | True when at least one relation type/direction filled its per-direction cap and more related works may exist — page with offset. |
| celex_number | No | CELEX number of the source work whose relations were traversed. Absent when addressed directly by work_uri. |
| empty_relation_types | Yes | Requested relation types that returned zero relations in THIS page. Page-scoped: a type can appear here because all its edges sit beyond the current offset/limit window, not only because the act genuinely has none of that relation — so absent-from-here does not prove absent-in-CELLAR. When every requested type is empty the tool throws no_relations instead. |
| requested_relation_types | Yes | The relation types this request traversed — the explicit relation_types list, or all types when it was omitted. Diff against the types present in relations[], or read empty_relation_types, to confirm which requested types returned edges. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint. Description adds pagination behavior (newest-first, per type/direction) and truncated flag, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no wasted words. Efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers input, return behavior, pagination, and relation types fully, leaving no gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline 3. Description adds context on one-of requirement and pagination behavior, providing additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool traverses the one-hop CDM relationship graph and lists specific relation types (amends, repeals, etc.), distinguishing it from siblings like search or browse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies input requirements (CELEX or URI) and that it returns direct relations only, but lacks explicit when-to-use vs alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurlex_lookup_celexResolve EU Legal CitationARead-onlyIdempotentInspect
Resolve an EU legal citation — a CELEX number or ELI URI — to its canonical CELLAR work, confirming it exists before you fetch or traverse it. Returns the work URI, confirmed CELEX number, document type, and date.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | The EU legal citation to resolve: a CELEX number (e.g. 32016R0679) or a work-level ELI URI (e.g. http://data.europa.eu/eli/reg/2016/679, with or without the /oj suffix). | |
| identifier_type | No | Format of the identifier. "auto" detects it automatically; supply "celex" or "eli" explicitly if detection fails. | auto |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | No | Document date in ISO 8601 format (YYYY-MM-DD). |
| found | Yes | True when the identifier resolves to a CELLAR work; false when a well-formed CELEX/ELI matches no work in the corpus. A malformed or undetectable identifier raises ambiguous_identifier instead. |
| work_uri | No | CELLAR work URI (stable resource identifier). |
| celex_number | No | Confirmed CELEX number for the resolved work. |
| resource_type | No | CDM resource type URI indicating the document category (e.g. .../resource-type/REG for Regulation). Absent for some works. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context beyond these: it confirms existence, returns specific fields (work URI, confirmed CELEX number, document type, date), and handles both CELEX and ELI formats. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose and the second lists what is returned. It is front-loaded, efficient, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description is complete. It covers the tool's role as a validation step, what inputs it accepts, and what outputs it returns. No missing information needed for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented in the schema. The description adds marginal value by explaining the overall purpose of the parameters (resolving citations) but does not provide additional semantics beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('resolve', 'confirming it exists', 'returns') and clearly identifies the resource (EU legal citation - CELEX number or ELI URI) and its output (canonical CELLAR work, work URI, confirmed CELEX number, etc.). It distinguishes from siblings like eurlex_get_document or eurlex_search_documents by focusing on resolution and validation before fetching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: use this tool to confirm an EU legal citation exists before fetching or traversing it (e.g., before using eurlex_get_document). It provides clear context but does not explicitly state when not to use it or name alternatives, though siblings are listed in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurlex_query_sparqlRaw CELLAR SPARQL QueryARead-onlyInspect
Run a raw, read-only SPARQL SELECT against the CELLAR Virtuoso endpoint — an escape hatch for CDM ontology traversals the curated tools do not cover. Only SELECT is accepted; update forms and ASK/CONSTRUCT/DESCRIBE are rejected before execution, and results are capped at 100. The cdm:, skos:, and xsd: prefixes are auto-injected.
| Name | Required | Description | Default |
|---|---|---|---|
| sparql_query | Yes | A read-only SPARQL SELECT query. Leading comments and PREFIX/BASE declarations are allowed; the cdm:, skos:, and xsd: prefixes are auto-injected. LIMIT is injected at 100 if absent, or capped to 100. Key CDM predicates: cdm:resource_legal_id_celex (CELEX), cdm:work_date_document (date), cdm:work_has_resource-type (type), cdm:work_is_about_concept_eurovoc (EuroVoc subject), cdm:work_cites_work (citation). CELEX is an xsd:string literal — match it with FILTER(STR(?celex) = "…"). For text, use bif:contains with a single-quoted phrase. | |
| timeout_hint | No | Optional client-side timeout in milliseconds (1000–55000). Defaults apply when omitted; the endpoint hard limit is 60 seconds. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The server-enforced result ceiling that was applied. |
| shown | No | Number of binding rows returned in this response. |
| total | Yes | Number of binding rows returned (capped at 100 by the server). |
| bindings | Yes | Raw SPARQL binding rows. To extract a value from a row: row["varName"]?.value. Use the variables array to iterate in query order. |
| truncated | No | True when the server-enforced result ceiling capped the rows and more may exist upstream — narrow the query with FILTERs to see the rest. |
| variables | Yes | Variable names from the SELECT head, in query order. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), it discloses query form restrictions, result cap at 100, auto-injected prefixes, and endpoint behavior, adding significant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load purpose and restrictions; no wasted words despite dense information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a raw SPARQL tool and presence of output schema, the description covers query constraints, auto-injected prefixes, and example patterns, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by providing key CDM predicates, CELEX matching hints, and text search tips, though not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a raw read-only SPARQL SELECT against CELLAR Virtuoso as an escape hatch for CDM ontology traversals, distinguishing it from curated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when to use (escape hatch) and specifies that only SELECT is accepted, but does not explicitly list when not to use or compare directly to each sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurlex_search_documentsSearch EU DocumentsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–100). Defaults to 20. | |
| offset | No | Pagination offset — number of results to skip. Defaults to 0. | |
| date_to | No | End of date range (YYYY-MM-DD), matched against document date. Omit for no upper bound. | |
| keyword | No | Keyword matched against English document titles via the full-text index (multi-word input is treated as a phrase), or against CELEX substrings. | |
| in_force | No | If true, restrict to acts currently in force. Omit to return all regardless of in-force status. | |
| date_from | No | Start of date range (YYYY-MM-DD), matched against document date. Omit for no lower bound. | |
| document_type | No | Document type: REG=Regulation, DIR=Directive, DEC=Decision, TREATY=Treaty, JUDG=Judgment, OPIN_AG=AG Opinion, PROP=Proposal, REC=Recommendation. Omit to search all types. A type filter excludes consolidated texts (CONS_TEXT) — set include_consolidated to fold them back in. | |
| eurovoc_concept | No | EuroVoc concept URI to filter by subject (e.g. http://eurovoc.europa.eu/2828), obtained from eurlex_browse_subjects. Omit for no subject filter. | |
| author_institution | No | Author institution name (e.g. "European Parliament", "Council", "European Commission"), matched against the English names of EU corporate bodies. | |
| include_consolidated | No | When true and document_type is set, also match consolidated texts (CONS_TEXT) of that type — point-in-time versions that a plain type filter omits. No effect when document_type is omitted. Consolidated rows are always tagged is_consolidated: true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied to this page. |
| shown | No | Number of documents returned in this page. |
| total | Yes | Number of documents returned in this page (not a corpus-wide count). |
| offset | Yes | Pagination offset used for this response. |
| documents | Yes | Matching EU documents ordered by date descending. |
| truncated | No | True when the returned page was capped at the limit and more documents may exist. |
| query_echo | Yes | Echo of filters applied to this search. Useful for diagnosing empty results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and openWorldHint annotations, describes key behaviors: returns newest-first page, is_consolidated flag, document_type excludes consolidated unless include_consolidated set, and keyword limitation. Adds substantial value over annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph of 6 sentences, front-loaded with purpose. Every sentence adds information, though could be slightly better organized into sections for filtering vs. return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral points: required filters, no full-text, sorting, is_consolidated flag, and type/consolidated interaction. Output schema handles return value details. Missing explicit pagination note, but schema covers limit/offset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds extra context on parameter interactions (document_type + include_consolidated) and keyword limitations, raising the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Search' and specific resource 'EU legislation, treaties, and preparatory acts across the CELLAR corpus'. Lists multiple filtering dimensions (document type, date range, etc.) and distinguishes from siblings like eurlex_browse_subjects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: at least one filter required, keyword matches titles/CELEX only, no full-text body search. Does not explicitly name alternative tools for excluded cases (e.g., full-text search), so lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!