Lex — Temporal Luxembourg and EU Law

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

With no annotations, the description carries the full transparency burden. It usefully discloses that results are enumerated from revising events and that a genesis log returns an explanation rather than a bare 'nothing drifted' assertion, but it does not state read/write semantics, permission needs, pagination, or response shape.

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 definition is a single sentence with little wasted length, but it is syntactically dense and front-loads a difficult noun phrase rather than a clear action. Its compactness comes at the cost of 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?

For a three-parameter tool with no annotations, no output schema, and zero schema description coverage, the description is insufficient. It adds one important edge-case behavior but leaves parameter usage and return behavior largely unexplained.

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 three parameters (after, limit, identifier) with 0% description coverage, and the description does not explain any of them. It neither clarifies the pagination cursor format, the result limit, nor what the identifier selects.

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 indicates that the tool returns past dated answers invalidated by a publisher revision, sourced from the log's revising events. However, the wording is opaque and relies on unexplained domain terms like 'drift,' 'genesis log,' and 'revising events,' so an agent cannot confidently distinguish it from siblings such as diff, changes_in_period, 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 no explicit when-to-use guidance, prerequisites, or alternatives. It mentions a genesis-log edge case, but that is behavioral detail rather than routing guidance for choosing this tool over related history or diff 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?

No annotations are provided, so the description carries the full behavioral burden. 'History' implies a read-only temporal view, but it does not explain what 'states' means, whether all versions are included, how results are ordered, or whether pagination or authorization constraints apply.

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 single sentence is front-loaded and free of filler, but it is too terse for a three-parameter tool with no annotations and no documented schema fields. Its concision comes at the cost of necessary specification.

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 three parameters, zero schema descriptions, no annotations, and no output schema, the description is materially incomplete. It conveys the domain concept but omits parameter meanings, expected behavior, and return characteristics needed to invoke it confidently.

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 0%, and the description never names the parameters. It hints at a two-level lookup ('article' and 'act'), which may loosely map to anchor and identifier, but anchor and language remain unexplained and no format or accepted values are given.

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 identifies a specific resource: the history of one article of a Luxembourg act across its states. It is clear enough to distinguish a historical article lookup from broad siblings like search or browse, but it does not explicitly distinguish it from timeline, diff, or 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 gives no explicit guidance on when to use this tool rather than timeline, diff, changes_in_period, or as_of. The intended usage is only implied by the phrase 'history of one article.'

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, and it does disclose a key behavior: every question returns `assistant_v3_unavailable` and no model answers. That is useful transparency about output and refusal behavior, but it does not clarify side effects, permissions, error modes, or the shape of the returned presentation result.

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 short and technically one sentence, but it is front-loaded with the vague phrase "The contained assistant" and packed with internal references such as "Decisions 51 and 91." It is concise in length but not structured for quick agent comprehension.

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 one-parameter tool with no annotations or output schema, the description should clearly explain the operation and return behavior. It does state that the result is always `assistant_v3_unavailable`, but it leaves the parameter semantics and practical usage unclear, so an agent cannot confidently invoke it beyond knowing it is a non-model fallback.

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 0% for the single required `question` parameter. The description only says "every question" and adds no detail about expected question format, constraints, or how the value is used, so it does not compensate for the undocumented 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 is framed around a "contained assistant" but does not clearly state what `ask` is for in normal terms. It says every question returns the typed presentation result `assistant_v3_unavailable` and names deterministic operations, but the core purpose is obscured by implementation jargon rather than a clear verb+resource.

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?

There is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative among the many sibling tools. The mention of deterministic operations that answer from held law implies routing, but it does not tell an agent when to call `ask` instead of `search`, `resolve`, `as_of`, or others.

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 behavioral burden; it does disclose non-obvious observation semantics—build time as upper bound and no observation time held—plus a refusal behavior for time. However, it does not state read-only/side-effect/auth profile or return behavior, leaving meaningful gaps.

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?

