AI Rechtshulp

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context by enumerating the data categories returned (subscription state, budgets, renewal date, permissions, statement count), which tells the agent what information it can expect to obtain. It stops short of noting auth/linking requirements or a return format.

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 that front-loads the purpose and then lists the returned fields without filler. It is a dense enumeration rather than elegant prose, 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?

With no output schema, the description carries the burden of describing what comes back, and it does so by naming each returned data category. Safety behavior is already covered by annotations. The only real gap is the absence of any usage/routing context against the many sibling tools.

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 no parameters, so the baseline of 4 applies. The description correctly implies a parameterless lookup of the single linked account rather than something requiring an identifier.

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

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

The description names the resource (the linked AI Rechtshulp account) and enumerates exactly what the tool surfaces: subscription, shared source budget, question budget, renewal date, access-rights explanation, and saved-statement count. That is a clear retrieval purpose, though it never distinguishes itself from siblings such as check_source or list_saved, which also surface account-adjacent data.

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

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

There is no indication of when to call this tool, what precondition it assumes (e.g. that an account is already linked), or which sibling to prefer for related information. The agent is left to infer usage entirely from the purpose statement.

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:false and destructiveHint:false, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the normalization behavior (whitespace and capitalization) and what is returned (source passages and quotation context for a claim).

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 dense sentences, front-loaded with the core check and closing with the important limitation. Every clause earns its place; it is only marginally longer than strictly necessary.

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

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

With no output schema and no annotation gaps left, the description does most of the work: it says what is checked, how comparison is normalized, and what comes back. It leaves the exact response shape and the role of the optional quotation underspecified, a minor gap for a three-parameter read tool.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining ecli, claim and quotation. It names the ECLI concept and the check against a stored quotation, and 'citaatcontext bij een bewering' hints at how claim and quotation combine, but it never cleanly maps the three named parameters (notably the optional quotation) to their roles.

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

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

The description states a precise verb+resource: it verifies whether an ECLI exists in the collection and whether a quotation appears in the stored ruling, including whitespace/case normalization. This scope is clearly distinct from siblings like save_source or search, which an agent can infer without opening any schema.

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

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

It gives an explicit negative boundary — 'Beoordeelt niet of de rechter de bewering ondersteunt; een citaat kan ook een partijstelling zijn' — which tells the agent what conclusion this tool does NOT license. It stops short of naming an alternative tool for the cases it declines, so it is clear context without full routing.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=true; the description reinforces the idempotency claim by revealing that an existing name is reused, and adds a non-obvious behavioral prerequisite (paid account required). That is real value beyond the structured metadata, though it says nothing about permissions or side effects on conflicting 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?

A single compact sentence with a semicolon; the creation act is front-loaded and the two additional facts (reuse, paid account) are tight. No padding, but also no formatting to separate the prerequisite from the 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 non-destructive write tool with no output schema and zero param documentation, the description covers the idempotency behavior and the account prerequisite, which are the most agent-relevant facts. It still leaves the parameters and the effect on the created resource under-specified.

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

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

Schema description coverage is 0% for two parameters. The description only touches on 'name' indirectly via the reuse note and says nothing about the 'description' parameter, leaving its meaning and constraints undocumented in both schema and prose.

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 ('Maakt ... een dossier op'), clearly distinguishing it from sibling read tools like read_dossier and list_dossiers. It lacks any explicit routing to alternatives, but the purpose itself is 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 qualifier 'op uitdrukkelijk verzoek' (only on explicit request) implies a usage context, and 'Betaald account nodig' states a prerequisite. However, there is no when-to-use/when-not guidance relative to siblings such as list_dossiers or save_research.

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

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

With annotations already covering read-only, idempotent and closed-world behaviour, the description adds substantial non-redundant context: account linking requirement, per-ECLI monthly credit cost, pagination semantics (next_offset null on the last page), SHA-256 version verification on subsequent pages, and the caveat that absence from the collection does not mean the ruling doesn't exist.

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

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

Dense and essentially waste-free, with every clause adding operational information. It is slightly back-loaded: the actual purpose (returns a ruling by ECLI) arrives after the billing/account sentence, which is arguably not the first thing an agent needs.

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 paginated read with no output schema, the description covers call prerequisites, cost, paging, and version verification, and even references output fields (next_offset, source_sha256). The main residual gap is how a not-found ECLI is surfaced (error vs empty result), though the closing caveat gestures at it.

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

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

