Lex — Temporal Luxembourg and EU Law

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

With no annotations provided, the description takes on the behavioral disclosure burden. It goes beyond a simple read operation by detailing specific lifecycle events (inserted/removed/renumbered) and explains that renumbering is detected mechanically via identical text hash. It also warns about a prerequisite ('timeline_semantics') for interval legal applicability. It stops short of describing output format or error handling, but the added context is meaningful.

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 sentences, ordered logically: what the tool returns, a prerequisite warning, and a user-facing question. It is information-dense without being verbose, and each sentence contributes unique value. A minor structural improvement could be separating the prerequisite into its own line, but it remains concise.

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

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

For a tool with six parameters and no output schema, the description provides a solid high-level account: it defines the output (history plus lifecycle events), notes a dependency on timeline_semantics for legal applicability, and frames the use case. It lacks an explicit statement about the response structure (e.g., chronological list of states), but given the absence of an output schema, this is a minor gap.

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 covers all six parameters with individual descriptions at 100% coverage, including examples and purpose. The tool description adds little parameter-specific detail beyond what the schema provides. It implies the relevance of date parameters through 'interval legal applicability' but does not elaborate on their semantics, so the schema carries the 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 defines the tool as returning the complete history of a single provision's text and lifecycle events, with the explicit phrase 'Every distinct text ONE provision...' and answers the question 'what did Article X say over its life / when did it change.' This sharply differentiates it from sibling tools like timeline (whole-work history) and changes_in_period.

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 a concrete prerequisite: 'Read timeline_semantics before calling an interval legal applicability,' which guides safe usage. It also scopes the tool to 'ONE provision,' implying it is for single-article history rather than broader time-based queries. However, it does not explicitly name when to prefer alternatives like as_of or in_force_on.

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 clearly states this is a 'Pure lookup' (no side effects), explains each mode (outline, select, full), and notes that every provision includes a permalink and hash. It does not mention error or edge cases, 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?

The description is two sentences, front-loaded with a clear purpose statement, then detailed modes. Every word earns its place, with no redundancy or fluff.

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

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

