israel-gateway

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 fully covered. The description adds only that the conversion uses representative (indicative) rates, and stays silent on rate date, missing/unsupported currencies, rounding, and error behavior for an openWorld tool that depends on an external feed.

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 operation, inputs and rate source are all in the first clause. Nothing could be trimmed without losing meaning.

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, so the description should say what comes back (converted amount, rate used, effective date), but it does not. For a simple 3-parameter conversion tool this is a moderate gap rather than a blocking one, since the input semantics are largely inferable from the schema.

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 67%: 'to' documents its ILS default and 'from' gives a USD example, but amount has no description and the description text adds nothing about parameter meaning. With coverage in the mid range the description should compensate for the undocumented amount (units, negative values, rounding) and does not.

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 (convert) and resource (amount between currencies) plus the rate source (Bank of Israel representative rates). It is clearly distinct from boi_exchange_rates by being a computation rather than a rate lookup, though it never names that sibling 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?

Usage is only implied: the phrase 'representative rates' signals official/indicative BOI rates rather than live market conversion, which is useful context. However there is no explicit when-to-use, no exclusion relative to boi_exchange_rates, and no note about which currencies are supported or how dates affect the rate.

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 and non-destructive behavior, so the safety profile is covered. The description adds the meaningful nuance that these are 'representative' official BOI rates rather than market rates, but it never states what happens when currencies is omitted (presumably all rates) or which date/quoting convention applies.

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 clauses with the resource stated first and the parameter note after; nothing is padded. The second clause largely echoes the schema, so it is near-redundant rather than harmful.

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 optional parameter and no output schema, the description should hint at the return shape (per-currency rate, effective date, base ILS), because the agent has no schema to consult. As written it is adequate to invoke but leaves the response format entirely unknown.

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% and the single parameter already carries an example and maxItems, so the description's 'optional list of currency codes' adds only confirmation of optionality. No additional semantics (case sensitivity, unknown-code handling, default set) are provided beyond the schema.

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?

Names the specific resource (official Bank of Israel representative exchange rates) and the base currency (ILS), so an agent knows exactly what data is returned. It stops short of differentiating from the obvious sibling boi_convert, which covers currency conversion rather than rate lookup.

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?

No statement of when to use this instead of boi_convert or how the results should be used; the only guidance is that the currency list is optional. The agent must infer that this fetches rate tables while boi_convert performs arithmetic.

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, so the safety profile is fully covered structurally. The description's only added behavioral detail is the queryable:true gating rule; it says nothing about pagination behavior, the limit ceiling of 100, or result shape, which matters for a paging-capable read tool.

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 short sentences with the eligibility constraint front-loaded and no filler. Slightly under-filled rather than over-filled, but every sentence earns its place.

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 4-parameter read-only tool with no output schema, the core call path is adequately conveyed. The main remaining gap is pagination semantics for limit/offset, which neither the schema nor the description explains and which an agent needs to page through large resources.

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 50%: limit and offset carry no descriptions, and the description does not compensate — it never mentions pagination, page size, or the 100-row cap. The one thing it does cover ('Optional full-text filter') is already documented verbatim on the query parameter, so it adds no meaning beyond the schema.

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 ('Query rows from a data.gov.il resource') and names the gating condition (queryable:true), which lets an agent distinguish it from datagov_search (metadata search) versus row retrieval. The differentiation from siblings is implied by the resource-level scope rather than stated 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?

The 'only resources marked queryable:true' clause is a genuine eligibility precondition, and the schema's resource_id hint ('from datagov_search') implies a search-then-query workflow. However, the description itself never tells the agent to run datagov_search first or what to do if the resource is not queryable; usage context is implied rather than 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 readOnlyHint=true, idempotentHint=true and openWorldHint=true, so safety is covered; the description adds the non-obvious query-language guidance and the output hand-off to datagov_query. It does not mention result-count behavior or that only up to 20 hits come back, which would have made this 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?