It is short but a single nested sentence with jargon, not front-loaded with the tool's action. The compression makes it harder to parse rather than efficient.

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 five-parameter tool with no annotations, no output schema, and zero schema descriptions, this is too incomplete; it explains a conceptual snapshot model but not how to call it or interpret results.

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 0% for five parameters, so the description must compensate. It hints at date, snapshot/index digest, and a refused time ('at'), but ignores required identifier and language, and gives no format/semantics for the rest.

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 never states an action verb and leads with a dense noun phrase; a reader must already know what a 'mounted log build' and 'index digest' are. It gestures at a Luxembourg act state on a date from a specific build, but does not clearly separate this from as_of/status_on/in_force_on 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?

No explicit when-to-use or when-not-to-use guidance is given, and the only constraint ('a time refuses') is cryptic and unexplained. It does not name as_of or other temporal siblings, so an agent cannot 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 must carry the whole burden, and it does add genuine semantics: for EU acts the date resolves to a wording date at or before the requested date, explicitly never an applicability date. That is a real disambiguation of a subtle behavior. Still missing: that this is a read-only retrieval, how large the returned article set may be, and what happens when no wording exists at or before the date.

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?

A single dense sentence with no filler; the core temporal rule is front-loaded. The compression goes slightly too far, producing cryptic fragments like '(publisher)' that cost more clarity than the tokens they save.

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 annotations, no output schema, and 0% schema description coverage for a domain-specific legal tool. An agent still cannot tell which identifier formats are valid, what 'language' does, or how this differs from four sibling temporal tools, which is a substantial 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?

Schema coverage is 0% across three parameters, so the description must compensate. It clarifies the semantics of 'date' only indirectly through the EU wording rule, and says nothing about the accepted form of 'identifier' (ELI, CELEX, act number?) or what 'language' controls. Two of three parameters remain opaque.

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?

Names the specific resource (the state of a Luxembourg/EU act on a date, with its articles) and distinguishes the two legal regimes the tool handles. However, it does not differentiate itself from near-identical siblings like in_force_on, status_on, and as_observed, and the parenthetical '(publisher)' is unexplained.

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?

There is no statement of when to use this tool rather than in_force_on, status_on, as_observed, or timeline, all of which occupy adjacent temporal territory. The Luxembourg-vs-EU split is a usage hint, but it is embedded in a purpose clause rather than framed as 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?

With no annotations, the description must carry the behavioural burden. It does disclose that results are ordered and paged and enumerates some returned fields (identifiers, languages, state dates, document types), but it omits defaults, page size behaviour, sort order, and whether the operation is read-only (implied by 'browse' but not stated).

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?

It is a single sentence with no filler, but the syntax is convoluted and front-loads an awkward fragment ('The Luxembourg works this mount holds') rather than a clear verb-resource statement. Size is appropriate; structure is weak.

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 four-parameter, unannotated, no-output-schema tool, the description gives a reasonable summary of what is returned and that results are paged. It is missing key context an agent needs: the meaning of 'this mount', the semantics of `after`, default and maximum page sizes, and ordering guarantees.

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 0% for all four parameters. The description only indirectly names two of them ('filter by type or language') and gestures at paging with 'ordered and paged', without explaining what `after` is (cursor? identifier?), what the default `limit` is, or how ordering relates to `after`. It compensates only partially for the coverage gap.

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 identifies a concrete resource: the Luxembourg works held by 'this mount', described as an ordered, paged list with identifiers, languages, state dates and document types. That is a specific, recognisable listing operation, though the sentence fragment style ('The Luxembourg works this mount holds') and absence of any contrast with sibling tools like search or timeline keep it from 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?

It says 'filter by type or language', which hints at usage, but never states when to choose this over siblings such as search, timeline, or coverage. There are no exclusions and no prerequisites mentioned.

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 of behavioral disclosure. It does not say whether this is a read-only operation, what permissions are required, how results are ordered or paginated, or what the response contains.

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 one sentence, but it is cryptic and poorly structured rather than efficiently informative. Brevity here reflects under-specification, not conciseness.

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?

