Lexiara

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

Annotations cover safety (readOnly, idempotent, no destruction), and the description goes well beyond them: it discloses the authentication/gating model (definitions free; borrowing chains and citations need an API key on a signed-in account, else arrays empty and `gated` reports withheld counts), the `pivotWhy` per-instrument field, and the fundamental semantic rule that meanings are separated on facts only.

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?

Front-loads the resource scope in the first sentence, then layers usage, semantic constraints, and gating. Dense and largely earned, though the middle paragraph is lengthy and could be tightened without losing substance.

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?

An output schema exists, so return values need not be enumerated, yet the description still names key response fields (`pivotWhy`, `gated`) and explains what happens when the key is absent. For a one-parameter lookup tool, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% for the single `term` parameter, so the baseline is already 3. The description adds meaning the schema lacks: exact case-insensitive matching behavior, and that an alias (a borrower's own label) still resolves to the family it borrows into.

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 precise scope: one defined term across the whole corpus, returning each distinct wording, its defining instruments, borrowing chains, cited defining provisions, and other-language labels. This is distinguishable from siblings like define_term or term_languages, and the concrete example ('producer' under WEEE vs Batteries Regulation vs PPWR) pins down what 'family' means.

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?

Gives an explicit trigger condition: ask this when a term is defined differently across instruments and the answer depends on which. It also clarifies the alias-query routing behavior. It does not, however, name sibling alternatives (e.g. define_term) to say when NOT to use this tool, 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: definition text is free, the adoption resolution requires authentication/API key, and multiple instruments can return multiple rows whose scope is tied to the carrying instrument.

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?

Every sentence earns its place: purpose, usage guidance, multi-definition caveat, and access requirements are all included without redundancy. The most important differentiation is front-loaded in the second sentence.

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

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

The description is complete for a read-only lookup tool: it explains when to use it, what it returns, how scope works, and what authentication limitations exist. The presence of an output schema covers return-format details, so nothing critical is missing.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds some meaningful context about the 'work' parameter through the scoping caveat, but it does not substantially add parameter-level semantics beyond what the schema provides.

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

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

The description clearly states what the tool does: it returns the verbatim definition of a term of art and the provision that gives it. It explicitly distinguishes itself from search_legislation, which returns provisions that use a phrase rather than define it, so an agent can select it confidently.

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 explicit when-to-use guidance: ask this tool BEFORE search_legislation whenever the question is what a phrase means. It also names the sibling alternative, explains the difference, and warns about multi-instrument definitions with scope caveats.

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?

Annotations only declare read-only/idempotent/closed-world safety. The description adds substantial context beyond that: what a country link carries (relationship type and review state), that informative national text is surfaced only as a separate research lead, the coverage-gap semantics ('an absent link is a coverage gap, never proof that national law is absent'), and the auth/cost profile ('ordinary signed-in Nexus allowance').

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?

Front-loads the core purpose and keeps each subsequent sentence to a distinct, load-bearing point (output contents, link semantics, coverage-gap rule, scope limit). It is dense and slightly long, but no sentence is pure 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?

Given 7 optional parameters, an output schema, and rich annotations, the description covers the behavioral and interpretive context an agent needs. Minor gap: it doesn't hint at how to compose valid role keys or what an empty result implies beyond the coverage-gap note, but the schema handles the mechanics.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters, including the comma-separated role-key format and date format. The description restates which inputs are available (roles, activity, product, Spain/France, date) without adding syntax or constraint detail beyond the schema, so the baseline 3 applies.

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 and resource ('Research source-bound EU role requirements') and enumerates what it returns: exact passages, act-specific definitions, conditions, unknown facts, and EN/FR/DE/IT source availability. It is clearly distinct from generic siblings like define_term or search, though it never names an alternative tool explicitly.

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?

Gives usage context (select multiple roles, optional activity/product/country/date) and a boundary ('bounded research aid, not a compliance verdict'), which implies when to reach for it. However, it never contrasts itself with the many sibling research tools (define_term, find_national_implementations, guidance_for_provision), leaving the agent to infer the choice.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful behavior: an empty container text does not mean the law is absent, and metadata.structure carries parent/child addresses. Missing rate/timeout or error behavior keeps it short of 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with purpose and return scope before the traversal and id-handling caveats. Nothing is padding, though the sentences are dense and the traversal note could be trimmed slightly.

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?

An output schema exists, so return-value documentation is not required, yet the description still orients the agent on structure and empty-container semantics. Traversal guidance and input provenance complete the picture for a single-parameter read tool.

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

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

Schema coverage is 100% and the schema already calls the id opaque and search-returned, so baseline is 3. The description goes further by warning against editing the id, adding a usage constraint the schema does not encode.

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 and resource ('Retrieve one search result by its opaque id') and enumerates the returned content (provision text, canonical URL, authority status, provenance), which distinguishes it from the sibling `search` and from `lookup_provision`. An agent can tell what this tool does without opening the schema.

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 names the alternative route ('Use child apiHref links or lookup_provision with sourceLang to traverse') and constrains input provenance ('ids returned by search without editing them'). That gives clear context and a fallback path, though it never states an explicit when-not-to-use condition for this tool versus lookup_provision.

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?

Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real context beyond them: the data is DERIVED and not authority-published, non-'human' links need verification, evidenceStatus can be informative-not-authoritative or stale, and an API key with a monthly allowance is required. That is meaningful behavioral disclosure.

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?

Core behavior is front-loaded in the opening sentence, followed by interpretation caveats. The auth block is somewhat boilerplate but still earns its place as a required precondition. Slightly long but well-structured overall.

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

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

The tool is a filtered lookup with an output schema, so return values need not be restated. The description covers derivation caveats, staleness, and auth requirements. It leaves out any mention of how results are ordered or limited, which 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?

Schema description coverage is 100%, so the schema already documents all four parameters (eId format examples, work ELI, jurisdiction ISO, minConfidence range). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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 first sentence states a specific verb+resource: national provisions implementing one EU provision, returned with method and confidence per link. It is clearly distinguishable in concept from sibling provision tools. However, it never names an alternative sibling to route against, so it stops short of a 5.

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

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

The description gives interpretation rules (treat non-human links as leads to verify, check evidenceStatus) but no explicit when-to-use/when-not or named alternatives such as lookup_provision or provisions_by_concept, which appear in the sibling list. Usage is implied rather than 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?

Annotations only cover the safety profile (read-only, idempotent, non-destructive), while the description adds genuinely non-obvious behavior: the grade is Lexiara's own assertion rather than the publisher's, it warns against treating 'major' as a finding, and it discloses that 'via-transposition' links are unreviewed evidence. That epistemic framing is exactly the kind of context annotations cannot supply.

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 front-loaded and every sentence carries content, but the single dense paragraph is heavy for a three-parameter, all-optional list tool, and the grade taxonomy is delivered in nested parentheticals that are harder to scan than a short list would 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?

With an output schema present, return values needn't be explained, yet the description still clarifies the two most interpretive output fields, significance grade and reach. It omits anything about pagination or default ordering, which keeps it short of fully complete.

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

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

Schema description coverage is 100%, so limit, since, and minSignificance are already documented in the schema; the description only restates the grade vocabulary for minSignificance. It does, however, add output-side semantics for 'reach', which is not an input parameter. Baseline 3 is appropriate when the schema carries the parameter burden.

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 opening line ('The digest: every change the corpus observed on followed law') names the resource and scope precisely, and the 'followed law' framing separates it from corpus-wide siblings like recent_changes or search. It is clear but never explicitly contrasts itself with those siblings, so an agent must infer the boundary.

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 rather than stated: the tool is for law you follow, and grades are described as 'a prompt to read the instrument'. There is no explicit when-to-use or when-not-to-use guidance relative to recent_changes, list_follows, or provision_history, leaving the agent to infer the 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?

The description explicitly states 'absence of coverage means "not here", never "does not exist"', which is an open-world behavioral claim. This contradicts the annotation openWorldHint: false, which suggests the tool treats absence as authoritative non-existence. While the description otherwise adds useful context about gap types and request_hint, the annotation contradiction makes it misleading.

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 compact and front-loaded: it states the core purpose, then the primary use case, then the optional work behavior. Every sentence adds operational value, and the formatting with a short first sentence and a focused paragraph makes it easy for an agent 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?

The tool is simple with two optional parameters and has an output schema, so the description does not need to document return values. It covers when to call, how to interpret absence, the effect of the work parameter, and the categories of gaps. Nothing essential for correct invocation is missing.

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?

With 100% schema coverage, the schema already documents the work and language parameters. The description adds meaning beyond that by explaining what happens when work is passed: the answer classifies the absence as metadata-only, language-not-held, or not-held, and carries requestable and request_hint. This helps the agent understand the parameter's effect on the response.

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 and resource: reporting per-source coverage and freshness of Lexiara's holdings. It immediately distinguishes the tool's use case from siblings by saying to call it first when unsure whether Lexiara holds the law.

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 explicit guidance on when to call: 'Call this first when unsure whether Lexiara holds the law you need.' It also explains the crucial semantic that absence of coverage means 'not here', never 'does not exist', which prevents misuse. It does not name specific sibling alternatives or exclusion conditions, 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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds important behavioral detail: the meaning of each state, the distinction between 'failed' (will be retried) and 'confirmed_unavailable' (publisher does not hold the manifestation), and the account-level read restriction. This is genuinely valuable context for the 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 dense but well-organized: the first sentence states the core purpose, the second explains critical state semantics, and the third covers access control. Every sentence earns its place with no repetition or 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?

Given the presence of an output schema, robust annotations, a single required parameter, and the detailed state semantics in the description, the agent has everything needed to call this tool correctly and interpret its response. The only minor absence is an explicit pointer to get_ingestion_result for retrieving the final result, but that is not necessary for completing the description.

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

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

Schema description coverage is 100%, so the schema already fully documents request_id. The description adds the context that it is 'one request you made' and that readability is account-scoped, but these are not parameter-specific semantics beyond what the schema communicates.

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 returning state, stage, reason code, and wait time for a single ingestion request. It is specific and informative, but it does not explicitly differentiate itself from the sibling tool get_ingestion_result, so it falls short of a 5.

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

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

The description implies polling usage through 'time to wait before asking again' and notes the account restriction, but it does not explicitly state when to use this tool instead of get_ingestion_result or how to proceed once the state is available. Usage context is present but exclusions and alternatives are not.

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 strong annotations (readOnlyHint, idempotentHint, non-destructive) already covering the safety profile, the description adds genuinely valuable interpretation context: the clarification that 'coverage: complete_for_scope' refers only to the DECLARED SCOPE, never to completeness of legal research, directly corrects a likely misreading. The citation directive (cite the manifest URL, not this tool) also adds behavioral guidance beyond the annotations.

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 dense but not padded; every clause earns its place — the handle list, manifest fields, follow-up lookup instructions, the citation rule, and the crucial coverage clarification. It opens with the most important information (what comes back). The first sentence is a long verb-less fragment, which slightly hurts readability, but no sentence is wasted.

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 one-parameter retrieval tool with an output schema, strong annotations, and detailed payload/citation/coverage guidance, the description is largely complete. The main gap is the unaddressed relationship to the sibling get_ingestion_request — an agent gets no guidance about whether to consult request status separately or whether results fail if ingestion is still running. Minor gaps against an otherwise thorough description.

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

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

Schema description coverage is 100% — the single parameter request_id is fully described as 'The request_id request_ingestion returned.' The description adds nothing about request_id's semantics, but per the high-coverage baseline, a 3 is appropriate since the schema already does the heavy lifting.

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 uses an explicit verb like 'returns' or 'retrieves', but the title ('What an ingestion request produced') plus the detailed enumeration of contents (handles, manifest, expectation results) makes the purpose clear. It also differentiates from siblings by listing unique payload elements (expression id, work ELI, manifest fields) that get_ingestion_request or request_ingestion would not produce.

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 guidance is implied rather than explicit: 'Repeat your original lookup with the handles' and 'Pass expressionId as the exact expression query parameter' tell the agent what to do after retrieving results, and the citation instruction is clear. However, the description never names alternatives or states when to use this tool versus get_ingestion_request, so the when-to-use-vs-siblings guidance is absent.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the trailing 'Read-only' adds nothing. The genuinely added context is the breakdown of the change list (publisher versions, parser corrections, newly acquired material, review status), which is behavioral detail beyond annotations, though partly overlapping the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and follow-up guidance. The enumeration of change categories is somewhat long but earns its place by telling the agent what the view surfaces; only the redundant 'Read-only' is waste.

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-parameter read tool with an output schema and full annotation coverage, the description covers purpose and behavioral cues adequately. Return values are left to the output schema, which is appropriate; nothing critical is missing.

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?

Only one parameter, fully documented at 100% schema coverage as 'UUID returned by list_saved_role_views.' The description adds no syntax, format or sourcing detail beyond that, so the baseline 3 for high coverage 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?

States a specific verb and resource: 'Recheck current official passages and connections against a private saved view.' An agent can tell this is a read/refresh of a saved view rather than a listing or creation tool. However, it does not explicitly name or contrast with the sibling list_saved_role_views, leaving differentiation implicit.

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

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

The description implies when to use it ('Recheck ... against a private saved view') and adds a workflow cue ('inspect the cited current result before relying on a connection'). But there is no explicit when-not guidance or named alternative to route the agent elsewhere.

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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety bar is low, and the description adds substantial interpretation guidance instead: GB notes carry an assimilated-law caveat, editorial status can be draft or published, and 'anything not method=human is evidence, not a finding.' That last warning materially changes how an agent should treat the data. It does not touch auth, rate limits, or sizing, so not a 5.

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 ('Everything a topic page shows: ...') with no filler, and every clause maps to a distinct part of the payload. It is dense with em-dash-nested qualifiers, which slightly hurts scannability, keeping it from a 5.

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 an output schema present, return values need not be explained, and annotations carry the safety profile; the description usefully adds the interpretive caveats. The missing piece is routing guidance against the many sibling retrieval tools, which leaves a small but real gap for a single-topic fetch.

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

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

Schema description coverage is 100%: conceptId is documented with a concrete example ('local:topic-pre-contract-information'). The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

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+resource ('get_topic') and then enumerates exactly what a topic page contains: orientation paragraph, per-jurisdiction notes, anchored provisions, transposition links, related instruments. This is far beyond a tautology. It stops short of naming sibling tools (list_topics, provisions_by_concept) by name, so the differentiation is implied rather than explicit.

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

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

The description never says when to use get_topic versus alternatives such as list_topics (list vs single), provisions_by_concept, or lookup_provision/provision_context. There is no when-to-use or when-not guidance, only an inventory of returned content, so the agent must infer the routing itself.

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

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

Beyond the readOnly/idempotent annotations, it discloses that every row is non-binding (binding: false), that this is the enforcing body's reading rather than law, and how it must be presented. It also states the auth requirement (API key on a signed-in account) and the free-plan allowance, which annotations cannot convey.

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 message is front-loaded with the core purpose and scoped into purpose, caution, and access paragraphs. It is slightly repetitive in restating the 'cite as guidance, not the rule' point twice, but every paragraph carries distinct information.

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 an output schema present, return values need no explanation, and all three parameters are documented in the schema with annotations covering the safety profile. The description fills the remaining gaps — non-binding status, citation discipline, and authentication requirements.

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

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

Schema description coverage is 100%, so eId, work, and includeActLevel are already fully documented in the schema. The description adds citation formatting context ('section number the publisher prints') but nothing about parameter syntax or defaults beyond what the schema provides — the baseline 3 applies.

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 opening sentence states a specific verb and resource — 'Sections of official GUIDANCE that discuss one provision' — and immediately contrasts it with the legislative text that lookup_provision returns. An agent can distinguish this from sibling tools without opening the schema.

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 clear usage context (use for verifiable citations like '§2.8 of the UCPD Guidance') and names the alternative to keep it separate from — lookup_provision. It stops short of an explicit 'use this when / do not use this when' rule set, so 4 rather than 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?

Annotations already declare a safe read (readOnly, idempotent, non-destructive), yet the description adds genuinely non-obvious behavior: the transitive borrowing rule ('an act that takes ... from the DSA, which takes it from the AVMSD, counts for the AVMSD'), the fact that the list is uncurated ('Nothing in the list was chosen by hand'), and a warning about count semantics. That exceeds what the annotations convey.

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 content is nearly all substantive, but it is delivered in dense, nested constructions (the parenthetical chain and the tier gloss) that are hard to scan. The core purpose is technically front-loaded but the sentence runs long before the reader reaches the point.

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 an output schema present, return values need no explanation, yet the description still clarifies output semantics that would otherwise be misread (tier meanings, and that reachWorks is a union of populations, not a sum). Combined with annotation-covered safety and a fully documented schema, the definition is close to complete for its 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?

Schema description coverage is 100%, with `limit` enumerating allowed values and `jurisdiction` giving an example, so the schema carries full parameter meaning. The description adds no syntax or format detail for either parameter beyond echoing that jurisdiction is a reach filter. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

It states a specific resource ('terms of art') and the exact ranking criterion (how many instruments DEFINE, BORROW, or CITE a defining provision), and it names the sibling to escalate to ('then call concept_family for one of them'). The purpose is clear but buried inside a long, clause-heavy first sentence, so an agent must parse nesting to extract it.

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?

Explicit when-to-use framing is present ('Use it to find the anchoring concepts of an area... then call concept_family for one of them'), plus it explains the discriminating meaning of the `tier` values 'pivotal' vs 'shared'. It stops short of stating when NOT to use it versus other term-oriented siblings like define_term or work_glossary.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds significant behavioral context: it explicitly labels the operation READ-ONLY, explains that follow changes happen via HTTP POST/DELETE to /v1/follows (not via any tool here), and specifies that the caller must use their own key, not the shared demo key. This goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the purpose, and packs essential caveats (read-only, key requirement) without extraneous wording. Every clause earns its place, and it is well-structured for quick 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?

Given the tool has no parameters and an output schema exists (so return format is covered elsewhere), the description is complete. It covers the scope, the read-only nature, the impossibility of mutating follows through this catalogue, and the key ownership requirement. Nothing an agent needs to correctly invoke or interpret the tool is missing.

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 tool has zero parameters, so per the rubric the baseline is 4. There is nothing to add beyond what the schema provides (which is empty), and the description appropriately focuses on the operation's semantics rather than parameter details.

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 listing the instruments, provisions, subjects, jurisdictions, and verticals that an API key follows. It uses a specific verb ('lists'), a resource ('follows'), and enumerates the scopes, distinguishing it from sibling tools that might operate on follows in other ways.

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 when to use this tool (to see what the key follows) and explicitly states that no tool in the catalogue dispatches follow creation/removal, which guides the agent away from trying to mutate follows. It also warns that the shared demo key is refused, providing a clear prerequisite. However, it does not name a specific alternative tool for follow management, only states that none exists.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond this by stating it does not start, repeat, or alter acquisition work, plus the 50-item cap, ordering, and privacy guarantee that another account's requests are never returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that front-load the key behavior (list up to 50, newest first), then add scope and safety details. No filler or redundant 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 zero-parameter read-only list tool with an output schema and strong annotations, the description covers everything needed: result limit, ordering, account isolation, and non-mutating behavior. Nothing essential is missing.

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 zero parameters, so the baseline is 4. The description adds context about the returned rows (status fields like intent, created_at, origin), which is useful even though it is not parameter-related.

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

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

The description uses a specific verb ('List') and resource ('ingestion requests'), and adds precise scope: up to 50, newest first, belonging to your account. This distinguishes it clearly from siblings like get_ingestion_request (single request) and request_ingestion (creating requests).

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 clearly states what kind of requests are returned and the account scoping, so an agent knows when to call it. It does not explicitly name alternatives or say 'use get_ingestion_request for a single request,' but the scope and list behavior make the intended use obvious.

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?

Annotations declare readOnly/openWorld/idempotent, and the description reinforces read-only behavior and explains the human-only verdict mechanism. It also discloses that all items are unreviewed evidence not to be cited as findings, and warns that truncating provision text can hide content. This goes well beyond the annotations.

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 dense but purposeful: one flowing definition, then the safety warning verdicts, then filter summary MendReadOnly. The ALL-CAPS warning earns its place. Slightly long, but every clause carries distinct information. Front-loaded with the subject and ordering.

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?

Even though there is an output schema, the description gives the essential context: what items appear, that they are ordered newest first, that they are paged, what each kind means, and the critical citation caveat. An agent can select and invoke this tool safely without further exploration.

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% (all 7 params have descriptions), so the baseline is 3. The description adds meaning by grouping filters (kind, vertical, jurisdiction), explaining the 'chars' truncation hazard with a concrete example (French code article), and clarifying that omitting lowConfidence means model tags only. That extra semantics justifies a 4.

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?

Description names a specific verb (list), a distinct resource (the human-verdict review queue), and defines its exact contents (unreviewed article-level transposition links with reasoning, tags, topic descriptions, jurisdiction notes, findings). It clearly differentiates this tool from the sibling search/list tools by foregrounding the auto-gated, unreviewed, evidence-only nature of the backlog.

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 makes the intended context explicit: this is the unreviewed, auto-gated work queue a human must decide on desserts? It states filter options and the ordering. It does not explicitly name alternative tools for other use cases, but the title and the 'UNREVIEWED EVIDENCE' warning make selection unambiguous against the siblings. Could name when not to use it, but the exclusions are implicit in 'UNREVIEWED'.

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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the bar is lower. The description adds genuine value beyond them: results are private to the connected account, each view is a snapshot for comparison rather than a compliance verdict, and write/delete operations live outside this 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?

Three tight sentences with no filler: scope first, then the interpretation caveat, then the access limitation. Nothing is repeated from the name or annotations, and the most important constraint is 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?

With an output schema present, the description need not explain return fields, and it supplies the scope and caveat an agent needs to interpret them. It is essentially complete for a zero-parameter list tool; only the relation to get_saved_role_view is left implicit.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly introduces no parameter-like concepts.

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 gives a specific verb and resource ('List private role and country research views') plus ownership scope ('belonging to the connected account'), so an agent knows exactly what comes back. It does not name the singular sibling get_saved_role_view or explain how the two differ, so it falls short of full sibling differentiation.

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 states the read-only nature and clarifies that saving and deleting views require the person's own HTTP account access, which effectively tells the agent this tool cannot mutate anything. No explicit alternative (e.g. get_saved_role_view for a single view) is named, so the routing guidance is implied rather than complete.

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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: it warns that draft editorialStatus entries are unreviewed model drafts and instructs the agent to disclose this when quoting. This is meaningful additional 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 compact and front-loaded: it states the purpose first, then describes output contents, then flags draft-status behavior and downstream usage. Every sentence earns its place with no redundancy.

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

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

For a read-only listing tool with one fully documented parameter and an output schema, the description is complete. It covers what is returned, important quality caveats, and how to proceed with a result, leaving no critical gap for an agent to call it correctly.

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

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

Schema coverage is 100%, and the schema already defines 'subject' as a subject head concept id with an example. The description repeats the 'subject head' concept but does not add new parameter semantics beyond the schema, so the baseline of 3 applies.

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 a specific verb (list) and resource (curated obligation topics under a subject head), and distinguishes itself from the related get_topic by noting that results should be fed into get_topic. This is more than a restatement of the title and gives an agent a precise idea of what the tool returns.

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 clear context for when to use the tool: to get curated topics under a subject head with orientation and anchor counts. It also implies the follow-up action (feed conceptId to get_topic), though it does not explicitly list when-not-to-use scenarios or alternative listing 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real semantic context the annotations cannot: entries carry expression IDs, source hashes, consolidation markers, and the warning that markers identify text but do not prove when it applied. Pagination/limits are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences with no filler; the core scope is front-loaded, followed by entry contents, the semantic caveat, the handoff to lookup_provision, and the asAt condition.

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?

An output schema exists, so return-value explanation is not required, yet the description still characterizes entries usefully. The only gap is the unexplained asAt reference, which has no matching input parameter.

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

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

Schema description coverage is 100% with only two params, so the schema already documents work (ELI URI) and sourceLang. The description adds no further parameter detail, and its mention of 'asAt' does not correspond to any input parameter, which slightly muddies rather than clarifies.

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

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

The description states a precise verb and resource ('Find same-language publisher expressions for one EU act') and scopes it to held official text versions, which distinguishes it from siblings like lookup_provision, provision_history, and recent_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?

It gives explicit downstream routing ('Pass a returned expression ID to lookup_provision to read that exact text') and a conditional rule for asAt ('only when the source carries an explicit validity window'). It stops short of naming when-not-to-use or contrasting against other listing tools such as provision_history.

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?

Annotations already declare read-only/idempotent/non-destructive, but the description adds substantial context beyond them: a named refusal mode (`date_not_covered`), an explicit no-machine-translation policy, entitlement gating ('provision text is always free; only gated counts require an API key'), and the rule that empty container text means 'follow children' rather than missing law.

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?

Purpose is front-loaded and each sentence carries distinct information, but the paragraph on output fields (`stand`, `sentence`, `structure`, `gated.citedByArticle`) is dense and partly overlaps the output schema. The description is long, though the length is largely justified by the tool's complexity.

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

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

Given an output schema exists, the description does not need to document return values, yet it covers everything an agent needs: refusal behavior, entitlement boundary, language selection, point-in-time semantics, and container/child traversal. Nothing material is left for the agent to guess.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds nuance the schema does not carry, such as `sourceLang` being combinable with `asAt`, and that children should be followed with the same `sourceLang`/`asAt`. The explanation of `asAt` and `sourceLang` semantics largely restates the schema, so it is not a full 5.

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 first sentence names a specific verb and resource ('Authoritative text of one provision') and enumerates the payload (in-force window, status, tags, transposition edges, provenance). It also explicitly distinguishes itself from a sibling by stating that citation rows come from provision_context rather than this tool.

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

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

It gives explicit conditions: use `asAt` only where a held expression has a validity window covering that date, otherwise expect `date_not_covered`; omit `asAt` for current text; use `sourceLang` to select held text and never to translate. It also routes to alternatives ('Use term_languages for authentic multilingual terminology', provision_context for citation rows).

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?

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds material beyond that: the API-key/signed-in-account requirement and the free-plan Nexus allowance, plus a subtle output trait (citedBy returning the same act-level list on every provision).

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?

Purpose and the citedByArticle/citedBy distinction are front-loaded, and the auth note is a compact trailing paragraph. It is somewhat dense and slightly long, but every sentence carries information.

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 an output schema present the description need not explain return values, and it still usefully flags the two output fields that are easy to confuse. Combined with the auth disclosure, an agent has enough to call it correctly; the only gap is the absence of explicit sibling routing.

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

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

Schema description coverage is 100%, so both parameters (eId, work) are already documented. The description adds no syntax, format, or identifier guidance beyond the schema, so the baseline 3 applies.

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 precise verb+resource: 'cross-reference neighbourhood of a provision plus its amendment history', and disambiguates its output concepts (citedByArticle vs citedBy). It does not explicitly contrast itself with closely named siblings such as provision_history or related_works, so an agent must infer the boundary.

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?

Gives a concrete trigger: 'Use this when a provision's relevance is not on its face', with a worked example of a silent cross-reference. It stops short of naming when NOT to use it or routing to alternatives like lookup_provision, but the use condition is clear.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is covered. The description adds genuinely new context: an API key on a signed-in account is required and a monthly allowance applies on the free plan, which is quota/permission information not present in the annotations.

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?

Front-loaded with the core purpose in one tight sentence, with no redundancy. The account/allowance sentence is slightly boilerplate and arguably account-level rather than tool-level, but it is behavioral information and reasonably brief.

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 read tool with an output schema and full annotation coverage, the description supplies the missing pieces: what the tool returns conceptually (version lineage) and the auth/quota constraint. Return-value detail is legitimately delegated to the 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?

Schema description coverage is 100%, so both eId and work are already fully documented in the schema with format examples and discovery hints. The description adds no parameter meaning, making the baseline 3 correct.

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 and retrieval scope: prior and successor versions of one provision across consolidations. An agent can distinguish this from lookup_provision or provision_context by the 'across consolidations / version history' framing, though no sibling is named explicitly.

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 'how the text got to its current form' implies the use case (historical/version questions), but there is no explicit when-to-use guidance and no named alternative such as provision_context or lookup_provision for point-in-time retrieval.

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?

Beyond the readOnly annotations, the description explains the actual behavior: it returns all tagged provisions across jurisdictions and includes tagging method and confidence. This gives agents useful expectations about result content and scope, though it does not discuss limits or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loads the core behavior, and uses examples effectively without verbosity. Each sentence adds value: definition, example, and use-case rationale.

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 read-only listing tool with a rich output schema and clear annotations, the description is nearly complete. It explains the concept-centric scope and cross-jurisdiction nature, but it does not explicitly mention whether there are pagination or size limits on results, which would be useful for an agent querying broadly.

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

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

The input schema already covers all three parameters at 100% coverage gift, and the description adds meaningful context with concrete concept ID examples)Skip. It does not add much semantic detail for jurisdiction or confidence filtering beyond the schema descriptions, but the example and language-neutral framing strengthen conceptId.

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 operation (cross-jurisdiction view of provisions by EuroVoc concept) and clearly explains what the tool returns: every provision tagged with the given concept, including tagging method and confidence. The examples ('eurovoc:4585', 'eurovoc:4392') anchor the concept and help distinguish it from more general search and definition tools.

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

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

