Lex: Luxembourg Law MCP Server

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

With no annotations, the description carries the burden of behavioral disclosure. It does well by explaining that renumbering is detected mechanically via identical text hash and that output includes validity intervals plus lifecycle events. However, it does not specify potential limitations (e.g., unknown anchors) or output ordering, which would strengthen 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 exceptionally concise: two sentences that front-load the core function and then summarize the user-facing question. Every clause contributes meaningful detail without redundancy or padding.

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 moderately complex history tool without an output schema, the description conveys the essential return content (validity intervals, lifecycle events) and a key algorithmic detail (hash-based renumbering detection). It could delve into interval representation or edge cases, but the provided information is largely sufficient for an agent to understand the tool's scope.

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 detailed descriptions for both 'work' and 'anchor', including guidance to call search first for unknown documents. The description adds no additional parameter-level meaning beyond schema, so the 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 identifies the tool's function: retrieving the distinct text versions of a single provision as validity intervals, plus lifecycle events. It effectively distinguishes itself from siblings by emphasizing 'ONE provision' and the historical scope, making the purpose unmistakable.

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 ('what did Article X say over its life / when did it change') and implicitly differentiates from siblings like timeline or changes_in_period by focusing on a single provision's full text history. However, it does not explicitly state when not to use this tool or name alternative tools, so it falls 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.

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

With no annotations, the description carries the transparency burden. It discloses that the tool is a pure lookup ('no ranking'), explains the three modes and their outputs, and notes that every provision includes a permalink and hash. It stops short of error handling or auth details, but adequately covers the key non-destructive 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 and every sentence contributes: purpose, safety, mode usage, and return characteristics. It is front-loaded with the core function and avoids redundancy, making it efficient and easy to parse.

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 5-parameter tool with no output schema, the description covers the main behavior, mode distinctions, and even output attributes (permalink, hash). It could be more explicit about the overall return structure, but the provided details are sufficient for an agent to invoke the tool correctly in most 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?

The schema already describes all parameters (100% coverage), so the baseline is 3. The description adds meaningful context beyond schema by explaining the mode parameter's three values ('outline', 'select', 'full') and their practical uses, which enriches the parameter semantics.

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: 'The state of one document as it stood on one date.' It distinguishes from search by claiming 'Pure lookup, no ranking' and from other temporal tools by focusing on a single date snapshot for one document.

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 explicit guidance on mode usage: 'use it first on long documents' for outline mode, and explains when to use select vs full. It does not explicitly name sibling alternatives for when not to use this tool, but the 'no ranking' contrast with search offers implicit direction.

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 behavior, ordering semantics (by_churn vs by_date), and the nature of the output (works, counts, timestamps). It does not explicitly mention read-only status or permissions, but the examples and wording imply a safe read operation.

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 that pack purpose, scope, sibling differentiation, example queries, and a key parameter explanation. It is front-loaded with the core function and contains no 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 query tool with no output schema and 7 parameters, the description covers the essential context: purpose, scope, example usage, and the most behaviorally significant parameter. It does not describe the exact return structure, but the output is implied by 'how many each, and when'. Optional filters (publisher, document_type) are not mentioned, but are less critical for core usage.

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 covers all parameters, so baseline is 3. The description adds value by explaining the 'order' parameter's two modes and clarifying that dates are inclusive. It also contextualizes the date window through examples, going beyond the schema's minimal definitions.

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: finding works that gained new versions between dates, with counts and timestamps. It explicitly distinguishes itself from sibling tools ('aggregate counterpart of diff/timeline') and specifies the corpus-wide scope.

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 explicit when-to-use guidance with concrete example queries, and names the alternatives (diff/timeline) it complements, explaining they cover one work while this covers the whole corpus.

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 adds useful context by noting the data is 'captured at derive time', indicating a snapshot rather than real-time computation. However, it does not mention response format, ordering, pagination, or any limitations beyond the schema's default limit, leaving gaps for an agent.

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 front-loaded with the core statement and then expands with example questions. It is not overly long, but the closing rhetorical clause ('the one a search box cannot answer') is somewhat decorative and could be trimmed. Overall, it is efficient 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?