This is a five-parameter tool with no output schema and no annotations. The description does not compensate with any usable detail about scope, inputs, behavior, or return values, leaving the agent unable to invoke it confidently.

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 0% for five parameters. The description vaguely references a period and 'a work or across the index', but it does not explain date_from/date_to, identifier, language, or limit, nor does it map any parameter to its purpose.

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 gestures at a resource ('Luxembourg states') and a temporal scope ('began in a period'), but the phrasing is vague and grammatically unclear. It does not state a specific verb or clearly distinguish this tool from siblings like timeline, as_of, or in_force_on.

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?

There is no guidance on when to use this tool versus alternatives such as timeline, as_of, status_on, or article_history. The description does not mention prerequisites, exclusions, or 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?

No annotations are provided, so the description carries the full burden and delivers none of it: no mention of auth/permissions, pagination behavior (despite limit/after/anchor in the schema hinting at a cursor), ordering, or what a response contains. Nothing beyond the topical gloss is disclosed.

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?

It is short, but shortness here is under-specification, not concision: a single fragment with no verb and no front-loaded statement of action or return. Structure fails to orient the reader before the domain detail.

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?

A six-parameter tool with two required args, zero schema descriptions, no annotations, and no output schema — which means the description is the only channel for behavioral and parameter meaning, and it supplies almost none of it. Completely inadequate for this complexity.

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?

Six parameters at 0% schema description coverage, and the description explains none of them. It says nothing about what identifier refers to (an article id? a state? an ELI?), what date constrains, or how after/anchor/limit/language behave, so an agent must guess all six.

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 text is a noun-phrase gloss on the tool name ('The references the publisher wrote...') rather than a verb-plus-resource statement of what the tool does. It adds topical domain (Luxembourg state articles, publisher-written references) but no action, so an agent can't tell whether it fetches, lists, or resolves citations, nor how it differs from siblings like cited_by or provenance.

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?

There is no when-to-use guidance and no named alternative. With siblings such as cited_by, provenance, evidence_bundle, and as_observed plausibly overlapping, the description offers nothing to route the agent between them.

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 behavioral burden. It discloses that results span any held Luxembourg state, but omits whether the operation is read-only, how results are ordered or paginated, and any permission or rate-limit considerations.

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 definition is a single compact sentence with no wasted text and the scope constraint is front-loaded. It is arguably too terse for the information an agent needs, but it is structurally efficient.

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 no annotations, no output schema, and zero parameter descriptions, the one-sentence description is not complete enough. An agent lacks parameter semantics, return shape, and usage context needed to invoke the tool confidently.

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 0% across three parameters. The phrase 'this work' weakly implies what identifier means, but the after and limit parameters receive no explanation in either the schema or the description.

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 identifies a specific resource and scope: references whose target is exactly this work, in any held Luxembourg state. It is understandable without opening the schema, though it lacks a verb and does not explicitly differentiate from siblings like citation or relations.

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 gives no guidance on when to use this tool versus alternatives such as citation or relations. There are no preconditions, exclusions, or selection criteria for an agent to follow.

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 behavioral burden. It adds that the facts are verbatim and publisher-typed, but does not explicitly state read-only behavior, error handling, or return structure.

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 efficient sentence with no filler, but it leads with “The publisher's typed facts” rather than front-loading an action or return statement. The field list is compact and useful.

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 two parameters and no annotations or output schema, yet the description only describes the data content. It omits parameter meaning and return behavior, so an agent lacks enough information to invoke it confidently.

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 0%, and the description does not explain the required identifier or optional language parameters. The phrase “Luxembourg work” weakly implies a work identifier, but language is entirely unexplained.

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 identifies a specific resource: publisher-supplied classification facts for a Luxembourg work, and enumerates the fields returned. It is distinguishable from broad siblings like search or provenance, though it lacks an explicit retrieval verb.

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?

There is no guidance on when to use this tool versus alternatives such as provenance, citation, status_on, or dossier. Usage is only implied by the listed content.

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 and does not state whether the call is read-only, what shape the answer takes, or whether it requires a mount context. The phrase 'what it does not' is the only behavioral detail — a negative-space claim — which is far from enough for a tool with an undocumented optional parameter.

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?

