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

Annotations already establish readOnly/idempotent/non-destructive, so the description correctly spends its space elsewhere: it discloses truncation behavior, the has_more flag, the ~3000-character chunk size, next_offset continuation, and a citation link to the Knesset database. The warning never to reconstruct truncated text from memory is exactly the kind of behavioral guidance annotations cannot carry.

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 with purpose, then lookup modes, then the truncation caveat — a sensible order with no filler sentences and every clause doing work. It is a single dense block, and the long enumeration of statutes plus the trailing Hebrew title slightly crowd out the operational guidance, 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 takes on return-value disclosure and does so: section text, section number, title, and citation link. Combined with the truncation/continuation protocol and the at-least-one-parameter rule, an agent has everything needed to call this correctly on the first attempt.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns more by stating the cross-parameter constraint that the schema does not encode — 'At least one of query, law or section is required' — given there are zero required properties. It also supplies a worked example (law "פקודת מס הכנסה", section "102") tying two parameters together, though it adds little to offset/limit beyond what their schema descriptions already say.

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 (search) and resource (primary Israeli tax and business legislation, 'the statutes themselves'), and enumerates concrete examples (Income Tax Ordinance, VAT Law, Companies Law). The phrase 'the statutes themselves' plus 'Use this when the question turns on what the LAW says' separates it in substance from secondary-source siblings like misim_search_library and misim_list_guides without naming 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?

Gives clear when-to-use framing ('Use this when the question turns on what the LAW says') and two concrete invocation modes: direct lookup via law + section, or free-text via query. It never names an alternative sibling tool or states when NOT to use it, so the routing guidance is strong but not exhaustive.

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