legal-lookup

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuine context beyond them: the rate is 'official' and 'daily', and the quote direction is fixed as 1 EUR = X, which prevents an agent from misreading the inversion. It does not mention weekend/holiday gaps or behavior for an unsupported currency.

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 sentence with zero waste; the scope ('official daily ECB euro reference rate'), the direction ('1 EUR = X'), and the input ('ISO 4217 code') are all 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 one-parameter tool with no output schema, the description effectively describes the return value ('1 EUR = X currency'), which is what an agent most needs. It stops short of covering error cases (unknown/unsupported currency) and whether a reference date is returned.

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 the currency parameter including the ISO 4217 constraint and examples. The description only repeats the same examples (USD, GBP, CHF) without adding format, casing, or error 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?

States a specific verb (Return), resource (official daily ECB euro reference rate), and the exact output format (1 EUR = X currency) so the agent knows precisely what it gets. It is unmistakable against siblings like eurlex_lookup, vies_validate, or legal_lookup, none of which deal with FX rates.

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

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

Usage is implied by the description — an agent can infer it is the tool to call for a EUR exchange rate — but there is no explicit when-to-use, no exclusions, and no alternative tool named. Minimum viable 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 carry the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower. The description still adds real value by disclosing the output content — two public lookup URLs from named sources plus court metadata — which matters since no output schema exists. Auth, rate limits, and invalid-ECLI behavior remain unstated.

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

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

Two sentences, zero filler: the capability and its outputs come first, the format example second. Nothing is repeated from the title or schema, and every clause 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?

For a one-parameter resolver with rich annotations and no output schema, the description covers what the tool returns and gives a format example, which is sufficient to invoke it correctly. Only edge-case behavior (invalid or non-Belgian ECLI) is left uncovered, a minor gap.

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

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

With a single parameter and 100% schema coverage, the baseline is 3, and the schema already says 'A Belgian ECLI identifier.' The description goes beyond that by supplying a concrete canonical example (ECLI:BE:CASS:2020:ARR.20200101.1), which anchors the expected format.

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

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

States a specific verb ('Resolve'), a specific resource ('a Belgian ECLI'), and the resulting artifacts ('canonical public lookup URLs (EU e-Justice + Juportal) plus court metadata'). The 'Belgian' jurisdiction qualifier cleanly distinguishes it from nl_legal_lookup / nl_rechtspraak_lookup / eurlex_lookup siblings 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?

Usage is implied by the resource: you call it when you hold a Belgian ECLI. However, there is no explicit statement of when to prefer it over the sibling lookups (eurlex_lookup, legal_lookup, nl_legal_lookup) nor what happens with non-Belgian ECLIs, so routing must be inferred.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds meaningful context beyond them: the values are 'parsed deterministically from the in-force Flemish Tax Code', which signals authoritative provenance and reliability rather than model-generated guesses.

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 tight sentences, front-loaded with the resource and its provenance. One clause ('Omit categorie to get all three') is a near-duplicate of the schema parameter description, which is the only wasted space.

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, read-only lookup with no output schema, the description conveys what is returned (rate brackets per heir category) and the authoritative source. It stops short of describing the return shape (e.g. bracket ranges vs. flat rates), but that omission is minor.

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 parameter's enum and default are fully documented in the schema. The description's 'Omit categorie to get all three' merely restates the schema's own 'Omit for all three' note, adding no syntax or format detail beyond structured data.

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 (Flemish inheritance-tax rate brackets) with an explicit legal source (VCF art. 2.7.4.1.1) and coverage scope (all three heir categories). An agent can distinguish this from sibling legal_lookup/legal_search, which are generic retrieval 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?

Gives a concrete usage instruction ('Omit categorie to get all three') and an explicit alternative to avoid ('use this instead of reciting rates from memory'). It does not, however, say when to prefer this over the sibling legal_lookup / legal_search tools that could plausibly return the same statute.

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 read-only, idempotent, non-destructive, open-world profile, so the safety bar is largely covered. The description adds one real constraint (inheritance-tax must go through the secure website), but omits return shape, count/ordering guarantees, or why 'eight' is fixed.

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

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

