Lex: Luxembourg Law MCP Server

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

With no annotations provided, the description carries the full burden. It discloses the tool's scope (single provision), includes lifecycle events (inserted/removed/renumbered), and notes the mechanical renumbering detection via identical text hash. This provides meaningful behavioral context beyond the schema, though it does not mention return format or error handling.

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 and front-loaded with the core function. The first sentence is somewhat dense, and the advice about reading timeline_semantics adds tangential context, but overall each sentence earns its place and the length is appropriate for 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?

Given no output schema and no annotations, the description gives a reasonable mental model (returns distinct texts and lifecycle events) but does not specify the exact return structure, pagination, or optional parameter interactions. It is adequate but leaves the agent to infer some details about the response format and edge cases.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context by emphasizing 'ONE provision' and the article-focused question, which helps understand the 'anchor' parameter, but it does not provide additional parameter-level detail beyond what the schema already documents.

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 ('has had') and identifies the resource (ONE provision's text and lifecycle events). It clearly answers the intended question, 'what did Article X say over its life / when did it change', and distinguishes from siblings like timeline by focusing on a single provision's history.

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

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

The description provides a clear use case (answering questions about a provision's historical text and change times) and preceding guidance about reading timeline_semantics for interval legal applicability. However, it does not explicitly name alternative tools for when not to use it, stopping short of full exclusion guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is a pure lookup with no ranking, explains the behavior of each mode (outline, select, full), the default mode, and mentions that every provision carries a permalink and hash. It lacks error-handling and authorization details, but for a read-only lookup this is transparent enough.

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 long and tightly packed with essential information. It front-loads the core purpose, then efficiently explains modes and output characteristics without any 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?

There is no output schema, but the description explains what is returned in each mode (whole text, outline, selected anchors' text) and notes the permalink/hash. It covers the main usage scenarios and parameter behavior, though error cases or special conditions are not mentioned. For a lookup tool with full schema coverage, this is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant meaning beyond the schema by explaining the semantics of 'mode' and 'anchors' (e.g., what outline vs. select returns, how anchors narrow results), which is not fully captured in 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 states the tool returns 'the state of one document as it stood on one date', which is a specific verb (lookup) and resource (document at a date). It also distinguishes from search/ranking by explicitly saying 'Pure lookup, no ranking.' This clearly differentiates it from sibling tools like search or timeline.

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

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

The description provides clear context for when to use the tool (historical document snapshot) and explains the different modes and anchoring, which guides usage. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a full 5.

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

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

No annotations are present, so the description carries the full burden. It discloses the aggregate behavior, ordering semantics (by_date vs by_churn), and implies read-only operation. It doesn't discuss side effects or pagination, but no side effects are expected and limit/offset are documented in the schema.

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?

Four sentences cover scope, result semantics, sibling differentiation, example queries, and ordering behavior. Every sentence contributes unique information with no filler or repetition.

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?

With 14 parameters and no output schema, the description provides the essential context: what the tool does, when to use it, and how ordering works. It doesn't explicitly mention pagination, but limit/offset are well-described in the schema. The description is sufficient for an agent to select and invoke 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?

Schema coverage is 100%, providing a baseline of 3. The description adds value by explaining the order parameter's values and default, and giving real-world examples that clarify how the parameters are used together. It avoids repeating 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 explicitly states the tool identifies 'which works gained new versions between two dates, how many each, and when' and contrasts it with diff/timeline which cover ONE work. This clearly distinguishes it from sister tools and defines the resource and action.

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?

It provides concrete example queries ('what changed between 2025 and 2026', 'which laws changed most during the pandemic') and explicitly names diff/timeline as alternatives for single-work queries, giving clear when-to-use and when-not-to-use guidance.

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

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

No annotations are present, so the description must disclose behavior itself. It states that the tool 'reports the publisher references Lex captured' and explicitly notes what it does NOT do (classify or assess legal effect), which is valuable context. However, it does not mention other behavioral traits such as authentication requirements or rate limits, but for a read-only lookup this is reasonably transparent.

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, front-loaded with the core purpose, and the second sentence clarifies limitations without unnecessary detail. Every word contributes 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?

For a simple lookup tool with no output schema, the description communicates both the result scope (held provision versions with publisher references) and its limitations. It lacks a concrete example or mention of pagination behavior, but the mention of 'captured publisher cross-references' provides sufficient context for an agent to select the 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 descriptions cover both parameters completely ('the law being cited' for work, 'default 50' for limit). The description adds no new parameter-specific guidance, but the baseline 3 applies given high schema coverage.

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 query: 'Which held provision versions contain captured publisher cross-references to this work,' clearly identifying the tool as a reverse citation lookup. It distinguishes this from sibling tools by emphasizing 'reverse lookup' and its focus on publisher references.

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 implies usage (reverse citation lookup) but does not explicitly state when to prefer it over alternatives or when not to use it. It does provide a limitation ('does not classify relationship type or assess current legal effect'), which hints at scope, but lacks explicit alternative comparisons.

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

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

With no annotations, the description is the only source of behavioral information. It does disclose return contents (counts, date ranges, history_begins, known gaps) and the tool's focus on missing data. However, it does not explain how the optional publisher filter affects results, what 'tier by tier' means, or any limitations/formatting.

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 concise at two sentences and includes useful specifics in the first sentence. However, it is slightly poetic ('tier by tier') and could be more direct, but it still earns its place without unnecessary 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?

Given the tool's simplicity (1 optional parameter, no annotations, no output schema), the description provides a reasonable overview but leaves gaps: it does not clarify the meaning of 'history_begins', how publisher filtering narrows results, or the grouping by tier. More detail would improve completeness.

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 documents the single optional parameter ('publisher' with description 'optional publisher id'), and schema description coverage is 100%. The description adds no additional meaning about how the publisher parameter is used, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: to report coverage (what we hold and lack) with specific output types (counts, date ranges, history_begins, known gaps). It distinguishes itself from siblings by explicitly focusing on gaps (what we do NOT have).

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 implies usage for checking coverage gaps ('This tool exists to say what we do NOT have'), but it does not explicitly state when to use it versus alternatives or mention any exclusions. No sibling comparisons are provided.

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

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

With no annotations, the description carries the full burden. It discloses that the tool retrieves texts 'via as_of' and that an anchor 'scopes the typed comparison workspace,' which adds some behavioral context. However, it does not state whether this is a read-only operation, describe side effects, or explain behavior when texts are not held or no versions match.

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 and front-loads the core purpose. The second sentence is dense, incorporating references to as_of and timeline_semantics, but there is no filler. It earns a 4 rather than 5 due to the slightly convoluted phrasing of the second sentence.

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 tool has 8 parameters, no output schema, and no annotations, so the description must carry significant weight. It gives a solid overview of the diff operation and mentions prerequisites, but it does not cover parameter relationships (e.g., when publisher is required) or edge cases (e.g., no versions found). It also does not sufficiently differentiate from the sibling 'changes_in_period.'

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 adds minor semantic context by referring to the 'anchor' as a 'held article anchor' and mentioning 'typed comparison workspace,' but it does not provide meaningful additional meaning for most parameters (e.g., to_version_key, from_version_key, language) beyond what the schema already includes.

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: 'What changed between two dates for one work' and explains that it identifies publisher versions covering the dates and retrieves them via as_of for comparison. This is a specific verb+resource. However, it does not explicitly distinguish the tool from the similar sibling 'changes_in_period', so it falls short of a perfect 5.

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 implies usage when comparing two dates for a single work, and includes a crucial instruction: 'Read timeline_semantics before describing legal applicability.' However, it does not explicitly state when to use this tool versus alternatives like as_of or changes_in_period, nor does it provide exclusion criteria. Guidance is only implied.

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

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

With no annotations, the description carries the full burden. It discloses computation from timeline intervals, deduplication by work, envelope timeline_semantics, and a mandatory population disclosure in the result. This adds valuable behavioral context, though it omits potential error conditions or rate limits.

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 concise but dense, packing important behavior into two sentences. While a bit jargon-heavy (e.g., 'timeline_semantics', 'population disclosure'), it is structured efficiently and front-loads the primary purpose.

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 tool has 12 parameters and no output schema, so the description should compensate by explaining result shape more fully. It mentions envelope and population disclosure but does not detail response structure, error scenarios, or examples. The description is useful but incomplete for an agent expected to invoke this 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 provides 100% coverage with descriptions for all parameters. The tool description does not add parameter-level meaning beyond what the schema already states, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: returning publisher states covering a date, computed from timeline intervals and deduplicated by work. It also distinguishes key nuances (Legilux vs EUR-Lex), which helps differentiate it from related operations like as_of or timeline.

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 some usage context (e.g., EUR-Lex states must not be called entry into force) but does not explicitly state when to use this tool over siblings like as_of or coverage. Alternatives are not named or contrasted, leaving the agent to infer use cases.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does this well by detailing what the proof chain contains, including source URI, retrieval time, hashes, event chain, corpus commit, index build, and stamp signature. This tells the agent what to expect in the response, though it does not explicitly state side-effect-freedom or failure 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?

The description is a single, compact sentence that front-loads the core purpose ('Proof chain for one lex_id') and then efficiently lists the output components in a colon-separated sequence. Every element adds useful information, with no filler or redundancy.

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 moderate complexity (2 params, no output schema, no annotations), the description provides a solid inventory of return values, which is sufficient for a straightforward lookup tool. It lacks usage guidance and deeper behavioral notes, but the enumerated components largely compensate for the absence of an output schema. Sibling tool names also help contextualize its role.

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 descriptions for both parameters (lex_id as 'full lex_id' and language as 'optional'), achieving 100% coverage. The description adds minimal parameter-level meaning beyond confirming the lookup is for a single lex_id; it does not explain how 'language' affects the proof chain or whether it is required for certain lex_id formats.

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 tool's output as a 'proof chain' for a single lex_id and enumerates the specific components (source URI, hashes, event chain, etc.). This distinguishes it from siblings like 'article_history' or 'timeline' by focusing on verifiable provenance rather than general history. However, it lacks a strong action verb (e.g., 'retrieves' or 'generates'), so it reads more as an output description than an operation.

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 phrase 'for one lex_id' implies the tool is intended for per-identifier provenance lookup, which provides some usage context. But there is no explicit guidance on when to prefer this over siblings like 'coverage' or 'article_history', nor any mention of exclusions or alternative tools.

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

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

With no annotations, the description carries the transparency burden and does well: it discloses deterministic FTS5/BM25, conditional hybrid behavior, the absence of a generative model, the query_plan structure, and the lack of body text in results. It does not cover authentication or rate limits, but that is reasonable for a search tool.

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 three dense, purposeful sentences that front-load the core purpose ('Filtered legal search') and then provide only high-value clarifications. No redundant or filler content.

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 (17 params, conditional validation, no output schema), the description covers key aspects: retrieval modes, output characteristics, and the as_of state mechanism. Minor gaps like error handling and result ordering are not fatal because the schema fills in parameter constraints.

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 17 parameters already have schema descriptions, so the description adds minimal per-parameter semantics. It adds useful context about retrieval_mode and the query_plan, but does not go deeper than the schema for individual parameters.

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 a filtered legal search tool, noting its deterministic and hybrid retrieval modes and stating that no generative model participates. It distinguishes itself from sibling tools by detailing the query_plan output and the explicit absence of body text in hits.

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 hybrid mode is used versus keyword mode and hints at vector availability, but it does not explicitly address when to use this tool over siblings like article_history or cited_by. Usage context is implied rather than directly stated.

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

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

No annotations are present, so the description takes on the transparency burden. It adds valuable behavioral nuance by distinguishing Legilux intervals (applicability) from EUR-Lex intervals (consolidated wording, not entry into force), which is non-obvious and essential for interpretation.

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 exactly two sentences, front-loaded with the core purpose and followed by a crucial semantic clarification. Every word earns its place with no redundancy.

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?

Without an output schema or annotations, the description must explain return values and context. It lists key output components and a critical semantic caveat, but it does not describe interval structure, ordering, or relationship to sibling tools, leaving notable gaps for a nuanced legal-history 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?

The input schema provides exhaustive descriptions for all four parameters, including format details for 'work' and pagination for 'limit'/'offset'. The description itself adds no parameter-level information, matching the baseline for 100% schema coverage.

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 surfaces every publisher state a document has been in, with timeline intervals, version keys, and timeline_semantics. It is specific and informative, though the verb is implicit and sibling differentiation is not explicit.

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 implies the tool is used to retrieve a document's state history and provides important interval semantics, but it does not explicitly say when to use this tool versus siblings like article_history or provenance.

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