For a simple read-only tool with two parameters and no output schema, the description explains the core concept, use cases, and how it differs from other tools. It lacks explicit return-value details and ordering, but given the low complexity and rich context, it is nearly complete. Missing precise output structure keeps it from a 5.

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 covers both parameters (work and limit) with clear descriptions, so schema coverage is 100%. The description does not add extra meaning beyond the schema—it repeats the concept of 'the law being cited' but provides no additional syntax, format hints, or edge-case guidance. 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 a precise statement: 'Which ARTICLES point at this law.' This clearly identifies the tool's function as finding citing articles for a given law. It further distinguishes itself from siblings by contrasting with publisher-written cross-references and noting that a search box cannot answer this question, making the purpose unmistakable.

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 usage context: it answers 'what depends on this law', 'who amended it', and 'is anything still referring to it'. It implies this is for reverse-citation lookups that search cannot handle. However, it does not explicitly name sibling tools or state when not to use it, so it falls short of the highest bar.

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 reports counts, date ranges, history_begins, and known gaps, clarifying its informational nature. However, it does not explicitly state side effects, safety, or edge cases, 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?

The description is two sentences, tightly written, and immediately conveys the purpose and key output aspects. Every phrase adds value without 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?

For a simple tool with one optional parameter and no output schema, the description provides a clear picture of what is returned (counts, date ranges, etc.) and the overall purpose. Minor gaps remain, such as behavior when no publisher is specified, but it is generally 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?

The schema already fully describes the sole parameter ('publisher') with 100% coverage, so the description does not need to add parameter semantics. It provides no additional insight about the parameter, but the baseline of 3 is appropriate when the schema covers 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 identifies the tool as a coverage/gap reporting tool, listing specific outputs (counts, date ranges, history_begins, known gaps) and emphasizing its focus on what is absent. While it does not explicitly compare against sibling tools, the purpose is distinct and understandable.

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 explicit instructions are given for when to use this tool versus alternatives. The description implies it is used to assess data completeness ('what we do NOT have'), but it lacks direct guidance or exclusions, making the usage context merely 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 burden of behavioral disclosure. It reveals a key trait: diff does not return texts itself, but directs the user to as_of for retrieval. It also implies a read-only nature. However, it doesn't detail output format or edge cases, so it isn't perfect.

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, but it's grammatically awkward and not front-loaded. The key instruction ('retrieve them via as_of') is buried at the end. A clear rewrite would split into two sentences for better readability.

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?

No output schema exists, so the description must explain what diff returns. It mentions 'which versions applied, and where both texts are held', which is informative but vague. It doesn't specify the exact format of the version/location data or how to interpret the result, leaving some 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?

Schema coverage is 100%, with all four parameters documented. The description adds 'one work' and 'between two dates', which reinforces the work and date parameters, but provides no extra syntax or format details beyond the schema. 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 compares two dates for one work, listing which versions applied and where texts are held. This distinguishes it from siblings like changes_in_period (which covers a period) and as_of (which retrieves a single version).

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 instructs to retrieve texts via as_of, indicating that diff identifies versions/locations rather than returning full texts. It also mentions 'for one work' and the parameter description adds 'Unknown document -> call search first', providing practical usage context, though it doesn't explicitly contrast with all sibling 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 full burden for behavioral disclosure. It adds useful context: query-time computation, deduplication, and a mandatory population disclosure. However, the disclosure's nature is vague, and there is no mention of pagination behavior, return format, or potential limitations, so it is only partially 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 only two sentences, yet it packs in the core purpose, computation method, deduplication, and a caveat about disclosure. It is front-loaded with the key verb/resource and avoids any filler, making it 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?