Two short sentences, front-loaded with the core action, and no filler. Minor cost is that the second sentence is compressed to the point of ambiguity ('inheritance-tax requires the secure website').

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 no-parameter list tool whose annotations carry the safety profile this is close, but with no output schema the description should say what a 'scan' is or what the list returns. As written, an agent has to guess what the eight entries represent.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly implies a parameterless listing call.

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 ('List ... Successiekompas scans') and adds scope ('eight Belgian'), so the agent knows this is a catalog/enumeration tool. It also differentiates itself from the sibling erfkompas_step, which handles intakes rather than listing. Slightly reduced by the opaque domain term 'scans,' which is never defined.

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 gestures at routing by naming erfkompas_step for intakes and noting inheritance-tax needs the secure website, which hints at when a different path applies. However it never states plainly when to call this tool versus alternatives, and 'intakes' and 'the secure website' are left for the agent to interpret.

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/openWorld, so the safety profile is covered. Beyond that, the description discloses genuinely new traits: answers must be explicitly user-confirmed, consent is required before transmitting choices to Successiekompas, and no case is stored. That is meaningful data-handling context that annotations do not 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 core instruction (advance one step with confirmed answers, reuse returned state) is front-loaded, and the remaining sentences each carry a distinct rule or constraint. Dense but with no filler; a small amount of sentence-parsing effort is required to separate rules from scope notes.

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

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

There is no output schema, but the description compensates by describing the loop (ask missing question, reuse returned state, show deterministic result) and by defining scope limits and privacy behavior. For a nested-object, three-parameter step tool, this is close to complete; only explicit return-shape hints and cross-tool routing are 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 67%, and the schema already documents intent's split by flow and the answers object (including the {} start case). The description reinforces that answers must be user-confirmed but adds no syntax, format, or defaulting detail for flow/intent beyond the schema. This is the expected baseline when the schema carries most of the load.

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

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

The description states a concrete verb+resource: advancing exactly one step of a Belgian (inheritance) scan, driven by user-confirmed answers. It is clearly distinct from erfkompas_flows (which presumably enumerates scans) and from the tax/lookup siblings. It stops short of naming a sibling to differentiate against, so a 4 rather than a 5.

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

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

It gives real operating conditions: ask each missing question, reuse the returned state between calls, never infer answers, and get consent before sending choices. It also excludes out-of-scope behavior (inheritance-tax calculations and AI follow-up require the secure website). No explicit alternative-tool routing is given, 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 declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds that output includes a canonical URL plus sector/document-type metadata, which is useful since no output schema exists, but it says nothing about invalid or unknown CELEX handling.

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

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

Two short sentences, with the core purpose and return payload front-loaded and the example placed last. No wasted text.

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-only lookup with full schema coverage, the definition is nearly complete: it names the input, the output URL and the metadata fields. It omits only edge-case behavior such as what happens when a CELEX number cannot be resolved.

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 both celex and language are fully documented by the schema itself. The description repeats the CELEX example and notes the returned metadata but adds no new semantics for either 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 verb (resolve) and resource (CELEX number to canonical EUR-Lex landing URL plus metadata), and the CELEX identifier clearly distinguishes it from ecli_lookup, nl_rechtspraak_lookup and other legal siblings. The GDPR example anchors the identifier format.

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 identifier type implies when this tool applies, but there is no explicit when-to-use/when-not guidance or routing against siblings like ecli_lookup (ECLI) or legal_lookup. Implied usage only.

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), so the description is free to add the behavioral facts that matter: it is a pure/offline computation and it does not perform account-activity verification. One mild tension exists with openWorldHint=true, since 'pure compute' implies a closed, deterministic lookup, though the description's clarification (structural check only) makes the intent unambiguous rather than contradictory.

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 padding. The mechanism (ISO 13616 MOD-97 + country length) is front-loaded, and the limiting condition (not account existence) follows immediately.

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, low-complexity tool this covers scope, method, and the key limitation. The remaining gap is the return shape: with no output schema present, an agent does not know whether a pass yields a bare boolean, a reason string, or parsed IBAN components (country code, check digits).

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 parameter, including the 'with or without spaces' note and the 15–42 length bounds. The description adds nothing further about input format, so the baseline 3 is correct 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?

