Lexiara

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

The description adds meaningful behavioral context beyond the annotations: multiple instruments can return multiple rows, each definition's scope is tied to its instrument, and the adoption resolution requires API key authentication. It also clarifies that definition text is freely available, which is valuable operational knowledge. No contradiction with the readOnly/idempotent 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?

Every sentence earns its place: purpose, usage contrast, multi-row caveat, and authentication note are all packed densely without redundancy. The most important information is front-loaded, and the length is justified by the complexity of the tool's behavior.

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 lookup tool with no output schema, the description covers what the tool returns, when to use it, how results behave across instruments, and the authentication requirement for certain data. Nothing essential for an agent to correctly select and invoke 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 input schema already provides 100% coverage, including exact phrase matching, default limit, and jurisdiction filtering. The description adds useful examples and reinforces the exact-match behavior, but it does not substantially expand on parameter semantics beyond the schema.

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

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

The description clearly identifies the tool's purpose: it returns the definition of a term of art and the provision that gives it. It actively differentiates itself from search_legislation, which returns provisions that use a phrase rather than define it. This is specific and unambiguous.

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

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

The description gives explicit guidance: use this tool before search_legislation whenever the question is what a phrase means. It names the alternative and explains the exact difference between the two, leaving no ambiguity about when to choose this tool.

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 and idempotent annotations, the description discloses important behavioral traits: the data is derived and unauthoritative, links not marked method='human' are unverified leads, and users should say so when citing. It also discloses the API-key requirement and monthly graph allowance, which are not visible in 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 compact paragraphs with no filler. The core function and critical data-quality caveat are front-loaded, followed by access constraints. Every sentence 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?

Despite having no output schema, the description explains what is returned: national provisions with method and confidence per link, and how to interpret those links. It also covers access constraints and the distinction between free legislative text and metered graph data, making it complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, and the schema already documents all four parameters, including the meaning of jurisdiction, minConfidence, and examples for eId. The description adds no additional parameter-level semantics, so it remains at the baseline for high schema coverage.

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

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

The description states a specific operation: find national provisions implementing one EU provision, including method and confidence per link. The 'DERIVED data, not published by any authority' framing clearly distinguishes this from official-source lookup tools among the sibling list, such as lookup_provision or search_legislation.

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 use clear: this tool is for finding national implementing provisions from a derived graph, and it warns that non-human links should be treated as leads to verify. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full when/when-not guidance.

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

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

The description adds substantial behavioral nuance beyond the annotations: it warns that the significance grade is Lexiara's assertion rather than the publisher's, that 'major' should be treated as a prompt to read the instrument rather than a finding, and that via-transposition links are unreviewed evidence. This is exactly the kind of hidden-behavior disclosure that helps an agent use results correctly, and there is no contradiction with the readOnly/idempotent 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 every clause earns its place: purpose, grade definitions, caveat about the grade's authority, and the reach explanation are all densely packed without filler. The core purpose is front-loaded in the first phrase 'The digest: every change...', and the remainder is necessary semantic detail.

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

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

With no output schema, the description carries the burden of explaining what the tool returns; it does so by describing each development's significance grade, reasoning, and reach, and by giving the possible values and their interpretation. For a read-only digest tool with safe annotations, this is sufficient for an agent to call it and interpret the response correctly.

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

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

The input schema already describes all three parameters (limit, since, minSignificance), so coverage is 100% and the baseline is 3. The description adds extra value by defining the meaning of 'major', 'minor', and 'housekeeping', which directly enriches understanding of minSignificance, and it also explains the reach values. It does not add new detail for limit or since, but the schema already handles those adequately.

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

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

The description clearly identifies the resource ('followed law') and the action ('every change the corpus observed... each with a significance grade'), which is specific and informative. It does not explicitly distinguish itself from siblings like recent_changes, but the focused scope on followed law with grading is enough for an agent to understand what the tool does.

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 the tool: when the agent needs a digest of changes on law the user follows, including the significance and reasoning. It explains the meaning of the significance levels and reach, providing clear context. It does not explicitly state exclusions or compare with alternative siblings, but the usage context 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description goes beyond annotations by disclosing the key behavioral nuance: absence of coverage means 'not here' rather than 'does not exist' — crucial context for interpreting results. This adds genuine value beyond the annotation layer.

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 with zero waste. The first sentence states the function, the second provides use timing and result interpretation — each clause earns its place. High-value information 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?