Schema description coverage is 0%, so the description has to carry the load, and it largely does: id is tied to ECLI retrieval, offset is framed as page continuation, and expected_sha256 is explained as verifying the source version returned as source_sha256 on follow-up pages. It stops short of describing the regex format or that offset defaults to 0.

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: it returns a court ruling from the collection based on an ECLI, delivered as consecutive text pages. That distinguishes it from scan_contract, make_memo and the dossier tools. It does not, however, explicitly name sibling 'search' as the way to find an ECLI when you don't already have one, so the boundary is only 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?

It gives useful usage context — account linking required outside the fixed demo, one source credit per unique ECLI per month — but never states when to choose fetch over search, or what prerequisite (possessing an ECLI) must hold. Usage is implied by the ECLI-based contract rather than spelled out.

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?

Adds context well beyond the annotations: at_date semantics, the strong guarantee that missing historical text is never silently replaced by today's text, today as the default reference date, that continuation pages need expected_sha256 from the first page, and that account linking is required. The only real gap is the return shape/error behavior, which annotations do not cover either.

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?

Six short sentences, front-loaded with purpose, then date semantics, then pagination, then the auth requirement — nothing is padded. 'Controleer beschikbare versie en bron' is the one line that is too terse to be actionable.

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, closed-world lookup with no output schema, the description covers the things an agent would otherwise get wrong: date fallback, no silent text substitution, pagination via expected_sha256, and the account prerequisite. Return contents are handled by the 'Controleer beschikbare versie en bron' instruction.

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 0% schema description coverage the description has to carry the load and does for three of five parameters: at_date (meaning plus default), expected_sha256 (must come from the first page), and bwb_id/article (self-evident from purpose). offset is never mentioned and the ID/article formats go unexplained, so it stops short of full 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?

States a specific verb and resource ('Leest een opgeslagen artikel') and the two keys that address it (BWB-ID en artikelnummer), which cleanly separates it from search-law siblings. It never names those siblings explicitly, so the differentiation is implicit rather than stated.

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 required identifiers: you call this when you already have a BWB-ID and article number rather than a query. 'Controleer beschikbare versie en bron' hints at a verification step but is vague, and no alternative (search_law, check_source, fetch) is named with a condition for choosing it instead.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new context: the operation requires a paid account and a distinct dossier permission. It does not mention pagination behaviour despite an offset parameter, so it is not a 5.

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

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

Two short sentences with no filler, and the core action is front-loaded ahead of the permission constraint. It is arguably too terse for the information an agent needs, 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?

With no output schema and no annotation gaps, the description only needs to cover prerequisites and paging. Prerequisites are covered, but the offset parameter and any result-size/ordering behaviour are left unexplained, leaving a noticeable gap for a paged list 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?

There is one parameter (offset) with 0% schema description coverage, and the description says nothing about pagination, limits, ordering, or the maximum of 100000. The baseline for documented params does not apply here because the single parameter is entirely undocumented.

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

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

The description gives a clear verb and resource (showing your own dossiers), which an agent can distinguish from siblings like read_dossier or create_dossier by the plural 'eigen dossiers'. It does not explicitly name or contrast those siblings, so it falls short of a 5.

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

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

It states prerequisites (paid account plus separate dossier permission) and a vague trigger ('op verzoek'), which is implied usage context. There is no explicit when-to-use vs alternatives guidance, e.g. when to use this instead of read_dossier or list_saved.

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, openWorldHint=false, and destructiveHint=false, so safety is covered structurally. The description adds the useful constraint that results are limited to the linked account, but says nothing about result volume or pagination behavior despite the offset parameter.

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

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

A single compact sentence with no filler, and the resource being returned is front-loaded. It is efficient, though the brevity comes partly from omitting information an agent would need.

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

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

For a simple read-only list tool whose annotations cover the safety profile, the definition is minimally adequate: it states scope and source account. However, with no output schema and an undocumented offset parameter, the agent gets no picture of result shape or paging, leaving a real 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?