For a 7-parameter lookup with no output schema, the description covers the core behavior, all three modes, and output characteristics (permalkins/hash). It lacks explicit usage guidance and edge-case handling, but the schema fills parameter details. This is a solid, nearly complete description.

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 context about how mode and anchors interact (outline can be narrowed with anchors; select returns named anchors' text), which helps understanding. However, this overlaps with the schema's parameter descriptions and does not add significantly new meaning.

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 provides 'the state of one document as it stood on one date' and explicitly notes 'Pure lookup, no ranking,' which distinguishes it from search. However, it does not explicitly differentiate from sibling historical tools like in_force_on or timeline, so it falls short of a 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 gives almost no guidance on when to use this tool vs alternatives. It only says 'Pure lookup, no ranking,' which vaguely implies not for ranking, but does not mention when to prefer as_of over in_force_on, timeline, or changes_in_period. The schema's 'Unknown document -> call search first' is useful but not part of the description itself.

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 the aggregate, read-oriented nature (gaining versions across the corpus) and explains the behavior of the order parameter (by_churn ranks by count, by_date lists recently changed). It does not mention side effects, but the query nature is clear. It adds context beyond the schema, earning a 4.

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?

Three sentences of dense, front-loaded information. The first sentence establishes purpose, the second gives usage examples, and the third clarifies order semantics. Every sentence earns its place; there is no fluff 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 complexity (14 parameters, no annotations, no output schema), the description provides a strong conceptual overview, usage examples, and key parameter semantics. It doesn't enumerate all filters, but the schema covers them. It lacks explicit return format, but that is not critical for a list-style tool. Overall, it is complete enough 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%, so baseline is 3. The description adds meaningful semantic value by explaining what each order enum does ('by_churn ranks by number of new versions; by_date lists most recently changed first'), which is not fully expressed in the schema. This pushes it above the baseline.

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

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

The description clearly states the tool's purpose: to identify works that gained new versions across the corpus within a date range, including counts and dates. It explicitly distinguishes itself from diff/timeline by calling itself the 'aggregate counterpart' covering multiple works, which is a strong differentiation 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 provides explicit when-to-use guidance with concrete example queries like 'what changed between 2025 and 2026' and 'which laws changed most during the pandemic'. It also implicitly tells when not to use it by noting that diff/timeline cover ONE work, steering users to the appropriate alternative.

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 provided, the description carries the full burden of behavioral disclosure. It transparently states that it reports 'publisher references Lex captured' and explicitly disclaims any classification of relationship type or assessment of current legal effect. This sets accurate expectations about the tool's scope, though it does not detail pagination, output format, or data freshness.

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 about 35 words. It front-loads the main purpose, clearly states the scope, and adds a brief limitation note. There is no wasted text 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?

The tool is a simple lookup with 2 parameters (one required) and no output schema. The description explains what it reports and its limitations, which is sufficient for an agent to know when to select it. It could be more complete by describing the return structure, but the schema and high-level description make it adequate.

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 both parameters (work and limit), with 100% coverage. The tool description does not add any additional meaning to the parameters, so it does not go beyond the schema. 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 identifies the tool as a reverse citation lookup: 'Which held provision versions contain captured publisher cross-references to this work.' It specifies the resource (held provision versions) and the action (reverse lookup), and distinguishes itself from siblings by explicitly stating what it does not do (classify relationship type or assess legal effect).

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 this tool: when you need to find provision versions that cite a given work. It also includes a 'when-not' by stating it does not classify relationships or assess legal effect, which sets boundaries. However, it does not explicitly name alternative tools or provide direct 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 carries the burden. It discloses that the tool returns coverage counts, date ranges, history_begins, and gaps, which is useful behavioral context. However, it does not mention side effects, permissions, or limitations.

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 short sentences that front-load the purpose and key outputs. No wasted words, making it highly concise.

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

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

For a simple tool with one optional parameter, the description adequately covers the main return fields and purpose. However, terms like 'tier by tier' and 'history_begins' are left undefined, which could create ambiguity.

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 has 100% coverage for the optional publisher parameter, so the baseline is 3. The description does not mention the publisher parameter or add extra meaning beyond the schema.

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

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

The description clearly states the tool provides coverage information about what is held and lacking, with counts, date ranges, history_begins, and known gaps. It distinguishes from sibling tools by focusing on coverage, but does not explicitly name alternatives.

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 needing to know data coverage or gaps, but provides no explicit when-to-use vs. alternatives. It lacks exclusions or alternative tool references.

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. It discloses retrieval via as_of, the scoping effect of an anchor, and a prerequisite for legal applicability. However, it does not explicitly state read-only behavior, error outcomes, or return structure, leaving some behavioral aspects undisclosed.

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 convey a dense but focused purpose. The first sentence packs the core mechanics, and the second adds the anchor behavior and a caveat. No wasted words, though the first sentence is somewhat complex.

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 complex 8-parameter tool with no output schema and no annotations, the description covers the main purpose and key interactions but leaves gaps: it does not describe return format, error conditions, or clarify 'typed comparison workspace' and 'timeline_semantics'. Adequate but not fully 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 parameters are already documented. The description adds semantic context for 'anchor' ('scopes the typed comparison workspace') and relates 'work' to version/date selection, but does not go beyond the schema for other parameters, aligning with the baseline.

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

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

The description clearly states the tool's function: 'What changed between two dates for one work' and outlines the process of identifying publisher versions covering selected dates and retrieving them via as_of to compare. It distinguishes itself from siblings by referencing as_of and timeline_semantics, signaling specific use cases.

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?

Provides clear context on when to use: for comparing versions across dates for a single work, with an optional anchor for scoping. Mentions a prerequisite ('Read timeline_semantics') and a condition ('where both texts are held'), though it does not explicitly contrast with sibling tools like changes_in_period.

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 full responsibility for behavioral disclosure. It reveals the computation method (timeline intervals), deduplication by work, and the output contract (timeline_semantics in the envelope, mandatory population disclosure), going well beyond 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?

Two sentences are packed with essential information: the core purpose, the key semantic distinction, and the output characteristics. No unnecessary words; the structure front-loads the main purpose and then adds critical caveats.

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 12 parameters, no output schema, and no annotations, this description is remarkably complete. It explains what the tool computes, the crucial distinction from entry into force, the deduplication logic, and key aspects of the response envelope, enabling an agent to use it 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% with each parameter already having a description, so the baseline is 3. The description adds high-level semantics about publisher states and date coverage but does not elaborate on parameter-specific behavior or interactions beyond what the schema provides.

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

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

The description clearly states the tool computes publisher states covering a given date from timeline intervals, deduplicated by work. It also explicitly contrasts Legilux applicability states with EUR-Lex official consolidated wording states, making it unmistakable that this is not an entry-into-force tool.

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?

Provides contextual guidance by clarifying the difference between Legilux and EUR-Lex states and warning against mislabeling the result as 'entry into force.' However, it doesn't explicitly name alternative sibling tools or state when to prefer them, so it's not fully explicit.

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 must carry the transparency burden. It does disclose the contents of the proof chain (source URI, retrieval time, hashes, event chain, corpus commit, index build, stamp signature), which gives the agent a clear picture of the output. However, it does not state whether the operation is read-only, has side effects, requires authentication, or how the chain is constructed. The description adds some value but not full behavioral transparency.

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 sentence with a colon-separated list, packing many details into a compact format. It is not verbose or redundant; every listed item adds meaningful information. However, the sentence is somewhat dense and could be split for readability, but overall it is appropriately concise.

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

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

There is no output schema, so the description needs to cover return semantics. It does list the components of the proof chain, which is helpful, but it does not describe the output structure (e.g., JSON keys, order, nesting) or address potential errors or edge cases. Given the complexity of the tool (many parts in the chain), the description is adequate but not fully 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 description coverage is 100%, with both 'lex_id' and 'language' already documented in the schema. The description does not add any parameter-specific meaning beyond what the schema provides; it merely mentions the tool works 'for one lex_id', which is already stated. Therefore, it meets the baseline but provides no additional semantic value.

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 function: providing a proof chain for a single lex_id and enumerates its components (source URI, hashes, event chain, etc.). This distinguishes it from sibling tools like 'article_history' or 'timeline' by focusing on cryptographic proof rather than chronological narrative. However, it lacks an explicit verb like 'get' or 'retrieve', making the action slightly implicit.

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?

No guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or why one would choose 'provenance' over a tool like 'diff' or 'as_of'. The usage context is only inferred from the tool's name and description, not explicitly 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?

Without annotations, the description carries the full burden and does well: it discloses the deterministic FTS5/BM25 behavior, the hybrid mode with pinned local encoder and fixed RRF, conditional activation ('when verified vectors are mounted'), and the fact that no generative model participates. It also reveals that the response includes a query_plan and that hits lack body text. This goes beyond a simple search description, though it omits operational details like rate limits or error 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 four sentences, each delivering distinct information: what the tool does, retrieval behavior, response structure, and return constraints. There is no repetition of schema fields and no fluff. It is front-loaded with the core 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?

Given the tool's complexity (17 parameters, no output schema, no annotations), the description covers key aspects: core functionality, retrieval mechanism, response query_plan, and the limitation of no body text with a pointer to as_of for full state. It does not explain every filter, but the schema does that. It adequately addresses the important behavioral nuances.

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% for all 17 parameters, so the schema already provides detailed descriptions. The tool description adds meaning to retrieval_mode ('keyword is deterministic FTS5/BM25; hybrid adds the pinned local encoder') and hints at as_of usage, but does not significantly enhance understanding of the many filter parameters. 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 opens with 'Filtered legal search', which clearly identifies the tool as a search over legal documents with filtering. It distinguishes itself from sibling tools (article_history, as_of, diff, etc.) by specifying that it returns hits without body text and that full state is available via as_of.

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 implicitly guides usage by noting 'Returns hits WITHOUT body text; full state via as_of', which tells the agent to use as_of when full text is needed. It also differentiates retrieval modes (keyword vs hybrid) and clarifies that no generative model participates. However, it does not explicitly enumerate when to prefer this tool over other siblings beyond as_of.

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 adds meaningful behavioral context by explaining the different interval semantics for Legilux and EUR-Lex. However, it does not disclose whether the operation is read-only, any rate limits, or error conditions. The explanation of semantics is useful but leaves other behavioral aspects unspecified.

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 and followed by a clarifying note on interval semantics. Every sentence earns its place, and there is no redundant wording. It is appropriately sized and well-structured.

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 explains what the timeline represents and the distinction between Legilux and EUR-Lex intervals, which is essential for correct interpretation. However, with no output schema and no mention of pagination or response structure, it is not fully complete for an agent handling complex queries. The presence of sibling tools makes this description adequate but not exhaustive.

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 main description does not add parameter-level meaning beyond what the input schema already provides. The mention of 'version keys' and 'timeline_semantics' relates to the output, not the input parameters, so no additional value is added.

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 that the tool returns the timeline of publisher states, including intervals, version keys, and timeline semantics. It clearly references the resource (timeline) and the kind of data returned. It differentiates between Legilux and EUR-Lex interval meanings, which helps distinguish from sibling tools, though it lacks an explicit verb like 'get' or 'list'.

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 context for interpreting intervals but does not explicitly say when to use this tool versus alternatives like 'as_of' or 'in_force_on'. The semantic distinction (applicability vs. consolidated wording) implies a use case, but there are no explicit when/when-not statements or mentions of sibling alternatives.

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