Given zero parameters, no output schema, and annotations covering safety, the description provides sufficient guidance for correct invocation: what the tool returns (coverage and freshness), when to call it, and how to avoid misinterpreting the absence of coverage. Slightly more detail on return format would be nice, but the tool's simplicity makes this largely complete.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is no parameter documentation burden. The description correctly focuses on output semantics instead. Baseline 4 for zero-parameter tools is appropriate here.

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 verb and resource: 'Per-source coverage and freshness.' It clearly distinguishes this tool from siblings by positioning it as the first call when unsure whether Lexiara holds the needed law, and the title reinforces the purpose. The 'not here vs does not exist' clarification adds important semantic precision.

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 this tool ('Call this first when unsure whether Lexiara holds the law you need') and how to interpret results. However, it does not name specific sibling tools or explicitly state when not to use alternatives, which prevents 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 readOnlyHint, idempotentHint, and destructiveHint, and the description adds valuable interpretive context beyond those: the draft/published editorial status, the assimilated-law caveat on GB notes, anchor provenance, and the critical distinction that anything not method='human' is evidence, not a finding. This gives the agent significant insight into the meaning and reliability of returned data.

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

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

The description is one dense sentence that opens with the overall purpose ('Everything a topic page shows') and then lists the components and their nuances in compact parentheticals. There is no filler or repetition — every clause earns its place, including the important 'evidence, not a finding' caveat.

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 gives a comprehensive inventory of the returned content categories, which is especially important because there is no output schema. It stops short of specifying exact field shapes, ordering, or error behavior, but for a one-parameter read-only fetch this is largely sufficient.

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 only parameter conceptId is already documented with a concrete example. The description does not add parameter-level detail, 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 clearly states the tool's scope as 'Everything a topic page shows' and enumerates the exact content categories: orientation paragraph with editorial status, per-jurisdiction legal-status notes, anchored provisions with provenance, transposition links, and related instruments. This specificity distinguishes it from narrower sibling tools like lookup_provision, provisions_by_concept, and related_works, even without naming them.

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

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

The description implies the tool should be used when the full topic page is needed, but provides no explicit guidance on when to prefer it over alternatives, nor any exclusions. For example, an agent is not told to use provisions_by_concept if only provisions are needed. The usage context is inferable but not 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?

Above and beyond the annotations, the description explains why the tool is read-only by construction and adds the important behavioral caveat that the caller's own key is required and the demo key is refused. This is meaningful context that the annotations alone do not provide.

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-loads the core purpose in the first sentence, then packs authentication and mutation guidance into the next two sentences without waste. Every sentence 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?

For a zero-parameter read-only list tool with strong annotations, the description covers scope, safety, mutation alternatives, and auth requirements. Nothing essential is missing for an agent to invoke this tool correctly.

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

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

The tool has zero parameters, so parameter semantics are not a burden. The description goes further by defining what the returned follow list contains (instruments, provisions, subjects, jurisdictions, verticals), which adds useful semantic meaning beyond the empty 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 uses a specific verb and resource: it lists the instruments, provisions, subjects, jurisdictions and verticals that an API key follows. It clearly distinguishes this from the sibling tools by focusing on follow state rather than topics, provisions, or review queues.

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 states when to use this tool (to view follows for your own key) and when not to use it (creating or removing a follow requires HTTP POST/DELETE to /v1/follows). It also warns about the shared demo key being refused, giving the agent actionable guidance for invocation.

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, and non-destructive hints, and the description adds meaningful behavioral context beyond them: verdicts can only be set by a human with a 'reviewer' key, no MCP tool can set one, and everything returned is unreviewed evidence. This is precisely the kind of extra context an agent needs and no annotation provides.

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 every sentence earns its place: the first front-loads the resource and ordering, the second covers filters, and the final two carry critical usage warnings about unreviewed evidence and read-only behavior. There is 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?

With no output schema present, the description carries the burden of explaining what the tool returns, and it does: item kinds, side-by-side provision texts, stored reasoning, ordering, filters, and key caveats. An agent has enough information to call this tool correctly and interpret its results responsibly.

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 schema itself already provides rich parameter detail, including the chars truncation warning and the lowConfidence tail-size warning. The description only repeats filter dimensions ('kind, vertical and jurisdiction') and adds no new parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description names a specific resource — the 'AUTO-GATED backlog' of unreviewed items — and enumerates exactly what it returns: transposition links with both provision texts, reasoning, low-confidence tags, draft topic descriptions, jurisdiction notes, and recorded findings. It also states the ordering ('newest first'), making it unmistakable from sibling research/list 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 gives clear context for when to use the tool: when human verdicts are pending and you need the unreviewed backlog, with explicit filters by kind, vertical, and jurisdiction. It includes a strong exclusion — 'cite none of it as a finding' — but it does not name alternative tools or conditions for when-not to use it.

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 and idempotentHint, and the description adds meaningful behavior: results may include UNREVIEWED model drafts marked editorialStatus='draft', and the agent should disclose this when quoting. This is valuable non-obvious context beyond the structured 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?

