Harel travel insurance (Israel): prices by age, trip rules, coverage, medical conditions.
Scored across 7 tools
Tools mostly target distinct facets: age rules, condition rules, coverage limits, destination info, quoting, and page retrieval. Slight overlap exists because age_rules and condition_rules both expose pre-existing-condition extension pricing, and quote_trip overlaps age_rules on price output, but the descriptions make the boundaries reasonably clear.
Names use consistent snake_case casing throughout. The only deviation is that most tools are noun/topic phrases (age_rules, condition_rules, coverage_limits, destination_info, quote_trip) while fetch and search are bare verbs, which is a minor inconsistency.
Seven tools is well-scoped for a travel-insurance information and quoting server. Each tool earns its place by covering a distinct area, and the search/fetch pair adds web retrieval without bloating the surface.
Core informational workflows are covered: pricing by age and trip, pre-existing condition rules, base coverage limits, destination requirements, and searchable guides. Minor gaps remain, such as direct purchase/claim operations or a batch condition comparison tool, but agents can work around these via search/fetch.
For one age: daily price (rest of world / USA), maximum trip length in one policy, pre-existing extension price and its maximum covered days, trip-cancellation prices.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and a closed (non-open-world) lookup, so the safety profile is covered. The description adds useful behavioral context by disclosing what data the lookup returns, but says nothing about auth needs, rate limits, or whether the age range (0-95) is enforced/handled at boundaries. Adequate but thin given the structured hints already do the heavy lifting.
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 opens with the operative scope ('For one age') and then lists the return payload. It is dense but every clause carries content; the parenthetical regional split is the only mildly awkward part.
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 must convey what comes back, and it does enumerate the returned fields (prices, trip-length cap, pre-existing terms, cancellation prices). For a read-only single-arg lookup this is largely sufficient, though it lacks any indication of result format or structure.
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% for the single 'age' parameter, so the schema alone gives only a bare integer with min 0 / max 95. The phrase 'For one age' confirms it is a single-age (not range) lookup, which adds a little meaning, but there is no detail on units, boundary handling, or what happens for ages outside coverage.
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 resource (age-based insurance rules) and enumerates the exact fields returned: daily prices by region, max trip length, pre-existing extension price/days, and trip-cancellation prices. That lets an agent know what this tool is for. It stops short of naming how it differs from siblings like condition_rules or coverage_limits, so an agent must infer the split from the title and name alone.
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 when-to-use guidance, no mention of alternatives (condition_rules, coverage_limits, quote_trip), and no stated prerequisites. The scope 'For one age' implies a single-age lookup but does not say when this is preferable to the other pricing/rule tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a pre-existing medical condition (e.g. diabetes, stent, COPD, cancer): what Harel's health declaration says about it (quoted from the official proposal form), whether the pre-existing-condition extension is required by the form's logic, its price per day by age and max covered days. Pass a Hebrew or English condition name or a slug.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | ||
| condition | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the answer is quoted from the official proposal form, the extension requirement is derived from the form's own logic rather than a lookup, and pricing is per-day by age with a max-covered-days cap.
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 condition framing, then the three payload items, then the input convention — no filler sentences. It is packed tightly enough that a reader must parse carefully, but nothing is redundant with the schema or annotations.
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 must describe the return, and it does: declaration quote, extension requirement, price per day, max covered days. Combined with annotations that cover safety and a two-parameter schema, an agent has everything needed to call it correctly; unknown-condition behavior is the only minor 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 0%, so the description must carry the load, and it does for the critical parameter: `condition` accepts a Hebrew name, an English name, or a slug. `age` is only implicitly documented via "price per day by age" — its optionality (only `condition` is required) and 0-95 range are never stated.
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 a specific resource (Harel's health declaration / underwriting rules for a pre-existing medical condition) and enumerates exactly what is returned: the declaration text, whether the pre-existing-condition extension is required, and the per-day price. It contrasts implicitly with siblings like age_rules and coverage_limits by anchoring everything to a medical condition, but never names or explicitly differentiates itself from 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?
"For a pre-existing medical condition (e.g. diabetes, stent, COPD, cancer)" establishes the domain of applicability, which is a usable trigger. However, it never states when to prefer this over age_rules or coverage_limits, gives no exclusions (e.g. what to do for a condition with no declaration entry), and does not mention prerequisites for calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Limits of liability of the base policy (medical $5M, medicines, dental, rescue, third party, continued treatment in Israel) with deductibles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world (openWorldHint=false), so the safety profile is covered. The description adds value by previewing the returned content — it names the coverage categories and gives one concrete figure ($5M medical) — which matters because there is no output schema. However, it gives no amounts for the other categories and says nothing about whether figures are per-person, per-trip, or per-policy.
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 sentence that front-loads the resource ('Limits of liability of the base policy') before the parenthetical detail. The parenthetical is dense but every listed item earns its place by naming a coverage category.
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 zero-parameter read tool with no output schema, the description should carry the burden of explaining what comes back. It lists the coverage categories and one figure but omits amounts for the remaining categories, the currency/denomination semantics, and deductible details, leaving the return shape only partially described.
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?
The tool takes zero parameters, so the baseline is 4. The description correctly introduces no parameter concepts and has no parameter semantics to clarify.
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 — the coverage limits of the base policy — and enumerates the coverage categories (medical, medicines, dental, rescue, third party, continued treatment) plus deductibles. An agent can tell this apart from age_rules and condition_rules, which cover different policy aspects, though the description never explicitly contrasts itself with those siblings.
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 statement of when to call this tool versus age_rules, condition_rules, or destination_info. The enumerated categories weakly imply it is the reference for coverage amounts, but no condition, prerequisite, or alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a destination country: Harel price class (USA vs rest of world), whether the country requires proof of insurance at entry, the Israeli National Security Council travel warning level, emergency numbers and the Israeli mission — each with its official source.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country name in Hebrew or English, or slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and a closed-world lookup, so the safety profile is covered. The description adds a useful behavioral trait — each fact is attributed to an official source — but says nothing about freshness, rate limits, or what happens for an unrecognized country, so it only modestly extends 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 a single front-loaded sentence that leads with the resource and then lists the returned facts without filler. The long enumerative tail is dense but every item is a distinct field, so 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 carries the return-value burden and does so well by naming each fact returned and noting source attribution. Minor gaps remain — no mention of whether unknown countries or partial data are handled — but for a one-parameter read tool this is nearly 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 100% and the single country parameter is already documented as accepting Hebrew, English, or a slug. The description only restates that a destination country is the input, adding no format or matching-rule detail beyond the schema, so the baseline of 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?
The description names a specific resource (destination country facts) and enumerates exactly which facts it returns: price class, entry insurance requirement, NSC travel warning level, emergency numbers, and the Israeli mission. This clearly separates it from siblings like age_rules, condition_rules, coverage_limits, and quote_trip, which cover other insurance dimensions.
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 returned fields (warning level, entry requirements, emergency numbers) suggest a pre-trip / destination-check context, but the description never says when to use this versus quote_trip or coverage_limits, nor any exclusions or prerequisites. It gives an agent enough to guess the intent, but not explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Title, summary and URL of a page returned by search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Page path, e.g. /matsav-refui |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered without the description. The description adds the return shape (title, summary, URL), which is genuinely useful since there is no output schema, but it does not clarify whether page body content is fetched or what the response actually contains.
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 short fragment with no padding, and the search-relationship hint is front-loaded. It is efficient, though its brevity tips into under-specification rather than true economy.
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 annotations and no output schema, the description partly covers the return shape but leaves the core behavior ambiguous: fetching a page yet returning only title/summary/URL is not explained. Just adequate, with a clear remaining 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?
There is one parameter with 100% schema description coverage ('Page path, e.g. /matsav-refui'), so the schema already defines the id. The description only obliquely signals where the id comes from ('returned by search') and adds no new format or origin detail beyond the schema example.
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 the resource (a page) and ties it to the 'search' sibling, so an agent can infer this retrieves a previously-found page. However, it states only the returned fields ('Title, summary and URL') rather than the action, so the actual verb must be inferred from the name/title. Not a tautology, but not a clean verb+resource statement either.
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?
'a page returned by search' implies the workflow: call search first, take an id from the results, then fetch. That is meaningful implied guidance, but there is no explicit when-to-use/when-not-to-use statement and no mention of alternatives among siblings like destination_info or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimated price (USD) of Harel 'Passport First Class' travel insurance for a trip, per traveller and total, from Harel's official 2026 tariff. Also says if the trip exceeds the maximum days for an age.
| Name | Required | Description | Default |
|---|---|---|---|
| usa | No | Destination includes the USA | |
| ages | Yes | Age of each traveller | |
| days | Yes | ||
| cancel | No | Trip cancellation up to $5,000 (basic) or $10,000 (extended) | |
| winter | No | ||
| baggage | No | ||
| extreme | No | ||
| preexisting | No | Add the pre-existing medical condition extension |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), but the description adds real behavioral context: the price comes from Harel's official 2026 tariff, the result is broken out per traveller and total, and the tool emits a warning when the trip exceeds the maximum days for an age. That edge-case disclosure is genuinely useful.
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 core purpose and tight at two sentences with no filler. The second sentence is somewhat tangential but earns its place by disclosing the out-of-range behavior.
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 read-only, idempotent quoting tool with annotations covering safety and no output schema, the description adequately explains what comes back (price per traveller/total and the max-days warning). It remains incomplete on the meaning of four of the eight parameters, which an agent would need to set the optional coverage flags.
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% and the description does not compensate: the undocumented booleans (winter, baggage, extreme) are never explained anywhere, nor is how ages/days interact with the quoted tariff. Only 'per traveller and total' maps loosely to the ages parameter.
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 verb+resource ('Estimated price (USD) of Harel Passport First Class travel insurance for a trip') and states the return shape (per traveller and total). It is clearly distinguishable from rule-lookup siblings like age_rules and coverage_limits, though it never names them 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?
There is no guidance on when to call this versus the sibling rule/limit tools, and no prerequisites or exclusions are stated. Usage is only weakly implied by the domain context of trip pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find pages on hartrip.co.il (Hebrew guides on Harel travel insurance). Returns ids to pass to fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and scope are covered structurally. The description adds the useful fact that results are ids consumed by fetch, which is behavioral context beyond the annotations, but says nothing about result size, ranking, or pagination.
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, front-loaded with what the tool returns and how the result is used. No wasted words.
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?
Given one required param, no output schema, and rich annotations, the description covers the essentials of purpose and handoff to fetch. But the near-total absence of parameter guidance and lack of differentiation from domain-specific siblings leaves it only minimally 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 the single `query` parameter is completely undocumented. The description does not explain what the query string should contain (free text? Hebrew? keywords?), leaving the only parameter semantically empty.
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 (Find pages) plus the resource and domain, and even describes the content (Hebrew guides on Harel travel insurance). It's clear but does not distinguish itself sharply from the sibling `fetch`, only implying a relationship by saying it returns ids for fetch.
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 phrase 'Returns ids to pass to fetch' implies a two-step workflow, hinting that this is the discovery step preceding fetch. However, it does not state when to use search vs. the many domain-specific siblings (age_rules, condition_rules, coverage_limits, destination_info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
age_rulescondition_rulescoverage_limitsdestination_infofetchquote_tripsearchIsraeli health insurance from the insurers' own documents: covers, fast routes, refunds, surgeons.
Compare travel insurance quotes from 15+ insurers — Schengen, WHV, students, long stays, seniors.
Morocco travel for Israeli travelers: e-visa, itineraries, guides, Shabbat times, hilula dates.
Search flights by route, dates, passengers, and cabin class. By Alice, Israel's travel app.
Add one secure layer between your agents and this server.