States a specific verb (validate) and resource (an IBAN's structure), and goes further by naming the exact standard and mechanism (ISO 13616 MOD-97 check digits + country length). The resource name alone separates it from the sibling vies_validate, which handles VAT numbers rather than bank accounts.

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

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

There is no explicit 'use this when' clause, but the second sentence draws a hard boundary: it confirms well-formedness, NOT that the account exists or is active. That exclusion is the most important routing signal for a validation tool, since an agent must know not to treat a pass as proof of a live account. It stops short of naming a preferred alternative for account-existence checks.

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, openWorldHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds genuine value beyond that: the data source (public KBO register), the returned fields (official name, status, legal form, start date) and the inclusion of a source URL for traceability.

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 tight sentences: the lookup action and identifier come first, the return payload and source second. No filler, no restated title, 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?

There is no output schema, so the description correctly compensates by enumerating the return fields and naming the source register. With annotations covering safety and the schema covering the single parameter, an agent has everything needed to call this 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 specifies the 10-digit format with dots/spaces tolerated plus min/max length, so the description adds only a concrete example (0403.170.701) and the digit count—both of which the schema already carries in substance. 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?

States a specific verb (look up) and a specific resource (Belgian company by KBO/BCE enterprise number), naming the register and the identifier type. Among siblings like vies_validate, iban_validate and the legal/ecli/eurlex lookups, no other tool overlaps this domain, so the agent can route unambiguously.

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 selection context clear: this is the tool for a company identified by a KBO/BCE enterprise number, and no sibling covers that register. However, it never explicitly states when not to use it (e.g. for VAT-number validation, use vies_validate), so it stops short of explicit alternatives.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that the output is a canonical URL, which is useful, but says nothing about failure modes for unknown codes/articles or upstream dependency on Justel.

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 the action front-loaded, followed by the input contract and an example. Slightly list-heavy with the code enumeration, but nothing 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 two-parameter read-only lookup with no output schema, the description is largely sufficient: it covers what the tool does and what it returns at a high level. It omits only edge-case behavior (invalid/unknown reference handling) and whether multiple matches are possible.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes beyond the schema by enumerating a wider set of accepted codes (WBTW, WBE, Sw, Ger.W) and giving a concrete worked example (code=BW, article=4.71), clarifying the expected format of the optional article value.

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

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

States a specific verb and resource: 'Resolve a Belgian legislation reference to its canonical Justel URL'. The mention of Belgian/Justel distinguishes it from nl_legal_lookup and eurlex_lookup by jurisdiction, but it never explicitly names or contrasts a sibling 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?

The description implies usage ('Give the code ... and optionally the article number') but gives no when-to-use guidance, no exclusions, and no routing advice versus legal_search, legal_read, or nl_legal_lookup. The agent must infer that this is for canonical URL resolution while legal_read fetches content.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld. Beyond those, the description adds real behavioral context: the allowlist of official sources (with example domains) and the 30,000-character cap, which tells the agent output may be truncated and which inputs are rejected. It does not describe behavior on non-allowlisted URLs, leaving a small 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?

Three sentences, front-loaded with what/how (fetch, clean, source constraints), then the cap, then the workflow pairing. No filler; every sentence carries actionable 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?

No output schema exists, but the description conveys the return shape ('cleaned full text') and its truncation limit, plus the allowlist and the URL-sourcing workflow. For a read-only tool with annotations covering safety, this is nearly complete; only edge-case behavior (invalid/non-allowlisted URL response) is unstated.

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, but the description adds value by naming concrete allowlisted domains (ejustice.just.fgov.be, eur-lex.europa.eu) for the url parameter and restating the character cap tied to max_chars. This gives the agent more concrete grounding than the generic schema text alone.

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?

Specific verb phrase ('Fetch and clean the full text') plus a precise resource ('official Belgian or European legal document') and scope (HTML or PDF, allowlisted URL). It distinguishes itself from siblings by naming the lookups that supply the URL, so an agent can place it in the workflow without opening a 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?

The description gives a clear routing rule: use legal_lookup / eurlex_lookup to obtain the URL first. It implies the tool should not be called with arbitrary URLs via the allowlist constraint, but it never states explicit exclusions or failure behavior for non-allowlisted domains, so it stops short of a full when/when-not treatment.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds genuinely useful context beyond that—the output shape ('search URL plus code hints')—which matters because there is no output schema. However it says nothing about result count caps or the Justel source's coverage beyond the title, so it is solid 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 tightly packed sentences: what it does and when to reach for it. The return-value preview is front-loaded and nothing 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?

With no output schema, the description correctly compensates by naming the return artifacts (search URL and code hints), and annotations cover the safety profile. For a two-parameter, low-complexity search tool this is nearly complete, though it could note result limits or language expectations for the keyword.

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 schema already documents 'keyword' (Dutch/French, length bounds) and 'limit' (default 5, max 10). The description adds no syntax or format 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 specific verb (keyword-search) and resource (Belgian legislation on Justel) and even previews the return value (search URL + code hints). It differentiates by scenario ('don't know the exact reference') but never names the sibling it is contrasted with, so differentiation is 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?

'Use when you don't know the exact reference' gives a clear triggering condition and implicitly excludes the case where the exact reference is known (i.e., use legal_lookup/legal_read instead). It does not name those alternatives explicitly, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: it discloses the resolution target (wetten.overheid.nl URL) and enumerates the accepted code vocabulary, which the agent cannot derive from 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 short sentences, front-loaded with the purpose, then the input contract, then a concrete example. No filler; 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?

For a two-parameter, read-only lookup with no output schema, the description supplies everything needed: the purpose, both inputs, their optionality, and the return value (the statute URL). 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%, so baseline is 3. The description exceeds that by enumerating the valid code set (BW4, Successiewet, Wet IB 2001, Wet OB 1968, BW6, Awb, Sr, Rv) and showing a concrete article format (4:63), effectively documenting accepted values the schema only samples.

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

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

States a specific verb (resolve), a specific resource (Dutch statute reference), and the concrete output (wetten.overheid.nl URL), plus the accepted code namespace. This clearly distinguishes it from siblings like ecli_lookup, eurlex_lookup, and nl_rechtspraak_lookup.

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 an example invocation and notes the article is optional, which implies usage, but it never states when to prefer this tool over alternatives such as legal_lookup or eurlex_lookup, nor any exclusion conditions. Usage is inferable but not guided.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context by naming the three canonical URL destinations it returns, which tells the agent what a call yields even though no output schema 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 short sentences, front-loaded with the verb and resource, then the concrete return targets and an example. No filler, no repetition.

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 one parameter and no output schema, the description adequately covers inputs (via schema) and return targets. It does not mention malformed-ECLI handling or whether lookup is always successful, but for a simple read-only resolver the coverage is close to 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 sole parameter's description already carries the ECLI example and format. The description repeats the same example without adding syntax, validation, or normalization details, so it meets the baseline but adds nothing 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?

States a specific verb (Resolve) and resource (Dutch ECLI) and enumerates the outputs (Rechtspraak.nl, Open Data API, EU e-Justice). However, it does not distinguish itself from similarly named siblings such as ecli_lookup and nl_legal_lookup, which an agent could easily mistake for 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?

There is no statement of when to use this tool versus alternatives, and with near-duplicate siblings (ecli_lookup, nl_legal_lookup, legal_lookup) present, that omission is costly. The only guidance is an input example, which is not usage guidance.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, open-world), so the bar is lower, yet the description still adds value by disclosing the return shape: validity plus trade name and address 'where the member state exposes it'. That caveat about partial data coverage is genuinely useful and not derivable from the schema.

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

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

Two compact sentences plus an example: purpose front-loaded, return behavior second, no filler. The example duplicates the schema's own example, a minor redundancy that keeps it out of the top band.

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 one fully documented parameter and no output schema, the description carries the return-value explanation and the important caveat that name/address are not always returned. It omits error behavior (malformed vs. unregistered number) and any rate-limit or availability note for this external service, which would have made it 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% and the single parameter is fully documented, so the baseline applies. The description repeats the same example (BE0403170701) already present in the schema and adds no new syntax or format 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?

States a specific verb (validate) and resource (EU VAT number) against a named authority (the official EU VIES service), which an agent can distinguish from sibling validation tools like iban_validate or kbo_lookup. No sibling is named explicitly, so it falls just short of the top score.

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

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

The context of use is clearly implied by 'validate an EU VAT number', but the description never states when to prefer this over iban_validate/kbo_lookup or what preconditions apply (e.g. country prefix required, VIES availability). Usage is inferable, not prescribed.

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