Three sentences, each earning its place: the first states purpose and result contents, the second warns about draft quality, and the third gives the next-step routing. The most decision-relevant information 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?

For a single-parameter, read-only list tool with no output schema, the description covers what is returned (topics, orientation, per-jurisdiction counts), flags the draft-status caveat, and tells the agent what to do next. Nothing critical is missing for correct invocation or handling of results.

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

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

The schema describes subject as a 'Subject head concept id' with an example, and the description similarly refers to 'under a subject head'. With 100% schema coverage, the description adds no substantive new parameter meaning beyond reinforcing the concept, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: listing 'curated obligation topics' under a subject head. It also names the result contents and points to get_topic as the follow-up tool, which distinguishes it from that sibling without needing to inspect 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 clearly implies use with a subject-head concept id and gives a workflow cue: feed a result's conceptId to get_topic. However, it does not explicitly state when not to use this tool or compare it against siblings like provisions_by_concept or search_legislation, so it stops just short of full routing guidance.

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

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

Well beyond the readOnly/idempotent annotations, it discloses that translations come back flagged non-authoritative with the original attached, and that the gated.citedByArticle and gated.nationalMandate counts require an API key on a signed-in account while the provision text is always free. This tells an agent which response fields may be unavailable and why. No contradiction with 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 dense paragraphs where every sentence earns its place: core payload, parameter guidance, citation-row handoff, and the free-vs-gated access model. The purpose is front-loaded in the first sentence and nothing is repeated from the annotations or schema.

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

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

With no output schema present, the description compensates well by naming the return payload (text, in-force window, status, concept tags, transposition edges, provenance, gated counts) plus the translation and auth caveats. It does not address error behavior or the exact shape of non-gated fields, a minor gap for a complex legal-data 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?

All four parameters are already documented in the schema (100% coverage), so the baseline is 3; the description adds real value by framing asAt as point-in-time law and revealing that lang triggers translation behavior with a non-authoritative flag and attached original. eId and work gain little beyond the schema, keeping this at a modest bump above baseline.

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

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

Opens with a specific verb-resource statement — 'Authoritative text of one provision' — and enumerates the enriched payload (in-force window, repealed/prospective status, concept tags, transposition edges, provenance). This clearly separates it from siblings like provision_history and search_legislation, which concern a provision's change over time and discovery rather than single-provision retrieval.

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 explicit parameter usage ('Use asAt (YYYY-MM-DD) for point-in-time law and lang for a translation') and routes one concrete case to an alternative — 'the rows themselves... come from provision_context.' It does not, however, map other relevant siblings (e.g., provision_history, search_legislation) to their selection conditions, so the when-not guidance is partial rather than systematic.

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 indicate readOnly/idempotent/non-destructive, but the description adds substantial behavioral detail: it returns citations both ways, distinguishes article-level from act-level citation results, explains the EU/national split, and discloses that derived-graph data requires an API key and consumes a monthly allowance. No contradiction with 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 every sentence contributes: the core function, the motivating use case, the citation-direction semantics, the granularity distinction, and the access constraint. It is front-loaded with the essential purpose and avoids 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 complex graph tool with no output schema, the description explains what will be returned, at what granularity, how to interpret citedBy vs citedByArticle, and what access restrictions apply. An agent has enough context to select and invoke this tool correctly.

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

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

Schema coverage is 100% and both parameters already have clear descriptions. The tool description reinforces that work is an ELI and eId is a provision identifier, but it does not add meaningful 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 states a specific resource and function: the cross-reference neighbourhood of a provision plus its amendment history. It clearly distinguishes the tool from sibling tools by detailing citedByArticle granularity and why it differs from act-level citedBy.

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 explicitly says 'Use this when a provision's relevance is not on its face' and gives a concrete example. However, it does not name alternative tools or state when not to use this tool, so it stops short of the full when/when-not guidance that would earn 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 readOnlyHint, idempotentHint, and destructiveHint, so the tool is safe to call. The description adds genuinely useful behavioral context beyond the annotations: the data is derived-graph data, requires an API key, and is subject to a monthly allowance while the legislative text is free. This helps the agent anticipate access constraints.

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. The first sentence states exactly what the tool does, and the second sentence adds the key access condition. There is no filler or repetition of the schema or annotations.

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 history tool with two well-documented parameters, the description provides enough context to select and invoke it. It covers purpose and access constraints. There is no output schema, but the description's phrase 'prior and successor versions' adequately conveys what the result will contain, though a bit more detail on the returned structure could make it 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?