The description provides clear context for when this tool is appropriate: when you need a language-neutral way to line up EU and national law on the same legal concept. It does not explicitly name alternative siblings or state when not to use it, which keeps it from 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?

Annotations already cover read-only/idempotent behavior. The description adds meaningful nuance beyond that: detectedAt reflects when the system observed the change, not the legal in-force date. This helps set expectations about timestamps without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose and filters, with a single important caveat about detectedAt vs. in-force dates. No filler or redundancy.

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

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

For a read-only list operation with a full output schema and all parameters documented, the description communicates the essential behavior and the one subtle timestamp distinction. It could be slightly more complete by naming sibling tools, but nothing critical is missing.

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?

Input schema covers all four parameters with clear descriptions (100% coverage), so the baseline applies. The description reinforces the role of jurisdiction, concept, and date filters but does not add significant new meaning beyond the schema.

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

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

The description gives a specific resource (“provisions”) and the nature of the feed (“added or modified”), plus the available filters (“jurisdiction, concept and date”). This is clear enough to orient an agent, though it doesn’t explicitly contrast with siblings like provision_history or follow_updates.

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 choose recent_changes over related tools such as follow_updates, provision_history, or search. The description explains what the tool does but not the context in which it is the right choice.

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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds the conceptual model of the edge directions, which is useful, but says nothing about result volume, pagination, or how edges are shaped (deferred to the output schema). Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core concept front-loaded and the sibling routing placed last as a disambiguation. Every clause earns its place.

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?