It is one short sentence with no filler, so it is concise in the literal sense. However, the brevity is under-specification rather than disciplined front-loading; the most important information (what is returned, how to call it) is absent.

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 zero-annotation tool with no output schema and an undisclosed optional parameter, the definition is far too thin. It needs to explain the return concept, the role of 'language', and how it differs from nearby coverage-oriented siblings like manifest or browse.

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 single parameter 'language' has 0% schema description coverage and is not mentioned anywhere in the description. Its meaning (output language? filtering by language? required format?) is entirely undefined, so the description does not compensate for the schema gap.

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 gestures at a concept — what a mount holds and does not — but never states a concrete verb or returnable resource. 'Coverage' plus this phrasing is only marginally more informative than the bare name, and it does not distinguish the tool from siblings like browse, search, or manifest.

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?

There is an implicit hint that this tool is about scope/boundaries rather than content retrieval, but no explicit when-to-use, when-not, or named alternative among the 23 siblings. An agent cannot reliably choose this over browse or search from the text.

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 exist, so the description carries the full burden, yet it discloses almost nothing beyond the headline operation. It does not say whether the result is a structured diff, how unchanged/repealed articles are represented, what errors occur for unknown identifiers or unsupported dates, or whether the act version must exist on both dates.

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?

A single front-loaded sentence with no filler, and the key qualifier ('article-level') appears early. Its brevity is efficient, though it borders on under-specification given the undocumented parameters.

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 no annotations, no output schema, and four undocumented parameters, the description is not complete enough for correctly invoking the tool. It leaves open the identifier format, the role of 'language', and the shape of the returned difference.

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 0% — the properties only carry regex patterns, with no semantic text at all. The description clarifies that date_from/date_to are the two comparison dates and implies identifier refers to a Luxembourg act, but it never mentions the 'language' parameter and never specifies the expected identifier form (e.g., ELI or work URI).

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?

States a specific resource (article-level difference between states of a Luxembourg act) and a specific operation (diff over two dates), which is clearly distinct from a general listing tool. It stops short of naming how it differs from near-siblings such as article_history or 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?

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'on two dates' implies a comparison scenario, but with 23 siblings including article_history, changes_in_period, as_of and as_observed, an agent gets no help deciding which to pick.

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, yet it says nothing about read-only status, authentication, error handling, or response shape. 'As the index holds it' faintly suggests an authoritative read, but this is too implicit to count as 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 no obvious filler, but its semicolon-heavy structure and lack of a clear action verb make it less front-loaded and harder to parse than it could be.

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 two-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It does not provide enough information about parameters or behavior for an agent to invoke the tool confidently.

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 0% for two parameters. The description mentions an identifier for an EU work but does not explain the identifier format or clarify the role of the language parameter, which is entirely omitted.

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 identifies the resource as a 'work record' or 'held expressions' from an index, which gives a domain-specific sense of what the tool returns. However, it lacks a clear verb, uses opaque phrasing like 'as the index holds it,' and does not distinguish the tool from siblings such as manifestation or citation.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies retrieval by identifier but does not state contexts, exclusions, or prerequisites.

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 behavioral disclosure. It usefully states cursor polling, at-least-once delivery, and the distinction between build time and observation time, but it omits important behavior such as ordering, duplicate handling under at-least-once delivery, pagination semantics beyond the cursor, and any permission or rate-limit context.

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 compact single sentence with no obvious filler and front-loads the resource and polling mechanism. Its density and jargon make it harder to parse, but it is not verbose.

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 and no annotations, and all three input parameters have zero schema description coverage. The description supplies a conceptual model of the event log but is not complete enough to confidently invoke the tool, especially regarding filtering, pagination, and return behavior.

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 0% for three parameters. The description hints at cursor polling, which loosely relates to the "after" parameter, and mentions event-log concepts, but it never explains the "after" format, the event enum, or the "limit" parameter and its maximum.

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 identifies an event log and cursor polling, but does not use a clear action verb such as retrieve/list or explicitly say whether it returns events or manages them. It is distinguishable from siblings only indirectly through the term "event log"; the cryptic "Luxembourg" framing and dense log semantics leave the purpose only partially clear.

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 no explicit when-to-use guidance, no conditions for choosing this over siblings like timeline, changes_in_period, or diff, and no exclusions. Cursor polling is mentioned, but that is a mechanism, not usage 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?