The input schema already provides 100% description coverage for both parameters, including examples of eId formats and ELI URIs. The description does not add new parameter-level detail beyond the schema, but the schema itself is sufficient, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: it returns 'prior and successor versions of one provision across consolidations' and explains the purpose ('how the text got to its current form'). This clearly distinguishes it from sibling tools like lookup_provision or provision_context, which would not focus on version history.

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

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

The description clearly communicates the intended use case: retrieving the version history of a single provision. It also adds a prerequisite by noting that derived-graph data requires an API key on a signed-in account. It does not explicitly name alternatives or say when not to use the 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 establish a safe read-only, idempotent profile, so the bar is lower. The description adds genuine behavioral context beyond them: results include tagging method and confidence, the view is 'every provision' (complete listing), and it is language-neutral. It does not cover pagination or behavior for an unknown conceptId, but the annotation coverage makes that a minor gap.

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 with no waste: the first states the function and output content, the second provides concrete examples and the overarching use case. The key scoping ('cross-jurisdiction', 'one legal concept') 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?

For a three-parameter, one-required read-only listing tool, the description covers purpose, output contents, and the use case. There is no output schema, so description should hint at return values — it does mention tagging method and confidence — but it omits any indication of result volume limits or pagination, which matters for a tool that returns 'every provision'.

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 all three parameters are already documented, warranting baseline 3. The description's EuroVoc examples reinforce the conceptId format already present in the schema and add domain relevance, but it does not add meaning beyond what the schema provides for jurisdiction or minConfidence.

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 action and resource: retrieving every provision tagged with a EuroVoc concept, with tagging method and confidence. Concrete examples ('eurovoc:4585' VAT, 'eurovoc:4392' VAT rate) anchor the semantics. It distinguishes itself from siblings like lookup_provision (single provision) and search_legislation via the 'cross-jurisdiction' and 'language-neutral' framing.

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

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

The description implies the use case — lining up EU and national law on the same subject in a language-neutral way — which gives clear context for when to call it. However, it never names an alternative or states when not to use it; notably, find_national_implementations is a sibling with apparent overlap that is not disambiguated.

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, so safety is covered. The description adds valuable behavioral context by clarifying that `detectedAt` is observation time, not the legal in-force date, and by stating the feed covers added or modified provisions.

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 with no fluff. The core purpose and filters are front-loaded, and the important `detectedAt` caveat is placed as a short clarifying 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?

With no output schema, the description could say a bit more about the return shape or ordering, but for a simple filterable list tool with fully documented parameters and a key timestamp semantic disclosed, it is largely complete. The limit parameter in the schema also implies pagination support.

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. The description repeats that results are filterable by jurisdiction, concept, and date, which adds little beyond the schema. There is no extra detail about parameter formatting or interactions.

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

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

The description clearly identifies the tool as a change feed of provisions added or modified, with filtering by jurisdiction, concept, and date. It is easy to understand what the tool does, but it does not explicitly distinguish itself from siblings like follow_updates or provision_history.

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

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

The description gives clear context: this is the corpus-wide change feed for provisions, with filters for jurisdiction, concept, and date. It implies usage for answering 'what changed in the corpus' questions, but it does not state when to prefer it over related tools such as follow_updates or 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 readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by explaining what 'in' and 'out' edges mean in legal terms and clarifying the granularity of results, 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 dense, front-loaded sentences with no filler. The core semantics and the distinguishing exclusion are each covered in one sentence, making every word earn 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?

For a read-only, two-parameter tool, the description provides the complete invocation contract: what the tool does, how to interpret both directions, and when to use a sibling. The lack of output format details is minor given the tool's simplicity and annotation coverage.

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 value by translating the generic direction enum into domain-specific semantics: 'in' relates to national laws transposing a directive, while 'out' relates to implementing/amending actions, which helps agents reason about expected results.

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

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

The description states the function precisely: returning relationship edges between instruments, with both directions explicitly explained. It also distinguishes itself from a sibling tool by the instrument-level scope ('for article-level links use find_national_implementations').

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?

Explicitly tells the agent when not to use this tool ('for article-level links use find_national_implementations') and clarifies the two direction modes. This is direct routing guidance to the correct sibling without requiring schema inspection.

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 the safety profile (readOnly, idempotent, non-destructive), and the description adds behavioral context beyond those annotations: ranked results, scope over provision text, and the specific fields returned. No contradiction with annotations exists.

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, both dense with relevant information: the first defines scope and ranking, the second defines the output contract and next step. There is no filler or repetition of annotation data.

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

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