There is one parameter (offset) with 0% schema description coverage, and the description explains nothing about it — no mention of paging, result limits, or how offset interacts with the default. The description fails to compensate for the schema gap.

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

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

The description names a specific verb (returns) and resource (saved uitspraken and notities of the linked account), with the adverb 'uitsluitend' clarifying the scope. It is clear what the tool yields, but it does not explicitly differentiate itself from sibling list tools such as list_dossiers.

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

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

The phrase 'voor een verzoek om het eigen bewaarde onderzoek te bekijken' implies the usage context (viewing one's own saved research) but never states when to prefer this over list_dossiers or read_dossier, nor any exclusions. Usage is inferred rather than stated.

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

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

Annotations declare the safety profile (write but non-destructive, idempotent, closed-world), and the description adds meaningful context beyond them: a quota cost, a required user-consent step, and request_id reuse on transport retries. It also flags that no human reviews the output. It does not say what happens to the resulting memo (saved, retrievable), leaving that 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?

Six short sentences, no filler, with the access and cost preconditions front-loaded before the 'ask permission' instruction and the outcome. The choppiness is stylistic rather than wasteful.

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

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

No output schema exists, so the description is right to characterize the return (draft memo with source references), and it covers quota, consent, and idempotency. But for a four-required-parameter mutation tool with zero schema coverage, leaving the content fields undefined is a real completeness gap.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains request_id (unique, reused on retry) and implies confirmed via the permission step, but feiten and rechtsvraag — the two substantive content fields with length limits — are never described beyond a vague reference to 'the provided text'. Two of four parameters remain undocumented.

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

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

The final sentence states a concrete verb and resource: creates a draft memo with source references. That distinguishes it from siblings like scan_contract or save_source, which operate on other artifacts. It stops short of naming that distinction explicitly, but the purpose is 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?

It gives real preconditions (linked-account document access, one question consumed from the shared bundle, ask permission before processing), which is more than a bare 'when to use'. However, it never names an alternative or exclusion, so an agent must infer routing from prerequisites alone.

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, closed-world), so the bar is lower; the description still adds real value with the paid-account auth requirement and the precise scope (only explicitly saved research notes, not files or conversations). It stops short of describing pagination or result format.

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

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

One compact sentence carrying scope, exclusions and prerequisite, with the core action front-loaded. No padding, though the language mismatch with the English tool name slightly hurts scannability.

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

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

For a simple read-only tool with no output schema, the description covers scope and auth but omits the meaning of the offset parameter and any sense of return volume or pagination, which are the main open questions an agent would have.

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

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

Schema description coverage is 0%, so both parameters (dossier_id, offset) are undocumented. The description only vaguely implies dossier scoping via 'je eigen dossier' and says nothing about what offset paginates or how it behaves, leaving the agent to guess.

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

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

States a specific verb+resource combination ('leest ... bewaarde onderzoeksnotities in je eigen dossier') and scopes it against non-dossier content ('geen bestanden of overige gesprekken'), which helps separate it from siblings like fetch and search. It is clear what is read, though it doesn't name a sibling tool directly.

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 implicit when-not guidance by excluding files and other conversations, and states a prerequisite ('Betaald account nodig'). However it never names an alternative tool (e.g. list_saved, search) or the condition that should route the agent there, so usage is only implied.

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

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, non-destructive). The description adds useful context beyond annotations: the artifact is visible on the website and via other linked clients (a shared/persistent side effect), and a paid account is required. However, it doesn't mention the confirmed=true gate or the request_id, which are unusual invocation requirements.

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 tight sentence that front-loads the action and the stored content. No waste, though the account/paywall clause is tacked on at the end.

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 mutation tool with no output schema and 0% schema coverage on 6 parameters, the description leaves important invocation details (confirmed gate, request_id, how dossier_id is obtained) unexplained. It covers purpose and persistence well but is incomplete on how to actually call it correctly.

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

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

Schema description coverage is 0% across 6 parameters, yet the description only mentions the note and ECLI references conceptually. It does not explain the required 'confirmed' boolean (const true) or the 'request_id' UUID, which are non-obvious invocation parameters that an agent could easily get wrong.

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

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