An output schema exists, so return-value explanation is unnecessary; with that in mind the description covers purpose, both direction modes, and cross-tool routing. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, including an explicit definition of 'in' vs 'out' and a worked ELI example, so the schema carries the parameter burden. The description reinforces direction semantics but adds no syntax or constraint 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 states a specific resource ('edges between instruments') and concretely illustrates what those edges mean (transposition, implementation, amendment) with the direction semantics. It also explicitly names the sibling it is not (find_national_implementations) and the granularity boundary, so an agent can distinguish it without opening schemas.

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 an explicit routing rule: use this for instrument-level links, use find_national_implementations for article-level links. The direction values are also tied to concrete use cases ('which national laws transpose a directive' vs 'what an instrument implements/amends'), so the agent knows which mode 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?

The description goes well beyond the annotations: it discloses that the target is validated, fetched from the publisher's own bytes, run through the same fail-closed checks, and returned as handles for repeating the original lookup. It also clarifies that expectations are hypotheses, not instructions, and that contradicted expectations leave the publisher's text untouched. The idempotent behavior, async retry_after polling, and auth consent limitations are all disclosed, and nothing in the description contradicts the annotations.

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 long, but it earns most of its length with clearly separated sections: core usage, what the tool is not, expectations semantics, and operational caveats. Front-loading the main invocation scenario helps an agent quickly understand the tool's purpose. Some repetition exists around `proposed_sources` never being dereferenced, which also appears in the schema, so it is not perfectly lean.

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

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