With no output schema, the description supplies the crucial return contract (work, eId, status, provenance) and the follow-up action. Combined with fully documented parameters and read-only annotations, nothing essential is missing for selecting and invoking this tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add query syntax or filtering nuances, but the schema already documents each parameter with examples, so the agent has sufficient guidance.

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 and resource: 'Ranked full-text search over provision text.' It also specifies what results carry, which differentiates it from related tools like lookup_provision and provisions_by_concept without ambiguity.

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 downstream guidance: feed a hit's work+eId to lookup_provision for the complete payload. This establishes when to use this tool as the entry point for full-text discovery, though it does not enumerate exclusions for all sibling tools.

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

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

The description explains the legal basis of equal authenticity, emphasizes that nothing here is inferred, and clarifies that the term may be entered in any language. This adds meaningful behavioral context beyond the annotations, which already mark the tool as read-only and idempotent.

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 structured into a definition, an example, a language-direction note, and a scope boundary. Every sentence contributes to correct use, and the most important distinction (not a translation, not national wording) appears early.

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 without an output schema, the description conveys what will be returned, how the lookup behaves across languages, and what it deliberately does not cover. For a lookup tool with four parameters and one required, this is complete.

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

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

Schema coverage is 100%, so the description does not need to re-document parameters. It reinforces that the term can be in any language, which matches the schema's 'any language held' note, but adds little beyond that. 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 states exactly what the tool does: it returns how an act words a defined term in each held language version. It also distinguishes the tool from a translation service and from national transposing legislation, making its unique purpose unmistakable.

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

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

It gives a concrete use case ('what do the German and French texts call this?') and an explicit negative boundary: this is not national implementation wording, so an agent is routed toward find_national_implementations when that is the actual need.

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 and idempotent hints, the description discloses important non-obvious behaviors: coverage is uneven across legal traditions, an empty glossary is a reader artifact rather than a statement about the act, NULL definitions have two distinct causes, and count represents three populations. It also clarifies which output fields require API-key authentication. This is exactly the kind of context an agent needs to avoid misreporting.

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?

Though the description is longer than average, it is front-loaded with purpose and then organized around distinct caveats that each prevent a different type of agent error. Every sentence earns its place, particularly the warnings about empty glossaries, NULL definitions, and count semantics.

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

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

With no output schema, the description compensates by detailing the return semantics: verbatim wording, provision references, `provisions`, `count` as three populations, NULL definition causes, and the `adopts` resolution requiring authentication. This is sufficient for an agent to call the tool and interpret its result 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%, with the single `work` parameter already described as 'ELI or official number of the instrument, e.g. 32011L0083.' The description does not need to restate this. The baseline of 3 applies because the schema carries the parameter documentation 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 description opens with a concrete definition: 'The act's glossary: every term it defines, alphabetical, with the publisher's own wording verbatim and the provision that defines each one.' This makes the tool's exact resource and scope clear. It also differentiates it from corpus-wide lookup by stressing 'IN THIS ACT rather than in the corpus at large.'

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 states when to use the tool: to orient in an unfamiliar instrument or to check a term's meaning within this specific act. It also warns against treating it as a corpus-wide definition source. It does not name the sibling alternative directly, but the 'rather than in the corpus at large' exclusion gives the agent clear routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, but the description adds substantial behavioral nuance: null `targetEId` is expected and not a defect, `adoptions` are counted separately from citations, and citations assert naming only, not implementation or correspondence. It also discloses API-key and quota behavior 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 every sentence earns its place: core semantics, counterintuitive null behavior, separation of adoptions from citations, sibling routing, and access requirements. The most important information 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 no output schema, the description compensates by explaining the shape and meaning of the response fields, including `targetEId` and `adoptions`. It also covers access control, quota implications, and the boundary of what the data asserts. Nothing essential is missing for an agent to invoke this tool correctly.

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

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

Schema coverage is 100%, so the schema already documents both `eli` and `limit`. The description does not add much parameter-level detail, but it does illuminate the meaning of the result fields. Baseline 3 is appropriate because 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 description states exactly what the tool returns: every provision of every instrument that names a given act, grouped by citing instrument, with `targetEId` resolved to an article where possible. It also distinguishes itself from related_works, so an agent can tell the two apart without reading 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 explicitly says to use related_works for the instrument-level version of the same question, and clarifies that the related_works view is public. It also flags that derived-graph data requires an API key and consumes a monthly allowance, giving the agent concrete selection and authorization context.

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