Skip to main content
Glama

Lexiara

by org.lexiara

The same defined term in the act's other authentic languages

term_languages
Read-onlyIdempotent

How an act words one of its defined terms in each language version held. NOT a translation: an EU instrument is equally authentic in all 24 official languages (Regulation No 1/1958, article 4), so each wording is the law in that language. Use it to answer 'what do the German and French texts call this?' — e.g. 'commercial guarantee of durability' is 'gewerbliche Haltbarkeitsgarantie' and 'garantie commerciale de durabilité'.

The term may be given in ANY language held, so the German words find the English definition just as well as the other way round.

SCOPE: this is the EU act's own wording per language. It is NOT how a Member State's transposing legislation words it — a national implementation may lawfully choose different wording, and reaching it means following a transposition link that carries a method and a confidence (find_national_implementations). Nothing here is inferred.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termYesThe phrase, in any language held. Matched exactly (case-insensitive).
workNoScope to one instrument (ELI or official number).
limitNoMaximum terms, default 8.
jurisdictionNoISO country filter, e.g. 'UK', 'FR', 'EU'.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description explains the legal basis of equal authenticity, emphasizes that nothing here is inferred, and clarifies that the term may be entered in any language. This adds meaningful behavioral context beyond the annotations, which already mark the tool as read-only and idempotent.

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 description is structured into a definition, an example, a language-direction note, and a scope boundary. Every sentence contributes to correct use, and the most important distinction (not a translation, not national wording) appears early.

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?

Even without an output schema, the description conveys what will be returned, how the lookup behaves across languages, and what it deliberately does not cover. For a lookup tool with four parameters and one required, this is complete.

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

Parameters3/5

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

Schema coverage is 100%, so the description does not need to re-document parameters. It reinforces that the term can be in any language, which matches the schema's 'any language held' note, but adds little beyond that. Baseline 3 is appropriate.

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?

The description states exactly what the tool does: it returns how an act words a defined term in each held language version. It also distinguishes the tool from a translation service and from national transposing legislation, making its unique purpose unmistakable.

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?

It gives a concrete use case ('what do the German and French texts call this?') and an explicit negative boundary: this is not national implementation wording, so an agent is routed toward find_national_implementations when that is the actual need.

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

All Lexiara toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, and descriptions carefully separate overlapping areas such as definition lookup, cross-references, and transposition links. A few citation/graph tools (related_works, work_mentions, find_national_implementations, provision_context) could be confused at a glance, but their granularity and direction are explicitly differentiated.

Naming Consistency3/5

Naming follows a readable all-lowercase-snake_case style, but conventions are mixed: roughly half are imperative verb_object names (lookup_provision, search_legislation, list_topics) while the rest are bare noun-phrase view names (provision_context, recent_changes, work_mentions). The pattern is understandable but not uniform.

Tool Count4/5

At 18 tools, the set is slightly above the ideal 3-15 range, but each tool maps to a distinct research query or data product. The count is justified by the breadth of legal-research operations rather than redundancy.

Completeness5/5

The surface covers the domain thoroughly: search, provision lookup, definitions, multilingual terms, cross-references, amendment history, transposition links, topics, coverage, updates, and review workflows. The explicit read-only design means absent write operations are a deliberate boundary, not a gap.

Resources