With no annotations, the description carries the full burden but does disclose meaningful behavior: pagination limits ('at most 50 articles and 96 KiB of text'), how page/article/contents affect the request, and that output is composed 'under the rights rule'. It does not mention permissions, read-only nature, 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 one dense, run-on sentence with nested parentheses and semicolons, making it hard to parse. It is not front-loaded with a clear action, and the structure obscures rather than organizes the constraints.

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 6-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It describes output contents and pagination bounds but omits the meaning of required parameters identifier and date, language behavior, and usage alternatives.

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 0% across 6 parameters, and the description only partially compensates: it explains that 'page or article chooses the page' and that 'contents adds the table of contents'. It leaves identifier, date, and language undocumented, including the required identifier and date.

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 indicates this tool assembles an evidence bundle for quoting a Luxembourg state, listing article text, digests, permalink, sources, and identities. However, it never states a clear action verb (e.g., 'retrieve' or 'compose') and does not distinguish the tool from siblings such as citation, provenance, or verify.

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 'What a quote ... needs' hints at a use case, but there is no explicit guidance on when to use this tool vs alternatives, when not to use it, or any prerequisites. It also does not route the agent to a sibling tool for different needs.

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 behavioral burden, yet it does not say whether this is a read-only lookup, what permissions are needed, how pagination works despite the limit parameter, or what the response contains. The vague phrase 'works with' provides essentially no 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?

It is a single short sentence, but it is not concise in a useful way: it is under-specified, awkwardly worded, and does not front-load what the tool actually does. The brevity reflects missing information rather than efficient structure.

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 five parameters, no annotations, and no output schema, this description is far too thin. It leaves the agent without enough information to invoke the tool correctly or understand its results.

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?

There are five parameters with 0% schema description coverage, and the description only gestures at the required date. It says nothing about limit, language, identifier, or after_work_key, so agents get no semantic guidance for most inputs.

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 name and the phrase 'state applicable on a date' hint that this concerns Luxembourg legal state at a point in time, but the verb 'works with' is vague and the sentence is ungrammatical. It does not state what the tool returns or how it differs from siblings like as_of or status_on.

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 no explicit when-to-use guidance, no exclusions, and no alternatives. It only implies that a date is relevant, leaving the agent to infer when this tool should be selected over closely related siblings.

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, yet it never states whether this is a read-only lookup, what permissions or scope are needed, or how errors/empty results behave. The phrase 'the retained one marked with its body digest' hints at retention logic and an integrity marker but is too opaque to act on.

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?

It is a single sentence with no filler, but that brevity comes from under-specification rather than discipline: the sentence is a noun phrase with no action, no lead verb, and no structure an agent can parse into 'call this with X to get Y'.

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 annotations, no output schema, and 0% parameter documentation mean the description is the only source of truth, and it explains neither the input contract nor the operation. For a 3-parameter tool it is not sufficient to invoke 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 0% for all three parameters. The word 'formats' loosely echoes the format param, but the required identifier (what namespace — a Luxembourg work ID?) and the language filter are completely undocumented, so an agent cannot know how to scope the query.

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 sentence reads like a description of the returned data structure rather than an action; there is no verb saying what the tool does or what it returns to the caller. 'Manifestation' is restated in domain jargon ('publisher's manifestations of a Luxembourg work's expressions') with nothing that separates it from siblings like classification, relations, or provenance.

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 when-to-use, when-not-to-use, or alternative is named, despite a sibling set full of overlapping bibliographic tools (classification, relations, coverage, provenance). The agent is left to infer selection entirely from the tool name.

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 behavioral burden. It implies a read of retained provenance data but says nothing about permissions, read-only nature, response format, or any limits, leaving the agent without the operational context needed for a query 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 a single short fragment with no wasted words, but it is not front-loaded with an action or clear structure. Its terseness reflects under-specification rather than efficient communication.

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 no output schema, no annotations, and 0% schema description coverage on three parameters, the description is not complete enough to support correct invocation. It states the returned subject matter but omits parameter meaning, usage routing, and behavioral expectations.

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 0% for three parameters, and the description does not explain what identifier, date, or language mean. The phrase 'behind a Luxembourg state' weakly suggests the parameters identify a state, but it does not clarify whether identifier is a legal act ID or whether date is an effective/version date.

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 names the resource it returns—retained sources, rule profiles and digests—and scopes it to a Luxembourg state. However, it is a noun fragment with no verb, and it does not distinguish this from siblings such as evidence_bundle or citation, so an agent cannot confidently tell what action it performs or how it differs.

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?

