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.4/5 across 7 of 7 tools scored.
Each tool targets a distinct resource or action: subject browsing, case search, document retrieval, relation traversal, identifier resolution, raw SPARQL, and legislation search. The few potentially similar tools (search_documents vs get_cases) are clearly separated by corpus and description.
All tools follow the consistent eurlex_verb_noun pattern in lowercase snake_case, such as eurlex_get_document, eurlex_search_documents, and eurlex_lookup_celex. Verbs vary but the pattern is uniform and predictable.
Seven tools is well-scoped for an EU legal research server covering search, retrieval, relationship traversal, and identifier resolution. Each tool has a clear role and none feel redundant or excessive.
The core research workflow is covered: browse subjects, search legislation, search cases, fetch documents, resolve identifiers, and traverse relations. Minor gaps exist such as no full-text body search and no explicit case-law full-text retrieval, but the raw SPARQL escape hatch partially mitigates these.
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. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of concepts returned in this response. |
| total | No | Number of concepts returned in this response. |
| offset | No | Pagination offset used for this response. |
| concepts | No | 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 already declare readOnlyHint, openWorldHint, and idempotentHint, so the description need not repeat those. It adds value by specifying the returned fields (URI, label, code, broader label) and the alphabetical ordering, which are not in the schema. 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?
Two sentences with no filler; the purpose and output are front-loaded. Every word earns its place.
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?
For a read-only browse tool with annotations covering safety and an output schema present, the description covers purpose, output details, and usage context. An agent receives everything needed to invoke it correctly, including how the results integrate with the search tool. No significant gaps.
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 schema fully documents each parameter. The description adds a small amount of context (e.g., 'resolving a keyword' clarifies the keyword's purpose, and 'usable in filter' suggests how the output is consumed), but does not meaningfully enrich individual parameter 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 states a specific verb ('Search'), resource ('EuroVoc thesaurus'), and the intended use (resolving keywords to concept URIs for the eurovoc_concept filter). It clearly distinguishes this from sibling search tools by explaining the output's role in eurlex_search_documents. No ambiguity about the tool's function.
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 ties the output to the eurovoc_concept filter of eurlex_search_documents, implying this is the tool to use when you need subject concepts for a search filter. It does not explicitly list when not to use it or alternatives, but the use case is clear enough for an agent. It stops short of naming sibling tools or conditions, but provides sufficient context.
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 | No | Matching case law records ordered by date descending. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of cases returned in this page. |
| total | No | Number of cases returned in this page (not a corpus-wide count). |
| offset | No | 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 | No | 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 transparently discloses the default behavior (excluding derivative records) and the scope of keyword matching (no full-text search). It also describes the return structure. Since annotations already indicate read-only and open-world, no side effects are expected, and the description adds useful 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 paragraph that efficiently covers purpose, behavior, and output, but it is somewhat dense and could benefit from bullet points for readability. It is not overly verbose and stays focused on essential facts.
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 that the schema fully documents all parameters and an output schema exists, the description is complete. It adds valuable context about the default derivative exclusion, keyword matching scope, and the parsed fields in results, ensuring an agent has all necessary information to use the tool 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?
The input schema already provides comprehensive descriptions for all 9 parameters with 100% coverage. The description does not add significant new information about parameters beyond reinforcing what is in the schema, such as the include_derivative flag's effect. Therefore, it meets the baseline but does not exceed it.
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's purpose: searching CJEU and General Court case law with specific filters (case number, court, case type, keyword, date range). It is specific and distinguishes it from other sibling tools by focusing on case law, not documents or 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 explains the tool's behavior (e.g., default exclusion of derivative records, keyword matching only on titles and CELEX strings) but does not explicitly mention when to use this tool instead of siblings like eurlex_search_documents or eurlex_lookup_celex. This leaves some ambiguity for an agent deciding between similar search tools.
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. Ordinary offset-based paged windows and full-mode windows are capped at 100,000 characters; page with offset/limit to reconstruct larger acts, or 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. Follow has_more and the returned offsets until false to reconstruct the complete body. | |
| 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 | One of the 24 supported two-letter EUR-Lex language codes (e.g. EN, FR, DE), accepted case-insensitively and normalized to uppercase. 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 an offset/limit window; "full" requests from the start and returns at most 100000 characters with continuation metadata when more exists; "metadata_only" skips the content fetch. offset and limit apply only to "paged". | paged |
| Name | Required | Description |
|---|---|---|
| cap | No | Maximum body characters allowed in the window. |
| date | No | Document date in ISO 8601 format (YYYY-MM-DD). |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of body characters returned. |
| title | No | Document title in the requested language (absent for some older works and judgments). |
| notice | No | How to retrieve the remaining document content. |
| content | No | Body content of the act in the requested format and language. In "paged" mode this is the requested window; in "full" mode it starts at zero and is capped at 100000 characters. 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 | No | True when body content exists beyond the returned window. Continue in "paged" mode with offset = content_offset + content_chars_returned until false. Always false in "metadata_only" mode. |
| in_force | No | Whether the act is currently in force. |
| language | No | 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. |
| truncated | No | True when the returned body window was capped. |
| legal_basis | No | Legal basis acts for this work. |
| celex_number | No | Confirmed CELEX number for the retrieved work. |
| content_mode | No | 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 | No | 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. |
| content_status | No | Body resolution status: "not_requested" for metadata-only calls, "available" when a body was resolved, or "unavailable" after ordinary resolution attempts returned no usable body. |
| 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 | No | 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. |
| requested_language | No | Originally requested language code when English fallback changed the effective language reported in language. |
| 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. |
| content_unavailability_reason | No | Why content_status is "unavailable": no representation exists, the upstream request failed, or a multipart Formex body could not be assembled completely. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description exceeds the annotations by disclosing the 100,000-character window cap, format-specific offsets, outline/select behavior, resolve/consolidation semantics, and automatic language fallback. The readOnlyHint, openWorldHint, and idempotentHint annotations are fully consistent with the described behavior.
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?
Every sentence is informative and there is no fluff, but the main description is a dense single paragraph covering many interacting behaviors. A bulleted or more sectioned structure would aid scanning; however, the length is justified by the tool's 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?
The description covers identifier selection, formats, language, content modes, pagination, section selection, consolidation behavior, and edge cases such as selection misses and empty outlines. With an output schema also present, no call-relevant gap remains.
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?
The schema already covers all 11 parameters with rich descriptions (100% coverage), so the baseline is 3. The prose still adds cross-parameter workflow guidance — page/offset/limit reconstruction, the outline-then-select pattern, and the need to keep format constant when paging — which helps an agent select and combine parameters correctly.
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 opens with a specific verb ('Fetch') and resource ('metadata and full text of an EU act'), names three exact identifier types (CELEX number, ELI URI, work URI), and enumerates the returned metadata plus content formats. This clearly distinguishes it from sibling search/lookup/relations tools by identifying the precise input and output.
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?
Clear context is provided for direct retrieval by known identifier, and the description explains how to handle large acts via paging, outline, and select. It does not explicitly name sibling alternatives or exclusion conditions (e.g., 'use search when you do not have an identifier'), so it stops short of a 5.
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. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of relations returned in this page. |
| total | No | 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 | No | Pagination offset applied to this response (per relation type and direction). |
| work_uri | No | CELLAR URI of the source work (the work_uri input, or resolved from the CELEX). |
| relations | No | 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 | No | 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 | No | 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 already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds meaningful behavioral context beyond these: it clarifies that only one-hop direct relations are returned, that pagination is applied per relation type and direction, and that a CELEX or work URI is required for traversal. This adds value without contradicting any annotation.
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, then the scope constraint. Every clause contributes: it states what relations are covered, that only direct relations are returned, the pagination model, and the identification requirement. 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?
Given the 5 parameters (all documented in schema) and the existence of an output schema, the description is complete. It states the exact scope (one-hop, direct relations), the relation types available, pagination behavior, and the required input form. An agent has everything needed to call this tool 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?
Schema description coverage is 100%, so the baseline is 3. The description itself does not add parameter details beyond what the schema already provides; it only reinforces the mutual exclusivity of celex_number and work_uri, which is also stated in each parameter's description. The schema carries the heavy lifting, so no bonus is warranted.
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 opens with a specific verb and resource: 'Traverse the one-hop CDM relationship graph of an EU act' and enumerates the exact relation types (amends, repeals, consolidated versions, legal basis, citations). This is unambiguous and clearly differentiates from sibling tools like eurlex_get_document (fetch full document) or eurlex_search_documents (text search).
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 clear context: it returns direct relations only, is paginated per type/direction, and requires a CELEX number or CELLAR URI. It does not explicitly name alternatives or state when NOT to use it, but the scope statement effectively distinguishes it from siblings. No explicit exclusion is provided, so a 4 is appropriate rather than 5.
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). |
| error | No | Present when the call failed. Absent on success. |
| found | No | 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, and idempotentHint. The description adds valuable behavioral context: it confirms existence, returns a canonical/confirmed resolution, and lists the specific return fields. It does not contradict 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 compact and front-loaded: the first sentence states the core purpose and usage, and the second lists the key return values. Every clause earns its place with no redundant filler.
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?
For a simple two-parameter resolution tool with rich annotations and an output schema, the description fully covers what an agent needs: what to pass, why to call it, when to call it, and what to expect back. No critical contextual gap remains.
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 schema already fully documents both parameters. The description's mention of CELEX/ELI inputs mirrors the schema rather than adding new meaning. A baseline score of 3 is appropriate since the schema carries the semantic load.
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 identifies the action ('Resolve'), the input (CELEX number or ELI URI), and the output (canonical CELLAR work URI, confirmed CELEX, document type, date). It also distinguishes the tool from siblings by framing it as a pre-flight confirmation step before fetching or traversing.
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 clear usage context: use this tool when you need to confirm an EU legal citation exists and resolve it before fetching or traversing. It does not explicitly name sibling alternatives or state when not to use it, but the intended placement in a workflow is evident.
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. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of binding rows returned in this response. |
| total | No | Number of binding rows returned (capped at 100 by the server). |
| bindings | No | 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 | No | 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=true and openWorldHint=true. The description adds concrete behavioral details beyond that: only SELECT is accepted, results are capped at 100, prefixes are auto-injected, and a timeout_hint parameter is described. It does not contradict annotations and provides useful operational 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?
The description is well-structured and front-loaded with purpose and constraints. Every sentence adds value—constraints, behavioral details, parameter guidance—without redundancy. Length is appropriate for the complexity of a raw SPARQL tool.
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 output schema exists (so return values need no explanation), the description covers everything an agent needs: accepted query forms, result caps, endpoint limits, timeout options, and practical query-writing guidance. It is complete for safe and effective 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?
Schema coverage is 100%, but the description significantly enriches the sparql_query parameter with syntax rules (leading comments, PREFIX/BASE allowed), LIMIT behavior, auto-injected prefixes, and a list of key CDM predicates with matching tips (e.g., CELEX matching, bif:contains). This goes well beyond the schema description.
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 a specific action (run a raw, read-only SPARQL SELECT) against a specific resource (CELLAR Virtuoso endpoint), and frames it as an 'escape hatch' for traversals the curated tools do not cover, distinguishing it from siblings.
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 an explicit when-to-use condition: 'an escape hatch for CDM ontology traversals the curated tools do not cover.' It also imposes constraints (only SELECT, rejection of other forms) that inform usage. However, it does not explicitly name alternative tools or provide when-not-to-use guidance beyond the curated-tools-cover case, leaving some inference required.
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 category: REG=Regulations, DIR=Directives, DEC=Decisions, TREATY=Treaties, JUDG=Judgments, OPIN_AG=AG Opinions, PROP=Proposals, REC=Recommendations. Each category includes its explicit CELLAR authority variants (for example, delegated and implementing regulations). Omit to search all types. Consolidated texts are excluded unless include_consolidated is true. | |
| eurovoc_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 whose basic act belongs to that document category. 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. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Number of documents returned in this page. |
| total | No | Number of documents returned in this page (not a corpus-wide count). |
| offset | No | Pagination offset used for this response. |
| documents | No | 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 | No | 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 annotations already provide readOnlyHint and openWorldHint, so no contradiction exists. The description adds valuable behavioral detail beyond those annotations: keyword matching is limited to English titles and CELEX strings with no full-text body search, results are returned newest first with a page of CELEX numbers, work URIs, type labels, dates, titles, and an is_consolidated flag, and a filter must be supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler. It front-loads the tool's purpose, follows with the key search limitation, then the return shape and ordering, and ends with the essential usage requirement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 10 optional parameters, high schema coverage, and presence of an output schema, the description is sufficiently complete. It provides the central search workflow, the mandatory-filter rule, the crucial absence of full-text body search, and an accurate summary of the result payload, leaving no critical gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds non-obvious parameter semantics: it specifies that keyword matching is limited to English titles and CELEX strings, explicitly rules out full-text body search, and imposes the global constraint that at least one filter is required. These details meaningfully augment the already rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search EU legislation, treaties, and preparatory acts across the CELLAR corpus.' It also distinguishes itself from sibling retrieval/search tools by stating that keyword matches target titles and CELEX strings only, and that there is no full-text body search, making its role as a structured search endpoint clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear invocation context: searching by document type, date range, EuroVoc subject, author institution, and in-force status, plus the explicit constraint that at least one filter is required. However, it does not name sibling tools or explicitly state when to prefer alternatives such as eurlex_get_document or eurlex_query_sparql.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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.