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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description is not carrying the safety burden. It still adds real behavior: the judicial corpus excludes DYCTEA and PETETE, natural mode depends on vectors and is capped at a 50-decision window, the original query is preserved, and results do not constitute legal interpretation or exhaustive coverage.

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

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

Front-loaded and information-dense, with the core scope in the first sentence. It loses points for the search_mode paragraph being repeated almost verbatim in the schema description, and for the legal-disclaimer sentences ('retrieval does not establish legal interpretation or exhaustive coverage') which pad rather than guide invocation.

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?

Covers the hard parts of a 10-parameter search tool: corpus boundaries, mode selection rules, filter semantics, and an explicit statement of the return payload (identifiers, metadata, official links, indexed excerpts), which compensates for the absent output schema. Pagination behavior for page/per_page is the notable omission.

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 only 10% across 10 parameters, so the description must compensate and does so for countries, source_groups (with its exact enum values and the omit-for-all default), search_mode, and the query_intent keys (required, alternative, phrase, excluded). However, page, per_page, court, date_from/date_to and the query string itself get no syntactic or format guidance, leaving half the surface undocumented in either place.

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 Spanish and EU court judgments') plus the facets it searches over (legal issue, terms, body, date, source). This clearly separates it from siblings such as search_administrative_documents, search_evidence, and lookup_decision, which operate on different corpora.

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 concrete selection rules: filter countries with ES, EU or both; omit source_groups to search all judicial sources; pick search_mode=strict only when textual operators or phrases are needed; and never combine query_intent with an explicit natural mode. What is missing is routing to sibling tools — it never says when to prefer answer_with_sources or lookup_decision over this search.

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