States a specific verb+resource ('Bewaart ... onderzoeksnotitie en ECLI-verwijzingen in je eigen dossier') and distinguishes from sibling save_source by being about the research note rather than a source. Clear, though the sibling distinction is implicit rather than named.

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

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

The phrase 'op uitdrukkelijk verzoek' implies this is user-requested only, giving some when-to-use signal, but it doesn't name alternatives like save_source or list_saved, nor explain conditions that select this tool over them.

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

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

Annotations already state readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: repetition does not overwrite an existing note, and the tool does not handle case documents, sending or payment.

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 core save action, then idempotency behavior, then exclusions. No redundant or filler 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 low-complexity save operation with rich annotations and no output schema, the description covers the key behavior, idempotency nuance and scope exclusions. The ecli format and identification are left to the schema, which is acceptable but leaves 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?

Schema description coverage is 0%, so the description must compensate, but it only mentions that the note is optional. It does not explain that ecli identifies the existing ruling or add meaning beyond the schema pattern already supplied for the ecli parameter.

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

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

The description states a clear verb (bewaart) and resource (een bestaande uitspraak) with optional note and target account. It distinguishes scope by excluding dossierstukken, verzending and betaling, but does not explicitly differentiate from siblings such as save_research or list_saved.

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 indicates the action is performed 'op verzoek van de gebruiker' and excludes unrelated operations, giving implied usage context. However, it does not name an alternative tool or specify when to choose this over save_research or list_saved.

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

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

Annotations only cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds substantial non-annotation behavior: a quota cost per invocation, an access prerequisite, a mandatory user-consent step before AI processing, and no human legal review of the output.

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?

Prerequisites and constraints are front-loaded before the behavioral statement, and every sentence carries distinct information. It is dense but appropriately sized for a tool with four required parameters and no schema documentation.

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 and zero schema description coverage, the description does well: it covers preconditions, cost, consent, idempotency, and the nature of the deliverable. Minor residual gaps are the absence of sibling routing guidance and any hint of size limits (tekst maxLength 60000).

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

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

Schema description coverage is 0%, so the description must carry the load. It explains request_id semantics (unique, reused on transport retry), implies the meaning of confirmed via the consent requirement, and clarifies that perspectief selects the viewpoint for clause analysis. The enum values themselves are not spelled out but are self-explanatory.

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 action and resource: "Onderzoekt clausules vanuit het gekozen perspectief" and scopes the output ("levert aandachtspunten, geen jurisprudentieonderzoek"). This differentiates it from research-oriented siblings like search or check_source, though it never names an alternative tool explicitly.

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

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

It gives concrete preconditions: document access in the linked account is required, it consumes one question from the shared bundle, consent must be obtained first, and request_id must be unique and reused on transport retries. What is missing is routing: no indication of when to prefer a sibling tool instead.

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 and destructiveHint=false, so safety is covered; the description adds genuine context beyond that: the auth/budget gating, the refusal behaviour on personal data, and the return shape ('source passages, not advice'). With no output schema, the 'bronpassages, geen advies' line usefully sets expectations.

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

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

It is compact, but the ordering is off: the opening sentence about a fixed Deliveroo demo is the least informative and slightly confusing, while the actual purpose arrives only in the third sentence. The sentences themselves are not padded.

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 2-parameter, no-output-schema tool the description covers scope, prerequisites, exclusions, and return type, which is decent. But with both parameters undocumented in the schema and no param detail in the prose, an agent cannot tell what limit does or how the query is interpreted.

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

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

Schema description coverage is 0% for both parameters, so the description must carry the burden. It only constrains query content ('no personal data'), and says nothing about the meaning, format, length, or effect of 'query' or 'limit'.

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

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

The description gives a specific verb ('Zoekt') and a precisely scoped resource: published Dutch and Dutch-language EU rulings for a legal question. It implicitly separates itself from siblings like fetch and check_source by framing the task as case-law retrieval, though no sibling is named explicitly.

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

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

It states the precondition for use (account linking plus a source budget outside the fixed Deliveroo demo) and a clear exclusion (queries containing identifiable personal data are refused). It does not name an alternative sibling for cases where the account/budget requirement is not met, which keeps it 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 cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: account linking and source budget are required, semantic search may degrade to keyword search and that limitation is surfaced, results are original passages with version dates, and the results are not evidence of legal applicability to a case.

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?