There is no indication of when to use this tool versus alternatives like evidence_bundle, citation, or as_of. The description gives no context about the scenario that selects provenance over its many siblings.

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 disclosure burden. It usefully states that results are ordered and paged and that both edge directions are included, but it says nothing about return shape, ordering key, authentication, 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?

A single front-loaded sentence with no filler. It conveys purpose, scope, ordering, and pagination efficiently.

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 6-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It covers the high-level purpose but omits parameter meanings and the structure of returned reference edges.

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 0% across 6 parameters. The description only hints at 'paged' for after/limit and 'both directions' for direction; it does not explain identifier, date, or language, leaving most parameters undocumented.

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 identifies the resource (reference edges of a Luxembourg work) and the shape of the result (one ordered, paged list). It implicitly distinguishes itself from directional siblings like citation and cited_by by saying 'both directions,' though it never names an alternative.

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?

Usage is only implied: an agent can infer this is the tool for getting all relations in either direction. There is no explicit guidance on when to prefer citation, cited_by, provenance, or timeline, and no when-not-to-use clause.

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 bears the full burden. It implies a pure lookup, but never states that it is read-only/non-mutating, what happens when an identifier is unresolvable or ambiguous, or whether external hash-pinned permalinks are dereferenced (with any network/auth implications). With no output schema either, the return behavior is left entirely unstated.

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?

One sentence, front-loaded with the verb, and each clause carries information: the domain qualifier narrows scope, and the two accepted input forms plus the resolution target define the operation. No filler or restatement of the tool name.

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 single-input lookup tool with no annotations and no output schema, the description adequately conveys what the tool does and what inputs it accepts. It falls short on failure modes, ambiguity handling, and the shape/meaning of the resolved work and expression data, which an agent would want before invoking it in a pipeline.

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 0% and the single parameter is only typed as a non-empty string, so the description must compensate. It does add real meaning by naming the two accepted forms (legal-act identifier vs. hash-pinned permalink), but supplies no format, syntax, or example for either, leaving the agent to guess what a valid value looks like.

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?

States a specific verb (Resolve) and a specific input->output mapping: an identifier or permalink to 'the work and expression it names'. The domain scoping ('Luxembourg legal-act') is clear. It does not explicitly contrast itself with siblings like search, browse, or citation, but the FRBR-style work/expression resolution is distinctive enough to infer separation.

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?

Usage is implied by the accepted input kinds (identifier or hash-pinned permalink): an agent understands it is the tool for turning a known reference into work/expression entities. However, there is no explicit when-to-use/when-not guidance, no statement of prerequisites, and no routing toward alternatives such as search when only a partial reference is available.

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 does add some behavioral context: results are constrained by rights ('text they withhold is not matched'), a 'typed refusal' is possible, and search can be 'strict or relaxed'. It omits return shape, ordering, pagination behavior, and any permission model beyond the vague 'rights' reference.

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 entire definition is a single dense run-on sentence joined by semicolons, with the core action buried mid-sentence after a long conditional clause. It is hard to parse and not front-loaded.

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 seven-parameter tool with no annotations, no output schema, and 0% schema coverage, the description leaves too much unspecified: most parameters, the return format, and clear distinction from the many sibling lookup tools are absent.

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 0% for seven parameters, so the description must compensate. It only indirectly touches 'query', 'mode' ('strict or relaxed'), 'identifier' ('one EU work named by identifier'), and possibly 'date'; 'after', 'limit', and 'language' are never explained, and no formats or constraints are given.

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 does indicate two functions — resolving an exact reference and searching 'held Luxembourg article text' — but the phrasing is so idiosyncratic ('the address its act opens at', 'its held wording') that an agent cannot quickly state what the tool does. It never names or contrasts with siblings like resolve, citation, browse, or ask.

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?

