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 genuinely new context the annotations cannot carry: a per-decision price ($0.005 per `decision`), which matters for how aggressively an agent sets maxResults, plus the fact that includeText truncates text rather than returning it whole. It does not cover error/empty-result behavior or whether search results include total counts.

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 a one-line price note; the primary capability is front-loaded and the audience note is clearly secondary. The long mid-sentence enumeration of retrievable fields is dense but each item is informative rather than filler.

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

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

With ten optional parameters and no output schema, the description usefully enumerates what a record contains (court, dates, case numbers, legal area, procedure, inhoudsindicatie, appeal/cassation/AG relations, referenced laws, optional full text), compensating for the absent output schema. What remains unaddressed is outcome behavior — empty result sets, pagination limits beyond the 25-result cap, and cost implications of includeText across many records.

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

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

Schema description coverage is 100%, so the schema already documents every parameter in detail, including ECLI multiplicity, date formats, defaults and the includeText/maxTextChars interaction. The description adds little parameter-level meaning beyond restating the filter dimensions, although it does clarify that the keyword search targets title plus inhoudsindicatie. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource pair ("Look up Dutch court decisions (uitspraken) by ECLI") and immediately states the second mode ("search them by court, legal area, date and keywords"). The explicit Dutch/Rechtspraak jurisdiction and the ECLI identifier distinguish it from siblings like eu_law_lookup and national_law_lookup without needing to name them.

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

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

It clearly establishes the two usage modes — direct ECLI lookup versus filtered search — and enumerates the searchable dimensions, so an agent knows which parameters select which path. It stops short of naming alternatives or stating when to prefer a sibling (e.g. eu_law_lookup for EU instruments, national_law_lookup for non-Dutch jurisdictions), which is the main gap.

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