Three short sentences with zero filler, and the core purpose is front-loaded ahead of the tips and hand-off. Every sentence carries distinct 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?

With no output schema, the description does the necessary work by naming the return content (datasets + resource_id) and how to consume it. The only gap is pagination/limit behavior for a tool that clearly returns a bounded list.

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 50%: 'query' is documented in-schema, but 'limit' has no description anywhere. The description compensates partially by telling the agent what to put in 'query' (Hebrew terms), but says nothing about what 'limit' controls or that it caps at 20 – though the maximum is visible in the schema itself.

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 Israel's national open-data portal') and names the concrete payload ('datasets and their resource_id values'). It also points at the sibling consumer (datagov_query), so an agent can tell this apart from the other datagov tool 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?

'Hebrew queries work best' plus 'resource_id values for datagov_query' gives clear context and an implied two-step workflow (search then query). It stops short of an explicit exclusion such as 'do not use this to fetch dataset rows', leaving the boundary with datagov_query only implied.

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, openWorld and non-destructive, so the safety profile is covered. The description adds what annotations cannot: the return payload is store_id values, and the input language is Hebrew — both material to calling and chaining it correctly. It does not say what happens if both filters are given or whether zero matches is an error.

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 sentences, zero waste. The resource and filters come first and the chaining hint second, which is the right front-loading for a discovery tool.

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 rightly names the return value (store_id). For a 2-optional-param, no-required-args lookup tool this is nearly enough; only the both-filters-provided case and the empty-result behavior are left implicit.

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 both optional parameters including the Hebrew example for city. The description's '(Hebrew)' note largely duplicates the schema's 'City in Hebrew, e.g. חיפה', adding no combination or precedence semantics.

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 (find Shufersal branches) plus the two filter axes (city or name). It also names the downstream sibling grocery_search, so an agent can immediately place it in the workflow rather than confusing it with grocery_search itself.

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?

Clear usage context: this is the lookup step that produces store_id values for grocery_search. It does not state a when-not condition (e.g., that this is Shufersal-only and other chains are not covered), so it stops short of full routing guidance.

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 open-world, so the safety profile is covered. The description adds genuine context beyond them: the data comes from official price-transparency files, prices are 'current' shelf prices, and results are sorted cheapest first — useful behavioral traits for interpreting output.

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 short sentences, front-loaded with the resource and scope, then search mode, then result ordering. Nothing redundant and every sentence carries information an agent would use.

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 does cover the essentials — source, freshness, search modes, sort order — which is enough to call the tool correctly. It stops short of describing result fields (e.g. price vs. unit price, product metadata) that an agent might need to interpret the response.

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 67% and the description largely restates what the schema already says (Hebrew name or barcode for query, branch-specific store). The Hebrew example adds a little practical value, but the limit parameter is undocumented in both places, so the description does not compensate for the gap.

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 (shelf prices at a Shufersal branch) plus the data source (official price-transparency files) and result ordering. It's clearly a price-lookup tool, distinct in intent from grocery_find_stores, though it never names that sibling explicitly — the differentiation only surfaces via the store_id schema description.

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 implies how to search (Hebrew product name like 'חלב 3%' or barcode) and that a specific branch is required, but gives no explicit when-to-use/when-not guidance and no mention of the grocery_find_stores prerequisite or what happens if the query is ambiguous. Usage is inferable rather than 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value by explaining the day_off=true distinction for yom tov, which is the one output behavior an agent must anticipate. It does not say what happens when year is omitted or whether the result is a list of objects vs. dates.

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?

One short sentence with the key qualifier (day_off/yom tov) front-loaded and no filler. It is arguably too terse given the undeclared parameter, 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?

