Jurisprudencia.io

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the default retrieval mode, the preservation of require_semantic when supplied, and an explicit scope disclaimer that it does not provide legal advice or determine case outcomes. It still says little about the shape or volume of what comes back.

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 text is dense and front-loaded: purpose first, then mode defaults, then the administrative alternative, then the scope disclaimer. Every sentence carries information, though the mode/flag sentence is syntactically crowded and could be split for faster scanning.

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 7-parameter retrieval tool with no output schema, the description covers routing and mode semantics but omits the meaning of countries, source_groups, max_citations and response_language, and gives no sense of the citation/provenance structure returned. An agent could invoke it, but not confidently tune 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% across 7 parameters, so the description must carry the load. It explains allowed_modes in useful depth (default behavior plus the 'judicial_text' value) and mentions require_semantic, but question, countries, max_citations, source_groups, and response_language receive no explanation at all, leaving the majority of parameters undocumented in both places.

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

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

The description opens with a specific verb and resource ('Retrieve and organize verifiable judicial passages with sources and version provenance'), which is far more informative than the tool name. It distinguishes the tool from the administrative siblings (DGT/TEA) but never explains how it differs from close siblings like search_evidence or search_decisions, leaving an agent to guess between 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?

Strong conditional guidance: it states that omitting allowed_modes defaults to hybrid thematic search, that allowed_modes=['judicial_text'] forces textual retrieval, and that administrative doctrine belongs to the administrative tools. It lacks an explicit exclusion against the nearest judicial siblings (search_evidence, search_decisions), so the routing picture is incomplete.

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 the safety and determinism profile is fully covered. The description adds the non-trivial fact that only 'visible' bodies in the 'available corpus' are returned, which explains why the output may be partial — useful context beyond the annotations, though nothing about ordering or result size.

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 front-loaded sentence with no filler. The scoping qualifier ('within the available corpus') is placed where it is most useful rather than buried.

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-argument, no-output-schema tool the description is minimally sufficient, but with no output schema it should say more about the return shape — what a 'count' is measured over and whether the returned labels are the values accepted by the search tools. That linkage is the main missing piece for correct downstream use.

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 zero parameters there is no parameter meaning to convey, so the baseline of 4 applies. The description neither adds nor omits anything relevant on this dimension.

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

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

The description states a specific verb and resource — listing Spanish judicial bodies together with their counts. It is unambiguous and clearly distinct from sibling tools such as search_decisions or lookup_decision, though it does not explicitly name a contrast with any sibling.

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 when-to-use or when-not-to-use guidance, and no mention of how this enumeration relates to the search/lookup siblings that take court filters. The phrase 'within the available corpus' hints at a discovery role, but the agent must infer that it is meant as a facet-exploration step.

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 read-only, idempotent, closed-world, non-destructive behavior. The description adds a useful caveat that availability does not imply complete coverage, but it does not explain status values, ordering, or the effect of include_planned.

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 a single front-loaded sentence with no filler. The caveat about availability is compact and directly relevant.

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 listing tool with one optional parameter and no output schema, the description is adequate but incomplete. It omits the include_planned parameter semantics and gives no indication of result shape or source status values.

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 optional parameter, include_planned, with 0% schema description coverage, but the description does not mention or clarify it. An agent cannot infer what 'planned' sources are or how toggling the default changes results.

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

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

The description uses a clear verb-resource pair: 'List configured legal sources' and adds that availability status is returned. It is distinguishable from siblings like list_courts and search_decisions, though it does not explicitly say how it relates to 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?

There is no explicit guidance on when to use this tool versus alternatives such as list_courts or answer_with_sources. Usage is only implied by the object being listed.

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 context beyond that: the lookup may return only a criterion or excerpt rather than the full document, and a miss is not evidence of absence from the official source. It does not discuss auth or limits, but none seem relevant for a read-only local lookup.

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?

Four short sentences, front-loaded with the verb and identifier formats, followed by the required follow-up workflow and the ambiguity/not-found caveats. Every sentence adds a distinct constraint; nothing is redundant.

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 required parameter, no output schema and no nested objects, the description covers what an agent needs: what it returns (criterion or excerpt), the mandatory read step, and how to interpret a miss. Only the exact identifier string format remains underspecified, which is a minor gap for a tool this simple.

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 0% and the single 'identifier' parameter has no schema description, so the description carries the burden. It does add meaning by naming the two accepted identifier schemes (DGT:consultation-number and DYCTEA:registry), but gives no concrete example, prefix syntax, or validation rules, leaving the agent to guess the exact string 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 and resource ('Retrieve a specific tax administrative document') and narrows it to an exact-reference lookup by DGT:consultation-number or DYCTEA:registry. This cleanly separates it from the sibling search_administrative_documents (broad search) and read_administrative_document (full reading), so an agent can pick it without opening schemas.

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

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