Conditional routing is present: 'with no work named' leads to exact-reference resolution, 'otherwise' leads to article-text search, and 'for one EU work named by identifier' leads to wording retrieval. However, no alternatives or exclusions are named, so the agent must infer when to prefer sibling tools such as resolve or citation.

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 behavioral burden. It does disclose useful behavior beyond the schema: the publisher assertions are returned verbatim, alongside an applicable state, under one fixed reading of the dates. It does not address authorization, idempotency, or error behavior, but it adds meaningful domain-specific context.

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 definition is compact, essentially one sentence with no obvious padding. However, it is syntactically dense and front-loads a noun phrase rather than a clear action, making it harder to parse than necessary.

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 no output schema, no annotations, and 0% schema description coverage, the description should explain both inputs and return shape more fully. It lists the returned fact fields, which helps, but leaves the language parameter unexplained and does not give a complete picture of how the response is structured.

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 0% for all three parameters, so the description must compensate. It gives some meaning for the work identifier and the date through phrases like 'about a Luxembourg work' and 'state applicable on a date,' but it never explains the language parameter or clearly maps behavior to the named inputs.

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 names a specific resource, a Luxembourg work, and the exact returned facts (inForceStatus, dateEntryInForce, dateNoLongerInForce), plus the applicable state on a date. That is more than a tautology and gives an agent a concrete sense of what the tool returns, though it does not explicitly distinguish itself from close siblings such as in_force_on or 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 implies the tool is used to retrieve force status on a given date, but it gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. In a sibling set containing in_force_on, as_of, and as_observed, that omission leaves the agent to infer routing.

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 still discloses meaningful behavior: it returns every state or wording and specifies ordering by publisher applicability or wording date. However, it does not state whether the operation is read-only, how results are structured, or whether pagination or permissions apply.

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 definition is a single dense sentence with no wasted words, and the core output is front-loaded. The semicolon cleanly separates the Luxembourg and EU act cases.

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 are no annotations and no output schema, and both parameters lack schema descriptions. The description explains output scope and ordering but leaves invocation-critical details such as identifier format, language behavior, and result structure unaddressed.

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 0%, so the description must explain the parameters, but it does not. The required identifier is only indirectly implied to identify a Luxembourg or EU act, and the optional language parameter is not addressed at all.

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 resource: a timeline of every state of a Luxembourg act or every wording of an EU act, with ordering rules. It distinguishes jurisdiction-dependent behavior, though it does not explicitly differentiate itself from siblings such as article_history, as_of, or events.

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 no explicit guidance on when to use this tool instead of alternatives like article_history, as_of, in_force_on, or events. The implied usage is to retrieve a full timeline, but no conditions or exclusions are 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?

With no annotations, the description carries the full behavioral burden. It hints at read-oriented behavior but does not state whether the operation is read-only, what happens on verification failure, what the return value is, or whether auth/rate limits apply.

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?

A single efficient sentence with no filler. It is appropriately short, though the compressed jargon and combined dual-mode clause make it slightly harder to parse than it needs to be.

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 two undocumented parameters, no annotations, and no output schema, this is too thin. It omits parameter meaning, mode selection, return shape, and failure semantics.

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 0%, so the description must compensate for both parameters. It never maps 'identifier' to the permalink being verified or explains what 'language' controls, leaving the caller to infer everything from the schema field names.

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 names a specific verb (verify) and target (a hash-pinned permalink against the index's state digest), plus an alternate read mode. It is technically precise, though the dual-mode framing and lack of sibling differentiation keep it from 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?

It mentions a second mode ('or read the current digests to pin') but gives no guidance on when to use verification versus digest reading, and never distinguishes this tool from siblings such as resolve, provenance, or citation.

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