Given the tool's complexity — 13 parameters, enums, nested objects, async behavior, auth boundaries, and idempotency — the description is remarkably complete. It covers when to call, what will happen, what will not happen, how expectations are handled, how idempotency works, how to poll, and what auth is required. The output schema exists, so the description need not restate return shapes, and nothing critical for correct invocation is missing.

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 cooverage is 100%, so the baseline is 3 and the description does not need to compensate for undocumented parameters. The prose adds helpful cross-cutting context like idempotent keys, private rationale, and expectations being checks rather than instructions, but it does not systematically add per-parameter meaning beyond whatthe schema already provides. This is a solid 3 rather than higher because the extra value lies in behavioral context, not 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 states a very specific verb and resource: when a lookup returns `coverage` with `requestable: true`, ask Lexiara to acquire the missing law by creating an ingestion request. It clearly distinguishes this from siblings like get_ingestion_request, get_ingestion_result, and list_ingestion_requests by emphasizing that this tool creates a request rather than reading or listing one.

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 explicit when-to-use guidance: only after a lookup indicates `requestable: true`, and explicitly says not to stop or guess. It also names exclusions: it never fetches a user-supplied URL, never interprets law, and requires `ingestion:request` consent beyond a read-only OAuth grant. It even points to the polling flow with get_ingestion_request, making the alternative workflow clear.

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?

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond this: results are compact, ids are opaque, and an id should be passed unchanged to a fetch operation for full text and provenance. This provides a clear next-step workflow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose and followed by the result-handling behavior. Every sentence earns its place and there is no redundancy or 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 simple one-parameter search tool with a rich output schema and safety-relevant annotations, the description covers the essential workflow: search, receive compact results, and follow an opaque id to fetch full provision details. Nothing critical is missing.

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

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

