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

Annotations only cover the safety profile (readOnly, idempotent, openWorld, non-destructive); the description adds genuinely new behavioral context: live data source, the exact set of returned fields, how the licence fee is derived (price group x age tier, incl. the 135 ILS broadcasting add-on), and explicit exclusions ('No insurance prices', estimate 'never insurance'). That is unusually informative about what the call yields and what it refuses to compute.

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 the usage trigger, then a dense but purposeful enumeration of returns and exclusions — nearly every clause earns its place. The Hebrew tail paragraph restates the English content rather than extending it, which is a mild redundancy, though plausibly intentional for bilingual users.

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 an output schema present, the description does not need to enumerate returns, yet it does so anyway and layers on data provenance, calculation basis for the fee, and explicit scope exclusions. For a single-parameter read lookup, nothing an agent needs 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 100% and the schema already specifies the plate format, length bounds and dash/space tolerance, so baseline is 3. The description adds nothing about the parameter beyond restating that the plate is Israeli, which the sibling context and title already imply.

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 — live vehicle lookup by Israeli licence plate against Ministry of Transport open data — and the trigger condition ('when the person gives an Israeli licence plate') immediately separates it from model-level siblings like model_info, search_models and list_makes. An agent can pick this tool 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?

The opening clause gives a precise, input-driven trigger ('Use when the person gives an Israeli licence plate'), which is strong routing guidance. It stops short of naming an explicit alternative or a when-not-to-use condition (e.g. 'for recall-only questions use check_open_recall'), so it is clear context without exclusions.

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