Five short front-loaded sentences, each carrying distinct information (scope/mechanism, fallback, prerequisites, return content and caveat, follow-up tool). No restatement of the title and no padding.

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

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

For a 2-parameter read tool with no output schema, the description covers scope, prerequisites, degraded-mode behavior, what is returned (passages plus version dates), the key caveat about legal applicability, and where to go for historical text. Nothing needed to call 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 description coverage is 0%, so the description must compensate and it only partly does: 'Zoek zonder persoonsgegevens' constrains the query content, but nothing explains the `limit` parameter or its max of 5, nor the query length bounds. Adequate but with a clear gap.

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

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

States a specific verb and resource (search stored Dutch national legislation) plus the mechanism used (existing hybrid searcher). It distinguishes itself from the generic `search` sibling and from `fetch_law`/`at_date`, which the description says are the way to read historical text.

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

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

Gives clear operating context: use the hybrid semantic path, falling back to keyword search when semantic is unavailable, and the fallback limitation is reported. It routes historical-text reading to fetch_law and at_date, and warns not to put personal data in the query. It does not explicitly contrast itself with the sibling `search` tool, so a 4 rather than 5.

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

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

Beyond the annotations, the description discloses meaningful behavioural context: the direction of the citation relation, that absences in the collection do not prove non-existence, that account linking is required outside the demo, and that subsequent pages require expected_sha256. These details add real operational value and are consistent with the read-only, non-destructive, 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 front-loaded with the core action and then adds caveats and operational notes in short sentences. It is compact and largely waste-free, though the caveats are packed into a dense paragraph rather than separated for scanability.

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 does explain the return content at a high level: explicit ECLI references and Dutch case numbers with original context. It also covers important caveats and auth/pagination hints, but it is incomplete on limit/offset behaviour and does not explain how an agent obtains or uses expected_sha256 beyond the requirement that it is needed.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only explains that expected_sha256 is needed for subsequent pages and frames ecli indirectly. It says nothing about what limit and offset control, how pagination should be used, or what the hash represents, leaving most of the four parameters undocumented.

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

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

The description states a specific action and resource: it returns explicit ECLI references and recognised Dutch case numbers from a stored judgment, including original context. That is clear enough for an agent to know what it does, though it does not explicitly differentiate itself from siblings such as check_source or fetch.

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

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

The phrase 'uit een opgeslagen uitspraak' implies the tool is used against saved judgments, and the description gives useful scope limits ('geen volledige citatiegrafiek', 'geen oordeel over gevolgd, verworpen of achterhaald recht'). However, it never names alternatives or explicitly says when to choose this tool over check_source, fetch, or search.

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

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

With annotations present (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the bar is lower, and the description still adds substantial context: quota consumption from a shared bundle, a mandatory consent step, an idempotency/retry contract for request_id, and a disclaimer that no human legal judgment is produced. These are operational traits the annotations do not express. It does not describe output shape, but that is minor here.

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?

Five short sentences, each carrying distinct operational information, with the blocking prerequisites (access, quota, consent) front-loaded before the analytical purpose. No filler or repetition. The trailing disclaimer sentence is slightly detached from the flow but still 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 need not describe return values, and it does cover the non-obvious constraints (access, quota, consent, idempotency, non-human judgment). What it omits is the meaning of three required inputs and any sense of output form, which is a meaningful gap for a five-parameter tool with zero schema documentation.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the semantic load and it does not. It explains request_id's uniqueness/retry semantics and implies 'de aangeleverde tekst' maps to document, but rol, standpunt, and confirmed are never explained; confirmed can only be guessed at from the adjacent consent sentence.

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 purpose: it investigates counterarguments, evidentiary problems, and relevant sources for a supplied position. That is a specific analytical verb-resource, well beyond the vague name 'stress_test'. However, it never contrasts itself with plausible siblings such as check_source or make_memo, so an agent must infer the routing itself.

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 invocation preconditions: document access is required, it consumes one question from the shared bundle, and consent must be obtained first. What it lacks is any explicit when-to-use-this-instead-of-a-sibling guidance or when-not-to-use condition, which matters given thirteen siblings with overlapping legal-research functions.

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