Explicitly says 'Use this first for an exact reference', mandates a follow-up read_administrative_document call even when the lookup returns content, and warns that ambiguous references need refinement and that not-found does not prove absence. Both the when-to-use and the when-not-to-conclude conditions are 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 already declare readOnly, idempotent, non-destructive, and a closed-world hint, so safety is covered. The description adds one genuinely non-obvious behavioral fact, that a not-found result does not prove absence from the official source, which is valuable for negative-result handling. It says nothing about what a hit returns (full text vs. metadata) or about ambiguity handling when several identifiers are supplied.

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 with the primary action front-loaded and no redundant restatement of the schema or title. Each sentence adds a distinct rule (identifier forms, ECLI caution, court codes, negative-result caveat, administrative routing).

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 three undocumented optional parameters and no output schema, the definition should carry more of the load. The negative-result caveat and sibling routing help, but the lack of any statement about which parameter accepts which identifier form, or what a successful result contains, leaves real ambiguity.

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 for id, court, and identifier, and it partially does: court is pinned to catalog codes TC/TS or exact catalog names. However, it lists many accepted identifier forms (ECLI, ROJ, case number, decision) without saying which of the two string parameters, id or identifier, takes which form, and it never says whether parameters must be combined or are independently optional.

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 first sentence gives a specific verb (Retrieve) and resource (a judgment) plus the full set of accepted identifier types (stable id, ECLI, ROJ, decision or case number). It also routes the agent away from lookup_administrative_document for DGT/DYCTEA references, so it is distinguishable from siblings without opening schemas.

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

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

It names two explicit dependencies: use list_courts for court codes (TC or TS) and use lookup_administrative_document for administrative references. It also warns never to invent an ECLI from another reference. The gap is that the relationship to the closer siblings read_decision and search_decisions is never stated, so the agent must infer when lookup beats 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?

Annotations already declare readOnly, idempotent and non-destructive behavior, so safety is covered; the description adds genuinely new context about how the returned text must be treated (facts and questions do not establish the answer, preserve classification and conditions, do not presume binding effect, validity or applicability). This is meaningful interpretive behavior disclosure for a legal-source reader, though it says nothing about version resolution behavior or what happens when a section is unavailable.

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 passage is dense but front-loaded, with the core read action first and constraints after, and no redundant restatement of the title. A few phrases are compressed to the point of ambiguity ("Facts and questions do not establish the answer", "Check available_sections") and would benefit from one clarifying clause each.

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 7-parameter reader with no output schema and zero schema description coverage, the description covers the primary selection and paging mechanics adequately but leaves the q search parameter and start_char unexplained, and it references an available_sections field that the agent has no schema to interpret. It is workable but not fully self-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 0% across 7 parameters, so the description must carry the load. It explains section (three of ten enum values), limit (1-5) and pagination via offset, plus the version-pinned notion behind version_id, but leaves q, start_char, id and the remaining enum values (ruling, antecedents, tax_facts, normative_references, etc.) entirely unexplained.

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 concrete verb and resource ("Read version-pinned literal administrative passages") and specifies which section kinds can be requested (tax_answer, administrative_criterion, legal_grounds), which separates it from the pure lookup/search siblings. It stops short of explicitly contrasting itself with lookup_administrative_document or search_administrative_documents, so the differentiation is inferable 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?

It gives operative guidance for choosing a section value and states the limit constraint (1 to 5 paragraphs) with an instruction to paginate for more, which are real usage rules. However, it never says when to prefer this tool over the sibling lookup/search tools, and the instruction "Check available_sections" points at a field that is not documented anywhere in the definition.

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 readOnly/idempotent/non-destructive, and the description adds genuine behavioral context beyond them: truncation semantics via prefix_omitted, continuation via returned offsets, and the presence of available_sections and warnings in the response. It also warns that summaries are not full judgments, which prevents a misuse of the source_summary section.

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 core read action front-loaded, followed by parameter hints and then response-field guidance. No filler, though the compressed phrasing ('Check available_sections and warnings') reads as terse shorthand an agent must decode.

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 7-parameter tool with no output schema, the description usefully names key return fields and continuation mechanics, which is more than most. Still missing: how id and version_id relate, what limit controls, and any guidance on choosing a section — gaps an agent must guess at.

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 7 parameters, so the description must compensate and does so only partially: it explains q as a topic anchor, offsets as continuation handles, and references version and section concepts. It says nothing about limit (default 3, max 5), id vs version_id relationship, or the meaning of the five section enum values.

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: reading 'literal paragraphs' from a 'specific judgment version and section'. This differentiates it from metadata-style siblings like lookup_decision or search_decisions by emphasizing literal text 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?