Schema description coverage is 100%, and the single 'query' parameter is adequately described as a natural-language or keyword search. The description adds no additional query-format guidance, but with full schema coverage 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 states a clear action ('Search') and a specific resource ('Lexiara's bounded EU and UK legislation corpus'), and it explains the nature of results. It does not explicitly differentiate from the sibling tool 'search_legislation', so it stops short of full sibling distinction.

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 clear context for when to use the tool: when searching a bounded EU and UK corpus and wanting compact, citable results. It does not mention alternatives or exclusion conditions, but the boundary is reasonably clear.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds value beyond annotations by disclosing that results are ranked and by listing the result fields (work, eId, status, provenance), plus the relationship to lookup_provision.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler; the first sentence states the core behavior and scope, and the second adds return-field context and a downstream pointer. Every clause earns its place.

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 full schema coverage, safety annotations, and an output schema present, nothing essential is missing for selecting and invoking this tool. The description covers ranking, result contents, and how to get the complete payload.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters. The description does not add parameter-specific meaning beyond saying the search is full-text over provision text, so the baseline 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 specific verb and object: 'Ranked full-text search over provision text.' This clearly differentiates it from siblings like lookup_provision and the generic search by defining both the resource (provision text) and the behavior (ranked full-text).

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

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

It provides clear context: this is a ranked full-text search, and it gives an explicit downstream instruction to feed a hit's work+eId to lookup_provision for the complete payload. It does not enumerate exclusions or when-not conditions, but the workflow guidance is enough to route an agent correctly.

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?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description rightly doesn't repeat those. It adds meaningful context beyond the annotations: EU language versions are equally authentic under Regulation No 1/1958, the term may be entered in any language, and results are direct wording, not inferred translations. It does not describe result shape, but an output schema is present and the safety profile is covered by annotations.

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 longer than the minimal two sentences, but every paragraph justifies its presence: core meaning, legal authenticity, a worked example, and a scope exclusion. The Regulation No 1/1958 citation is useful legal context rather than filler. It could be trimmed slightly without losing information, but it is well-structured and 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 tool with 4 parameters, full schema coverage, annotations, and an output schema, the description provides the semantic context that the schema cannot: EU multilingual authenticity, bidirectional lookups, and the distinction from national transpositions. Nothing an agent needs to select this tool over siblings or invoke it correctly appears missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning to the term parameter by clarifying that German words find the English definition just as well as the reverse, which is not fully obvious from the schema alone. work, limit, and jurisdiction receive no extra prose, but their schema descriptions are already complete.

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?

Leads with a specific verb+resource: how an act words one of its defined terms in each language version held. It immediately distinguishes itself from translation and from national transposition wording, and the example ('commercial guarantee of durability' vs German/French) makes the purpose concrete. The description clearly differentiates the tool from glossary/lookup siblings by 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?

The description explicitly says when to use it: 'Use it to answer what do the German and French texts call this?' It also gives a when-not-to-use warning about Member State transposing legislation and names the alternative, find_national_implementations. This leaves no ambiguity about tool selection.

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?

Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the warning that an empty glossary reflects extraction coverage rather than the act, the two-way meaning of a null definition (borrowed vs undelimited), the three-population nature of count, and the API-key requirement for the adopts resolution. This is exactly the behavioral detail annotations cannot carry.

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?

Front-loads the core definition before the caveats, and each paragraph carries distinct information. The all-caps warnings and long caveat block are slightly heavy, but virtually every sentence earns its place by preventing a specific misreading.

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 an output schema present, the description need not explain return values, yet it still clarifies the ambiguous ones (count populations, null definitions). Combined with the annotations covering safety, nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100% for the single required 'work' param, so the schema already documents format and examples. The description's field-level talk (count, provisions, borrowed, adopts) concerns outputs, not input semantics, so it adds nothing to the input parameter. Baseline 3 applies.

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 (the act's glossary) with concrete scope modifiers: every term it defines, alphabetical, verbatim wording, plus the defining provision. It explicitly distinguishes itself from the corpus-wide alternative by emphasizing meanings 'IN THIS ACT rather than in the corpus at large', which separates it from the sibling define_term.

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?

Gives two concrete use cases (orient in an unfamiliar instrument; verify a term's meaning within this act) and the condition that selects this tool over the corpus-level alternative. It also sets an explicit when-NOT-to-report rule: 'Do not report it as this act defines no terms' when the glossary is empty.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real context: the null targetEId case is expected and not a defect, adoptions are borrowed definitions counted separately and never summed with citations, and Nexus data requires a signed-in API key with a monthly allowance. That is meaningful disclosure beyond the annotations.

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?

Dense but front-loaded: the act-level overview and grouping come first, then the scope caveat, then the sibling routing. The trailing API-key/allowance sentence is somewhat boilerplate but still earns its place for access planning.

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 an output schema present, return values need not be explained, yet the description still clarifies the ambiguous output semantics (targetEId null, adoptions vs citations) and the scope limitation. An agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is 100% and the eli and limit parameters (default 500, cap 2000) are documented in the schema itself. The description adds no syntax or format detail about eli or limit, so baseline 3 applies.

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 precise verb+resource ('every provision of every instrument ... that names the given act') and the grouping granularity (by citing instrument). It explicitly distinguishes itself from the sibling related_works and from implementation-oriented tools by stating what a row does and does not assert.

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?

Names the alternative (related_works) and the condition that selects it ('the same question at instrument level, which is public'), and implicitly routes implementation questions elsewhere by saying a row says nothing about implementation. No explicit statement of when-not-to-use beyond that, so slightly 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.