Search EU legislation, CJEU case law, and treaties; traverse CELLAR graph; browse EuroVoc concepts.
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.
Average 4.5/5 across 7 of 7 tools scored.
Each tool targets a distinct function: thesaurus browsing, case law search, document fetching, relationship traversal, citation resolution, SPARQL escape hatch, and legislative search. No overlap in purposes.
All tools follow a consistent 'eurlex_verb_noun' pattern (e.g., browse_subjects, get_document, search_documents). The pattern is uniform and predictable.
7 tools is well-scoped for an EU legal domain, covering essential operations without unnecessary bloat. Each tool has a clear role.
Covers discovery, retrieval, and relationship exploration. Missing full-text body search and CRUD operations (but read-only is appropriate). The raw SPARQL escape hatch fills gaps.
eurlex_browse_subjectsBrowse EuroVoc SubjectsASearch 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 |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) are already present and consistent. The description adds useful behavioral details: returns concept URI, label, code, broader label, ordered alphabetically, and respects language. No contradictions.
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, well-structured sentence that packs purpose, usage, and output details without fluff. Front-loads key action and 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 simplicity (4 params, 1 required, output schema exists), the description fully covers what the agent needs: purpose, linkage to another tool, and output format.
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 descriptions cover all parameters (100% coverage). The description adds context for the keyword parameter ('resolving a keyword') but doesn't add significant meaning beyond the schema. 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 it searches the EuroVoc thesaurus and returns concept URIs for use in document searches. It distinguishes from siblings like eurlex_search_documents by focusing on subjects rather than documents.
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 states the output is usable in the eurovoc_concept subject filter of eurlex_search_documents, linking tools effectively. No explicit when-not-to-use or alternatives, but the context is clear enough for appropriate selection.
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 LawASearch 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). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond readOnlyHint and openWorldHint: describes search scope (no full-text body), default exclusions, and return fields (parsed from title). 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?
Concise, front-loaded with purpose, every sentence adds necessary information. No redundant or missing elements.
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 output schema, description covers search behavior, exclusions, keyword scope, and return fields. Complete for an AI agent to use effectively.
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 100%, but description adds value by explaining keyword behavior, include_derivative default logic, and that parties/subject are parsed from title. Goes 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 clearly states 'Search CJEU and General Court case law' with specific resources (judgments, orders, AG opinions) and search criteria. Distinct from sibling tools like eurlex_search_documents which likely cover broader legal documents.
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?
Explains default behavior (primary records only, derivative excluded), when to use include_derivative, and keyword matching scope. Lacks explicit comparison to siblings but 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_documentGet EU DocumentAFetch 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 |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: paging with format-specific offsets, language fallback, selection behavior with Roman/Arabic numbers, and outline offset handling. 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 efficient, with each sentence adding value. It is front-loaded with the core purpose. However, it could be slightly more structured (e.g., using bullet points for different modes), but it remains clear and concise.
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 exists), the description is thorough. It covers all modes (paged, full, metadata_only), edge cases (format-specific offsets, missed selections), and parameter interactions. It is complete for an AI agent to use correctly.
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 still adds significant meaning to each parameter. It explains how select works with Roman/Arabic numbers, how outline offsets are format-specific, and the interaction between content_mode, offset, limit. This is well beyond what the schema provides.
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, ELI, or work URI. It distinguishes from siblings by listing multiple identifier types and output formats.
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 this tool (fetching a document by specific identifiers) and provides guidance on various parameters (content_mode, select, outline). It implicitly differentiates from sibling tools like eurlex_search_documents and eurlex_lookup_celex, but lacks explicit when-not-to-use scenarios.
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 GraphATraverse 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). |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations classify the tool as read-only, idempotent, and open-world. The description adds behavioral context: pagination with truncation when capacity is filled, ordering of incoming edges, and the need for offset to page for older works. This aligns with the annotations and provides extra detail.
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 only three sentences, each carrying necessary information: purpose, behavior (direct, paginated), and input requirement. No redundancy or filler; front-loaded with the most critical 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 tool's complexity (multiple relation types, pagination, idempotent) and the presence of an output schema (not shown), the description covers all essential aspects: what to expect, how to paginate, and required identifiers. It does not discuss error handling or status codes, but that is acceptable for a read-only tool.
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%, but the description adds value by explaining the mutual exclusivity of celex_number and work_uri, the pagination mechanics (ordering, offset behavior), and the meaning of the relation_types enum. This goes beyond the schema 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 a specific verb ('Traverse') and resource ('one-hop CDM relationship graph of an EU act'), listing concrete relation types. It clearly distinguishes this tool from siblings like eurlex_get_document (retrieves content) or eurlex_search_documents (searches), which have different purposes.
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 states the required input (CELEX number or CELLAR work URI) and notes that only direct relations are returned, paginated per type and direction. While it doesn't explicitly say when not to use it (e.g., for multi-hop traversal), the sibling context and specificity make the usage context clear.
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 CitationAResolve 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 |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context: it confirms existence before fetching/traversing and specifies the returned fields. No 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?
Two concise sentences: first states purpose and behavior, second lists output. No wasted words. Front-loaded with essential 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?
Output schema exists (mentioned but not shown), description lists returned fields. Parameters fully documented in schema. Annotations cover safety. Complete for a lookup/resolution tool.
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% (both parameters have descriptions). The description only mentions 'CELEX number or ELI URI' and enum values, adding minimal extra meaning 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 specifies resolving an EU legal citation (CELEX or ELI) to canonical metadata, with clear verb ('resolve') and resource ('EU legal citation'). It distinguishes from siblings like eurlex_get_document (which fetches content) and eurlex_search_documents (which searches).
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 says 'confirming it exists before you fetch or traverse it', giving clear context for when to use (as a prerequisite). It implies alternatives but does not explicitly exclude or name them, though sibling tools are listed separately.
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 QueryARun 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that only SELECT is accepted, results are capped at 100, and prefixes are auto-injected. 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?
Two sentences with no wasted words. Front-loaded with purpose, immediately followed by constraints. 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 full schema coverage, annotations, and presence of an output schema, the description sufficiently discloses behavioral traits (query type, result limit, prefix injection) without needing to explain return values.
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%. The description adds significant detail: for sparql_query, it explains allowed prefixes, LIMIT handling, and gives examples of CDM predicates and bif:contains syntax. For timeout_hint, it clarifies defaults and endpoint hard limit.
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 read-only SPARQL SELECT against CELLAR Virtuoso, serving as an escape hatch for CDM ontology traversals not covered by curated tools. This distinguishes it from siblings like eurlex_search_documents and eurlex_lookup_celex.
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 states when to use (curated tools do not cover) and what is accepted/rejected (only SELECT, no update forms or other SPARQL forms). Mentions result cap at 100, though does not explicitly name alternative tools for comparison.
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 DocumentsASearch 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: no full-text body search, results sorted newest first, each result flagged with is_consolidated, and consolidated texts omitted by default when document_type is set unless include_consolidated is true. These details complement the readOnlyHint and openWorldHint 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?
The description is a single focused paragraph that front-loads the core purpose and key limitations. Every sentence adds unique information—search scope, keyword behavior, return format, required filters—without redundancy or fluff.
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?
Despite 10 parameters and no output schema visible, the description covers retrieval fields (CELEX numbers, URIs, dates, titles, is_consolidated flag), ordering (newest first), pagination (a page), and required filters. It addresses the key constraints and return structure sufficiently for agent invocation.
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?
All 10 parameters have descriptions in the input schema, achieving 100% coverage (baseline 3). The description adds value by explaining the interaction between document_type and include_consolidated, and specifying the keyword behavior (phrase matching, CELEX substring). This extra context elevates the score above baseline.
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 EU legislation, treaties, and preparatory acts across the CELLAR corpus by multiple criteria. It specifies the search scope and return fields, and the name and title align with the purpose. It distinguishes from sibling tools like eurlex_get_document (retrieval) and eurlex_browse_subjects (subject browsing).
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 notes that at least one filter is required and clarifies that keyword search is limited to English titles and CELEX substrings—no full-text search. It provides context for when to use EuroVoc concepts from eurlex_browse_subjects. However, it does not compare directly to alternatives like eurlex_lookup_celex or eurlex_get_document for single-document retrieval.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.