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
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.6/5 across 7 of 7 tools scored.
Most tools have distinct purposes: search legislation vs. case law, fetch document vs. lookup identifier, browse subjects, traverse relations, and raw SPARQL. There is minor overlap between eurlex_get_relations and eurlex_query_sparql, but descriptions clarify when to use each, so ambiguity is low.
All tool names follow a consistent 'eurlex_verb_noun' pattern using snake_case (e.g., eurlex_browse_subjects, eurlex_get_document). The verbs and nouns are uniformly descriptive, making the set predictable and easy to navigate.
With 7 tools, the set is well-scoped for the domain of EU legal documents. It covers searching, fetching, identifier resolution, subject browsing, relationship traversal, and advanced SPARQL queries without being overwhelming or insufficient.
The tool set covers all essential operations for EU law access: search legislation and case law, fetch documents, resolve identifiers, browse EuroVoc subjects, traverse legal relationships, and execute raw SPARQL for custom needs. No obvious gaps given the underlying API's limitations.
Available Tools
7 toolseurlex_browse_subjectsBrowse EuroVoc SubjectsARead-onlyIdempotentInspect
Search the EuroVoc multilingual thesaurus to resolve a human-readable term or keyword into EuroVoc concept IDs. This tool is required before using the eurovoc_concept filter in eurlex_search_documents — agents cannot guess numeric EuroVoc concept IDs. Returns concept URI, preferred label in the requested language, concept code, and broader/narrower hierarchy hints. EuroVoc covers all EU policy domains: agriculture, environment, finance, health, trade, transport, and more. If no results are found in a non-English language, retry with language "en" and a broader English term.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of EuroVoc concepts to return (1–50). Defaults to 20. | |
| 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"). Defaults to English. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of concepts returned in this response. |
| concepts | Yes | Matching EuroVoc concepts ordered by relevance of the label match. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context beyond annotations: it returns concept URI, preferred label, concept code, broader/narrower hierarchy hints, and covers all EU policy domains. The retry advice further clarifies behavior. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with multiple sentences, front-loaded with purpose. Every sentence adds value: purpose, prerequisite role, return fields, domain coverage, and fallback. Could be slightly more structured (e.g., bullet points), but it is concise and efficient.
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 simplicity (3 params, good annotations, output schema exists), the description is comprehensive. It covers workflow context (prerequisite for search), thesaurus scope, return information, and error recovery. No gaps identified.
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 all three parameters described in the schema. The description adds limited additional semantics: clarifies that keyword matches against labels, language is for labels, and limit is for max number. The retry advice and return fields are contextual but not directly parameter semantics. Baseline 3 is appropriate.
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 verb 'search' and the resource 'EuroVoc multilingual thesaurus' with the purpose of resolving keywords to concept IDs. It explicitly distinguishes itself from sibling tools by noting it is required before using the eurovoc_concept filter in eurlex_search_documents, which agents cannot guess numeric IDs.
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 gives explicit when-to-use guidance: required before using eurovoc_concept filter in eurlex_search_documents. It also provides a fallback strategy for non-English searches: retry with English and a broader term. While it does not explicitly state when not to use, the 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_get_casesSearch CJEU/GC Case LawARead-onlyInspect
Search CJEU (Court of Justice of the EU) and General Court case law — judgments, orders, and Advocate General opinions. Distinct from eurlex_search_documents because case law uses CELEX sector 6 and practitioners search it differently: by case number, court, party name, or AG opinion type. Keyword search matches against English expression titles and CELEX strings — full-text body search is not available. Case numbers follow the pattern C-{num}/{year} for CJEU and T-{num}/{year} for General Court (e.g. C-131/12). Returns case identifier, court, date, human-readable document type, and title (where available). Use eurlex_get_document with the CELEX number to fetch the full judgment text.
| Name | Required | Description | Default |
|---|---|---|---|
| court | No | Court filter: CJEU = Court of Justice of the EU, GC = General Court. | |
| 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). | |
| keyword | No | Keyword to match against case titles and CELEX strings. | |
| case_type | No | Case type filter: judgment, order (procedural decision), or ag_opinion (Advocate General opinion). | |
| date_from | No | Start of date range in ISO 8601 format (YYYY-MM-DD). | |
| 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cases | Yes | Matching case law records ordered by date descending. |
| total | Yes | Number of cases returned in this page (not a corpus-wide count). |
| offset | Yes | Pagination offset used for this response. |
| 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?
The description transparently discloses that keyword search only matches English titles and CELEX strings (not full text), and lists the returned fields (case identifier, court, date, document type, title). Annotations already set readOnlyHint=true, and the description aligns 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 appropriately detailed without redundancy. Every sentence serves a purpose: stating the tool's function, differentiating it from siblings, explaining search behavior, providing examples, and indicating next steps. It is front-loaded with key information and well-structured.
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 8 parameters, the presence of an output schema, and multiple sibling tools, the description covers all essential aspects: what the tool does, how to search, what it returns (referencing output schema), and what it does not do. It is complete for agent decision-making.
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%, so baseline is 3. The description adds semantic value beyond schema by explaining the usage context for parameters (e.g., case number pattern, keyword scope) and when to apply filters like court and case_type. It provides practical knowledge that the schema alone does not convey.
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 that the tool searches CJEU/GC case law, lists included document types (judgments, orders, AG opinions), and explicitly distinguishes it from eurlex_search_documents by referencing CELEX sector 6 and different search patterns.
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 provides explicit guidance on when to use this tool versus eurlex_search_documents, explains searchable fields (case number, court, party name, AG opinion type), notes limitations (no full-text search), and directs users to eurlex_get_document for full text.
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 notice (metadata) and full text of an EU act by CELEX number or ELI URI. Returns structured metadata — title, date, document type, author institution, legal basis, EuroVoc subjects — plus the HTML or Formex4 XML content in the requested language. Defaults to English (EN); not all works have content in all 24 official EU languages, especially older acts pre-2004 EU enlargement. If the requested language is unavailable, the server automatically falls back to English and notes the fallback. CELEX format: {sector}{year}{type}{number} e.g. 32016R0679 for GDPR. Use eurlex_lookup_celex to validate an identifier before calling this tool. HTML format returns the full act text suitable for reading; XML returns Formex4 for structured processing.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Content format: "html" for readable HTML text (default), "xml" for Formex4 XML structured format. | html |
| eli_uri | No | ELI URI as alternative to celex_number (e.g. http://data.europa.eu/eli/reg/2016/679/oj). Used only if celex_number is absent or empty. | |
| language | No | Language code for document content (ISO 639-1 uppercase, e.g. EN, FR, DE). Defaults to EN. Falls back to EN if the requested language is unavailable. | EN |
| celex_number | Yes | CELEX number of the act to fetch (e.g. 32016R0679 for GDPR). Preferred over eli_uri. |
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 | Full text content of the act in the requested format and language. |
| in_force | No | Whether the act is currently in force. |
| language | Yes | Language code of the returned content. |
| work_uri | No | CELLAR work URI. |
| legal_basis | No | Legal basis acts for this work. |
| celex_number | Yes | Confirmed CELEX number for the retrieved work. |
| 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" or "xml". |
| eurovoc_subjects | No | EuroVoc subject classifications. |
| content_available | Yes | Whether document content was successfully retrieved. |
| 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 originating EU institution (e.g. "European Parliament", "Council of the EU"). Absent when not recorded. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. Description adds valuable context: language fallback to English, availability limitations for older acts, and automatic fallback notification. Does not cover error handling for missing documents, but this is minor given 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?
Five sentences, each sentence adds essential information. Front-loaded with main action. No redundant or vague wording. Perfectly concise for the complexity.
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 4 parameters, 100% schema coverage, output schema present, and rich annotations, the description covers identification methods, language fallback, format options, and prerequisite validation. No gaps for typical use cases.
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%, so each parameter is documented. Description adds: CELEX format example (32016R0679 for GDPR), priority of celex_number over eli_uri, and clarification of format options ('html' for reading, 'xml' for structured processing). Adds meaning beyond 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?
Description starts with a specific verb 'Fetch' and resource 'EU act by CELEX number or ELI URI'. It distinguishes itself from siblings like eurlex_lookup_celex (validation) and eurlex_search_documents (search), making the tool's purpose immediately clear.
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?
Explicitly advises to use eurlex_lookup_celex for identifier validation before calling this tool. Also mentions defaults and language fallback behavior. Lacks explicit 'when not to use' but provides clear context for proper usage.
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 CELLAR CDM relationship graph for an EU work: what it amends, what amends it, its current consolidated version, its legal basis, and works that cite it. This is CELLAR's primary value over HTML scraping — the graph traversal that exposes the lifecycle and dependencies of an EU act. Returns one-hop direct relations only. For deeper traversal, use eurlex_query_sparql. The "consolidated_version" relation links to the current consolidated text (a separate CELEX-numbered work); fetch that work with eurlex_get_document. Requires a valid CELEX number or CELLAR work URI — use eurlex_lookup_celex to resolve identifiers first.
| Name | Required | Description | Default |
|---|---|---|---|
| work_uri | No | CELLAR work URI as alternative to celex_number. Used if celex_number resolves to no work. | |
| celex_number | Yes | CELEX number of the work to traverse (e.g. 32016R0679). Preferred identifier. | |
| relation_types | No | Subset of relation types to return. Omit to return all types: cites (citation graph), amends (what this work amends), amended_by (what amends this work), legal_basis (treaty/treaty article this act is based on), consolidated_version (current consolidated text). |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total number of direct CDM relations returned. |
| work_uri | No | CELLAR URI of the source work (resolved from the CELEX number). |
| relations | Yes | Direct CDM relations for the requested work. |
| celex_number | Yes | CELEX number of the source work whose relations were traversed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent hints. Description adds that relations are one-hop direct, the consolidated_version link is to a separate work, and the tool returns relation types. It provides useful context beyond annotations 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?
Description is well-structured with front-loaded purpose, then listed relations, then usage notes. It is somewhat long but each sentence adds value. Could be slightly shorter, but effective.
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, presence of output schema, and annotations, the description is complete: it covers what relations are returned, how to use identifiers, and directs to sibling tools for deeper traversal or document retrieval. No gaps for the intended 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 coverage is 100%, so baseline 3. Description adds meaning by explaining the effect of omitting relation_types (returns all), the alternative use of work_uri, and that celex_number is preferred. It clarifies behavior beyond schema fields.
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 traverses the CELLAR CDM relationship graph for EU works, listing specific relations (amends, amended_by, etc.) and distinguishes itself from siblings like eurlex_query_sparql and eurlex_lookup_celex. It uses strong action verbs and resource identification.
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?
Explicitly tells when to use (one-hop direct relations) and when not (deeper traversal: use eurlex_query_sparql). It also states prerequisite: requires valid CELEX or CELLAR URI, with reference to eurlex_lookup_celex for resolution.
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 any EU legal citation — CELEX number, ELI URI, or Official Journal reference — to the canonical CELLAR work. Returns the work URI, confirmed CELEX number, document type, document date, and whether the work exists in the CELLAR corpus. Use this to validate identifiers before passing them to eurlex_get_document or eurlex_get_relations. CELEX format: {sector}{year}{type}{number} e.g. 32016R0679 (GDPR). ELI format: http://data.europa.eu/eli/{type}/{year}/{number}/oj. OJ format: OJ L 119 or L:2016:119.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | The EU legal citation to resolve: a CELEX number (e.g. 32016R0679), ELI URI, or Official Journal reference (e.g. OJ L 119). | |
| identifier_type | No | Format of the identifier. Use "auto" to let the server detect the format automatically. Supply explicitly if auto-detection fails or if the identifier is ambiguous. | auto |
Output Schema
| Name | Required | Description |
|---|---|---|
| date | No | Document date in ISO 8601 format (YYYY-MM-DD). |
| found | Yes | Always true on success (the tool throws not_found when the identifier does not resolve). Present as a discriminator for downstream logic. |
| 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 indicate read-only and idempotent behavior. The description adds context about what the tool returns (work URI, confirmed CELEX number, etc.) and its validation purpose, enhancing transparency 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 focused paragraph, efficient in conveying purpose and usage. It could be slightly more structured but remains concise and front-loaded.
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 an output schema exists, the description does not need to detail return types. It covers all necessary aspects: purpose, usage, parameter examples, and return fields, making it contextually 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?
Schema coverage is 100% with descriptions for both parameters. The description adds value by providing format examples (CELEX, ELI, OJ) and explaining the auto-detection feature, going beyond 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 explicitly states it resolves EU legal citations (CELEX, ELI, OJ) to canonical CELLAR work, and distinguishes itself from sibling tools by mentioning validation before using eurlex_get_document or eurlex_get_relations.
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 explicitly advises to use this tool to validate identifiers before other tools, providing clear usage context. However, it does not explicitly state when not to use it or elaborate on alternatives beyond the mentioned siblings.
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
Execute a raw SPARQL SELECT query against the CELLAR Virtuoso endpoint. Use only when the curated tools (eurlex_search_documents, eurlex_get_relations, etc.) do not cover the needed traversal. The server caps all queries at 100 results — include an explicit LIMIT in your query to control the count; if omitted or above 100 it will be injected or capped automatically. The CDM ontology prefix is prepended automatically: cdm: = http://publications.europa.eu/ontology/cdm#. Also auto-includes skos: and xsd: prefixes. Requires familiarity with the CELLAR CDM ontology. Key predicates: cdm:resource_legal_id_celex (CELEX number), cdm:work_date_document (date), cdm:work_has_resource-type (document type), cdm:work_is_about_concept_eurovoc (EuroVoc subject), cdm:work_cites_work (citation). Virtuoso does not support bif:contains for multi-word phrases; use FILTER(CONTAINS(LCASE(?title), "keyword")).
| Name | Required | Description | Default |
|---|---|---|---|
| sparql_query | Yes | A SPARQL SELECT query to execute against CELLAR. The cdm:, skos:, and xsd: prefixes are auto-injected. LIMIT is injected at 100 if absent or capped to 100 if above that threshold. | |
| timeout_hint | No | Optional client-side timeout hint in milliseconds (1000–55000). Defaults to server-configured SPARQL_QUERY_TIMEOUT_MS (55000). Virtuoso hard limit is 60 seconds. |
Output Schema
| Name | Required | Description |
|---|---|---|
| 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. |
| 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?
Discloses server cap at 100 results, automatic LIMIT injection/capping, prefix auto-injection, Virtuoso bif:contains limitation, and workaround using FILTER(CONTAINS(...)). No contradiction with readOnlyHint and openWorldHint 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?
Description is somewhat long but front-loaded with purpose and usage condition. Every sentence adds value; could be slightly more concise but still efficient.
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 SPARQL query execution, description covers purpose, usage conditions, technical constraints, prefixes, predicates, and text search workaround. Output schema exists, so return values are not needed.
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%, but description adds significant extra meaning: auto-injected prefixes, LIMIT behavior, and timeout hints. Provides key predicates for query construction.
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 verb ('Execute'), resource ('raw SPARQL SELECT query'), and target ('CELLAR Virtuoso endpoint'). It distinguishes from sibling tools by specifying 'only when the curated tools... do not cover the needed traversal.'
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?
Explicitly tells when to use ('only when the curated tools... do not cover the needed traversal') and names alternatives (eurlex_search_documents, eurlex_get_relations). Also provides guidance on query limits and auto-injection.
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 of 2.7M+ works. Filters by document type, date range, EuroVoc subject concept, author institution, and in-force status. Keyword search matches against English expression titles and CELEX strings — full-text body search is not available via this API. For multi-word searches, supply a single dominant keyword; use other filters to narrow results. Returns CELEX numbers, work URIs, human-readable document type labels, and dates — use these with eurlex_get_document to fetch full content. To filter by EuroVoc subject, first call eurlex_browse_subjects to obtain the concept URI. Case law (CJEU/GC judgments) is better searched via eurlex_get_cases which has court-specific parameters.
| 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 in ISO 8601 format (YYYY-MM-DD). Matches document date. | |
| keyword | No | Keyword to match against document titles. Single dominant word recommended; multi-word phrase uses substring match. | |
| 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 in ISO 8601 format (YYYY-MM-DD). Matches document date. | |
| document_type | No | Document type filter: REG=Regulation, DIR=Directive, DEC=Decision, TREATY=Treaty, JUDG=Judgment, OPIN_AG=AG Opinion, PROP=Proposal, REC=Recommendation. | |
| eurovoc_concept | No | EuroVoc concept URI to filter by subject (e.g. http://eurovoc.europa.eu/2828). Obtain concept URIs from eurlex_browse_subjects first. | |
| author_institution | No | Author institution name filter (e.g. "European Parliament", "Council"). Substring match. |
Output Schema
| Name | Required | Description |
|---|---|---|
| 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. |
| 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 readOnlyHint=true and openWorldHint=true are consistent with description's read-only search behavior. Description adds limitations (no full-text body) and describes output usage, 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?
Well-structured with two paragraphs: purpose/filters then usage tips. Front-loaded and informative, though slightly verbose with some repetition of schema info.
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 9 parameters and complex filtering, description covers key behaviors, output fields, and integration with sibling tools. Output schema exists, so return value explanation is sufficient.
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% so baseline 3. Description adds value by recommending single keyword for multi-word searches and clarifying substring match behavior, which is not in 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?
Clearly states the tool searches EU legislation, treaties, and preparatory acts across the CELLAR corpus. Distinguishes from siblings like eurlex_get_cases and 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?
Explicitly advises when to use alternatives (case law via eurlex_get_cases), instructs to call eurlex_browse_subjects for EuroVoc URIs, and provides keyword search tips. Also notes limitation of no full-text body search.
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!