For a single-parameter read-only tool with rich annotations and no output schema, the description covers the headline output semantic but omits the year default/range and any sense of return shape. Adequate to call correctly, not quite complete.

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 there is a single optional 'year' parameter with bounds 2000-2100 and no default documented anywhere. The description only says 'for a year' without stating the range, the default behavior when omitted (required parameters = 0), or the expected format, so it fails to compensate for the coverage gap.

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 specific resource (Jewish/Israeli holidays) and scopes it to a year, which distinguishes it from the nearest sibling, shabbat_times. It is a noun phrase rather than a verb+resource, but the intent is unambiguous.

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 indication of when to use this versus shabbat_times or other calendar-adjacent siblings, nor any prerequisites or exclusions. The day_off note clarifies output semantics rather than usage, leaving the agent to infer applicability.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), and the description still adds real behavior: the ~24h recency window and newest-first ordering, which the annotations cannot convey. It does not mention rate limits, upstream availability, or failure behavior for an open-world external feed, 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?

Two short sentences, zero filler, and the most decision-relevant fact (the ~24h recency window) is front-loaded.

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?

Annotations are rich and there is no output schema, so the description doesn't need to explain return values. But for a tool with an undocumented limit parameter and an external open-world data source, it leaves the agent guessing how many alerts come back and what a typical response looks like.

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 50%: city is documented in the schema itself, and the description's 'Optional Hebrew city filter' largely restates that. The limit parameter is undocumented in both the schema and the description (no indication that it caps the number of alerts returned), so the description does not compensate for the coverage gap; baseline 3.

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 specific resource (Home Front Command alert history) and a concrete scope (~last 24h, newest first), so the agent knows exactly what it returns. It implicitly separates itself from the sibling oref_current_alerts via 'history' vs. 'current', but never names that sibling or states the contrast 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?

The ~24h window implies when this tool is relevant and carries a weak implication that live alerts belong to oref_current_alerts. However, there is no explicit when-to-use/when-not statement and no alternative is named despite oref_current_alerts sitting right next to it in the tool list.

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 open-world, so the safety profile is covered. The description adds genuinely useful context that the upstream source is Israel-restricted and reached via an Israeli gateway, hinting at possible latency or availability constraints, but says nothing about response format or failure behavior when no alerts are active.

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 short sentences, all earning their place: purpose first, then the optional filter, then the infrastructure caveat. 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?

For a one-optional-parameter read tool with no output schema, the description covers purpose, filtering, and source constraints adequately. Only the shape of returned alert data (areas, alert categories) is left unaddressed, which is a minor gap.

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 single 'city' parameter is fully documented in the schema. The description only restates the Hebrew requirement and example without clarifying matching behavior (exact vs. substring, multi-area alerts), so baseline 3 applies.

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 resource (Pikud HaOref / Home Front Command alerts) and temporal scope ('right now' / 'active'), with examples of alert types. It implicitly separates itself from oref_alert_history via 'right now', but never names the sibling or spells out the contrast.

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?

Clearly frames the use case as real-time alerts and explains that the city filter is optional and must be in Hebrew, with a concrete example. It does not state when to avoid this tool or explicitly route to oref_alert_history for past data.

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=true, so the safety and freshness profile is covered. The description adds useful scope facts (this week, Israeli city, Hebrew or English input) but says nothing about behavior for unknown cities, default behavior, or result reliability.

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?

One dense sentence that front-loads the returned data and ends with the input constraint. No filler and nothing important is 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?

With a single optional parameter, full schema coverage, and annotations present, the description covers what the tool returns and the input format. Only the lack of routing guidance relative to israel_holidays keeps it from full marks.

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, and the description earns above baseline by disclosing that the city may be given in Hebrew or English — a real input-format fact the schema does not state (its example is Hebrew-only).

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?

Names specific outputs (candle lighting, havdalah, parasha), a specific time window (this week), and a specific scope (an Israeli city). That is a concrete verb+resource statement an agent can act on. It doesn't explicitly contrast with the nearest sibling, israel_holidays, but the domain overlap is narrow enough that confusion is unlikely.

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 no when-to-use or when-not-to-use guidance and does not mention israel_holidays, the sibling most likely to be confused with it. The agent must infer usage from the phrase 'this week in an Israeli city' alone.

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