Despite having 5 parameters and no output schema, the description omits any explanation of the 'mandatory population disclosure'—a critical caveat—and does not clarify what the return payload looks like or what filtering options exist. The description is too minimal to give a complete picture, especially given the lack of an output schema.

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 covers all 5 parameters with descriptions, so the baseline is 3. The description does not add additional parameter-specific semantics beyond what the schema already provides, such as the meaning of 'publisher' or 'document_type' filters.

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 returns 'the set of works in force on a date', computed from validity intervals and deduplicated by work. This is specific about the resource and behavior, distinguishing it from siblings like 'as_of' by mentioning deduplication and the population disclosure, though it does not explicitly name a sibling.

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 provided on when to use this tool versus sibling tools such as 'as_of' or 'coverage'. The description implies a date-based use case but does not offer exclusions or mention alternatives, leaving the agent to infer selection criteria.

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 reveals the output's content (URIs, hashes, event chain, etc.) and that it operates on a single lex_id. However, it does not mention potential side effects, permissions, or error behavior, leaving some uncertainty for an agent.

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 that is both concise and front-loaded with the core purpose. Every phrase adds meaningful detail about the returned proof chain, with 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?

For a simple two-parameter tool without an output schema, the description covers the essential aspects: what the tool does and what the result contains. It lacks explicit handling of missing lex_ids or error cases, but the listed components give an agent a clear picture of expected output.

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 provides descriptions for both parameters, achieving 100% coverage. The description's mention of 'one lex_id' reinforces the required parameter but adds no new semantics or format details beyond what the schema states.

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 produces a proof chain for a lex_id, enumerating specific components such as source URI, hashes, and stamps. This distinguishes it from sibling tools like article_history or timeline by focusing on provenance metadata, not historical changes.

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 this tool is used when you need provenance information for a specific lex_id, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like as_of or diff. Clear context is present, but no exclusionary or comparative direction is given.

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 transparency burden. It discloses key behaviors: filters always run before ranking, hits are returned WITHOUT body text, and full state is available via as_of. It does not mention permissions or rate limits, but for a read-only search tool, the description covers the most surprising traits.

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 concise sentences deliver essential information without fluff. The opening phrase is descriptive and front-loaded, and every clause adds value: FTS type, filter-before-ranking order, return payload composition, and the as_of escape hatch.

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 6 parameters and no output schema, the description gives a surprisingly complete picture: what it searches, what it returns, and how to get full state. It lacks explicit mention of pagination/ranking details, but these are either in the schema or not critical for basic 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?

Although schema coverage is 100%, the description adds semantics beyond the schema by explaining that filters (works, publisher, document_type) always run before ranking, and by connecting 'as_of' to the notion of full state. This enriches understanding of parameter interplay.

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: 'Filtered-then-ranked full-text search (FTS)' with a specific verb and resource. It also distinguishes itself from siblings by highlighting unique behavior (filters run before ranking) and the result format (hits without body text), making it unambiguous.

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 context is clear: this is the full-text search tool, and sibling tool names (e.g., article_history, diff, coverage) obviously serve different purposes. However, the description does not explicitly state when to use this versus alternatives or provide exclusions, 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.

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

With no annotations, the description carries the full burden. It adds 'publisher-asserted' as a source qualifier and specifies output components (validity intervals, version keys), which is useful. However, it does not disclose ordering, pagination behavior, or whether the full document content is included, leaving gaps in 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, concise sentence that front-loads the core concept. It contains no fluff and effectively communicates the tool's essence.

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?

Despite good schema coverage, the description lacks contextual completeness. It does not explain how this tool relates to siblings, what the return format looks like, or any edge cases. Given the existence of similar tools (article_history, as_of, changes_in_period), this minimal description is insufficient for an agent to confidently select and invoke this 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 schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already 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 conveys the tool's purpose as listing every state a document has been in, including validity intervals and version keys. Although it lacks an explicit verb, the phrasing distinguishes it from siblings by emphasizing publisher-asserted temporal data. It does not explicitly differentiate from alternatives like article_history or as_of, but the specific mention of validity intervals and version keys helps.

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 provided on when to use this tool versus alternatives. The only hint is in the schema description for 'work' mentioning 'Unknown document -> call search first', but the main description offers no context on choosing this tool over similar ones like as_of, changes_in_period, or article_history.

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