Implies usage through 'Optional q anchors the initial read near the topic' and 'continue with the returned offsets', which tells the agent how to page through content. However, it never states prerequisites such as needing an id from search_decisions/lookup_decision, nor when to prefer read_administrative_document or answer_with_sources 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, openWorldHint=false and destructiveHint=false, so the low bar is met by structure alone. The description adds genuinely useful behavior context beyond that: 'Coverage is progressive' warns results may be incomplete/incremental, and it mandates a verification step via read_administrative_document. It does not discuss result ordering or pagination depth, which keeps it from 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?

Four tight sentences, front-loaded with purpose, then filter semantics, then alternatives, then verification. No filler or restatement of the title; each clause 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?

There is no output schema, and the description compensates by telling the agent to verify results with read_administrative_document and warning that coverage is progressive. Given 5 parameters with weak schema documentation, it could say more about result ordering and page/per_page behavior, but the critical decision inputs are present.

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 only 20% (only search_mode is documented in the schema), so the description must carry the load. It does explain the least obvious parameter well — the meaning of each source_groups enum value and the null/omit case — but query, page and per_page receive no semantic elaboration, and pagination limits go unmentioned.

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 tax administrative doctrine') and immediately distinguishes scope from siblings by naming search_decisions for judgments and read_administrative_document for verification. An agent can tell this is a doctrine search tool, not an ID lookup or judgment search, without opening the 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?

Gives explicit routing rules: petete for DGT interpretations and binding consultations, dyctea for TEAC/TEAR/TEAL criteria and economic-administrative appeals, omit the filter to search both. It also names two follow-up/alternative tools and the conditions that select them (comparison with judgments, verifying the actual criterion).

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 read-only and idempotency, but the description adds non-obvious behavior: natural mode is hybrid retrieval requiring vectors and limited to a 50-decision window, the original query is preserved, and retrieval does not establish legal interpretation or exhaustive coverage. Those operational caveats are exactly what an agent needs and are not derivable from the annotations.

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

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

It is front-loaded with scope, then routing, then return values, then mode semantics, so an agent can stop reading early. It is fairly long and repeats some search_mode guidance already present in the schema's own description, but no sentence is pure 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 no output schema, the description supplies the return shape (identifiers, metadata, official links, indexed excerpts), and it covers the highest-risk parameters and the 50-decision retrieval window. Pagination limits and court-name format are not addressed, which keeps it short of fully complete for a 10-parameter 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 only 10%, so the description must compensate, and it does for the tricky parameters: source_groups enum values and omission semantics, countries ES/EU filtering, search_mode default and interaction with query_intent, and the shape of query_intent usage. It leaves court, page, and per_page unexplained, which is a residual gap but a minor one for a search tool.

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 opening sentence names a specific verb and resource ('Search Spanish and EU court judgments') and even lists the dimensions it can search by. It explicitly states what it does not cover (DYCTEA, PETETE) and names the sibling tool that handles that space, so an agent can separate it from search_administrative_documents without reading schemas.

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

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

The description gives explicit routing: use search_administrative_documents for tax administrative doctrine, use query_intent for required/alternative/phrase/excluded terms, use read_decision to verify literal passages. It also explains when search_mode=strict is required and that query_intent with explicit natural is invalid, so the agent knows both when to use this tool and how to configure alternatives within it.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered; the description adds genuinely new behavior: default retrieval mode when allowed_modes is omitted, a server-enablement prerequisite for vector modes, and a substantive content caveat that CENDOJ summaries are not full judgments. It stops short of disclosing result limits/pagination or behavior when a requested mode is unavailable beyond the enablement note, which keeps it below 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?

Purpose and sibling routing are front-loaded in the first two sentences, followed by return-value and mode guidance. Dense but largely waste-free; the allowed_modes topic is spread across three sentences that could be merged, a minor structural inefficiency rather than 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 13-parameter retrieval tool with no output schema, the description usefully summarizes what comes back (official links, versions, content_scope) and the mode semantics. But it leaves most filter parameters undocumented and never explains the relationship between source_groups, body_code/body_family and court_category_code, which an agent needs to filter 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% and 13 parameters exist, so the description carries the burden. It does real work on allowed_modes by enumerating the accepted values (judicial_text, semantic_vector, judicial_hybrid), which are absent from the schema's enum-less arrays, and explains the default when omitted. However, source_groups, body_code, body_family, court_category_code, require_semantic, content_languages and response_language remain entirely unexplained, so compensation is partial.

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?

"Search judicial passages from configured sources" names a specific verb (search) and resource (judicial passages), and immediately scopes it against siblings by pointing to search_decisions/read_decision for specific judgments and search_administrative_documents for DGT/TEA doctrine. An agent can discriminate this tool from every relevant sibling 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?

Explicit routing rules are given for three alternatives (search_decisions, read_decision, search_administrative_documents), plus a concrete mode-selection rule: hybrid thematic by default, allowed_modes=['judicial_text'] for explicit textual retrieval. When-to-use and when-to-use-something-else are both stated rather than inferred.

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