Skip to main content
Glama

eurlex_sparql

Read-onlyIdempotent

Run read-only SPARQL 1.1 queries directly against the EU Publications Office Cellar endpoint when standard EUR-Lex tools cannot express a specific CDM ontology search.

Instructions

Expert escape hatch: run a raw, read-only SPARQL 1.1 query directly against the EU Publications Office (Cellar) endpoint when the higher-level tools (eurlex_search, eurlex_metadata, eurlex_citations, eurlex_case_law, eurlex_transposition, eurlex_summary, …) cannot express what you need. Requires knowledge of the CDM ontology — READ THE eurlex_guide PROMPT FIRST for the property cheat sheet (celex, title, language, dates, citations, case law, transposition, summaries). Only SELECT and ASK are allowed; SPARQL Update (INSERT/DELETE/…) and federated SERVICE clauses are rejected before the query is sent. A SELECT with no top-level LIMIT gets LIMIT 50 appended (set limit_added); a top-level LIMIT above 100 is rejected. The response mirrors SPARQL JSON — vars + bindings for SELECT, boolean for ASK — plus row_count and a truncated flag (whole rows are dropped past ~40k characters). CELEX/ELI literals are typed xsd:string, so match them with FILTER(STR(?x) = "..."). Example: PREFIX cdm: http://publications.europa.eu/ontology/cdm# SELECT ?celex WHERE { ?w cdm:resource_legal_id_celex ?celex . FILTER(STR(?celex) = "32016R0679") } LIMIT 1

Input Schema

NameRequiredDescriptionDefault
queryYesA raw SPARQL 1.1 query against the EU Publications Office (Cellar) endpoint. Read-only: only SELECT and ASK are accepted (SPARQL Update and federated SERVICE clauses are rejected). If a SELECT has no top-level LIMIT one is appended automatically; a top-level LIMIT above 100 is rejected. Uses the CDM ontology — see the eurlex_guide prompt for the property cheat sheet. Example: PREFIX cdm: <http://publications.europa.eu/ontology/cdm#> SELECT ?celex WHERE { ?w cdm:resource_legal_id_celex ?celex . FILTER(STR(?celex) = "32016R0679") } LIMIT 1

Output Schema

NameRequiredDescriptionDefault
varsNoProjected variable names (SELECT only)
booleanNoASK result (present only for ASK queries)
bindingsNoRaw SPARQL binding rows, possibly truncated (SELECT only)
row_countYesTotal rows the query returned; null for ASK
truncatedYesTrue when whole rows were dropped to fit the char budget
limit_addedNoPresent (true) only when the tool auto-appended the default LIMIT
returned_rowsYesRows included after char-budget truncation; null for ASK

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.4.4
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / bindings / items / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / properties / returned_rows / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maximum": 9007199254740991,
      +    "minimum": -9007199254740991,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedOutput schema / properties / row_count / anyOf
      Previous value: -[
      -  {
      -    "type": "integer"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "maximum": 9007199254740991,
      +    "minimum": -9007199254740991,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. Addedv2.4.2
  3. Removedv2.3.0
  4. First observedv2.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds substantial operational context beyond them. It discloses automatic LIMIT 50 appending, rejection of top-level LIMIT above 100, SPARQL JSON response shape, row_count and truncated behavior, and the ~40k character truncation rule.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, and the remaining sentences each carry operational value: prerequisites, allowed query types, limit behavior, response format, literal typing, and a concrete example. It is dense but not redundant for a complex expert tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the single free-form query parameter, the description is complete enough to call correctly. An output schema exists, and the description still explains response shape and truncation, while also covering safety constraints, query limits, and ontology prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the single query parameter and many constraints. The description still adds useful query-building semantics, especially the CDM ontology guide reference and the caveat that CELEX/ELI literals are typed xsd:string and should be matched with FILTER(STR(?x) = ...).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: run a raw, read-only SPARQL 1.1 query against the EU Publications Office Cellar endpoint. It explicitly distinguishes itself from named higher-level siblings and frames itself as an expert escape hatch for cases they cannot express.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use this tool versus alternatives: only when eurlex_search, eurlex_metadata, eurlex_citations, and others cannot express the need. It also gives prerequisites and exclusions, including reading the eurlex_guide prompt first and disallowing SPARQL Update or federated SERVICE clauses.

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