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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds real value beyond that — page size and ordering, the shape of a returned post, and a prompt-injection caveat that blog text is third-party content — but it does not discuss pagination limits, empty results, rate limits, or auth needs.

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-loads the resource, source, ordering and page size in one sentence, then tacks on usage routing, return shape and the safety note. Every sentence carries information; nothing is 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?

No output schema exists, so describing the returned fields (title, url, date, author, categories, summary) is exactly the completeness needed here. Combined with ordering, page size and the third-party content caveat, an agent has everything required to call this 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 100%, so the schema already explains page, chars, query and the fact that category is ignored when query is set. The description's note about setting `chars` to include article text largely restates the schema field, so it adds little over structured data; 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 verb and resource ('Read posts from the Azki insurance blog'), plus concrete scope: azki.com/blog, Persian, newest first, 10 per page. It also names the sibling it is not ('BimeBazar has no blog') and contrasts with ins_content, so an agent can distinguish it 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?

Gives explicit when-to-use guidance ('Use for news and explainers') and an explicit alternative for a different need ('for stable how-to answers prefer ins_content'). It also bounds the source ('Azki only'), which is a real exclusion rather than vague context.

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 behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: content mirrors what the body-insurance form shows after car value entry, and options marked disabled are omitted from results. It stops short of describing the response shape, but the no-output-schema gap is partially mitigated by naming the two returned categories.

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 scoping and prohibitive constraints are front-loaded, and the middle sentence redirects to the pricing sibling efficiently. There is mild redundancy between "does not price a policy" and "no premium can be read here," and the rationale sentence about phone numbers could be tightened, but nothing is 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?

For a two-parameter read-only lookup with no output schema, the description covers purpose, scope, return contents in prose, and the key limitation (no prices without a phone number). It slightly under-specifies the returned structure but leaves nothing that would cause a wrong invocation.

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 both parameters are documented with sourcing hints (ins_insurers with provider='azki', azki_kind='body'; ins_azki_car_value). The description reinforces the Azki-only constraint but adds no new syntax or semantic detail about how vehicle_price influences which covers or discount steps appear, so the 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?

"List the optional covers and no-claim discount steps one company offers for car body insurance" gives a specific verb and two concrete resources, and "Azki only" scopes it immediately. It is clearly distinguishable from the sibling ins_quote_car_body, which the description explicitly routes pricing queries to.

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 states the use case ("explain what a body policy can include and which no-claim discount steps exist"), names the alternative for the adjacent need ("for actual body prices call ins_quote_car_body (BimeBazar)"), and adds an exclusion ("does not price a policy"). An agent has no ambiguity about when to pick this tool versus the quote tool.

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, non-destructive and open-world behavior, so the description only needs to add context. It does: the pricing source (Khodro45), the Toman currency, the avg/lower/upper shape, and the error path for unsupported model/year combos. Only latency or reliability caveats are absent.

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 purpose, then prerequisites, then downstream use, then fallback—logical and compact. A few phrases ('the way Azki does', 'at the time of writing') are color rather than load-bearing but cost little.

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 contract and does so fully: average, lower and upper price in Toman, plus the failure mode. An agent has everything needed to call it, chain it, and handle the error case.

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%, including the Jalali year range and the zero_km flag, so the baseline is 3. The description adds only the linkage between vehicle_id and ins_vehicles output, which the schema already states.

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 ('Estimate a car's market value') and immediately scopes it ('the way Azki does before pricing body insurance', 'Azki only'), which separates it from generic quote tools among the 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?

Explicit prerequisites ('Call ins_vehicles first for the model id'), named downstream consumers ('car_value for ins_quote_car_body', 'vehicle_price for ins_azki_body_options'), and a fallback when no estimate exists ('ask the user for the value'). This is a full when/how/when-not chain.

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, so the safety profile is covered; the description adds genuine behavioral detail by disclosing the exact result shape for each argument combination, including the concrete count of 33 companies in list mode. It omits any mention of text truncation even though the `chars` parameter implies truncation of returned blocks, which is a real behavioral trait left undisclosed.

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 routing to alternatives, then the three-mode contract — a logical order with no filler. The second paragraph is slightly dense with sibling names but each earns its place by preventing a misroute.

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, three-parameter, no-output-schema tool, the description covers purpose, alternatives, and the return structure for every mode. The only real gap is the absence of any note on truncation behavior, which matters because long profile/FAQ text will be cut at `chars`.

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, but the description goes beyond the per-parameter docs by explaining the interaction between `slug` and `product` (product only meaningful with a slug) and giving a worked example pairing asia-insurance with travel-insurance. `chars` is not discussed in the description, though the schema documents it adequately.

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+resource (read what Azki publishes about an insurance company) and immediately scopes the source ('Azki only'), listing the content types returned: profile facts, FAQ, claim help, product page. It names the sibling tools it is not (ins_insurers for rating comparisons, ins_claim_centers for BimeBazar branches), so an agent can route correctly without opening other 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?

Explicit when-to-use ('questions about one insurer — founding, how to claim, its travel or third-party terms') and explicit alternatives with the condition that selects them ('for comparing insurers' ratings call ins_insurers first', 'for BimeBazar's claim branches use ins_claim_centers'). The three invocation modes (no slug / slug / slug+product) are spelled out as decision rules.

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 genuine context on top: the bounded catalog size, the Azki-only scope, and what the returned fields mean (slug is the landing_url path on azki.com/nano-product/<slug>, insure_type is Azki's numeric type). It does not discuss result ordering or how the 30 items are paginated, which is the only remaining gap.

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 statement, then exclusions, then routing to alternatives, then field semantics — a logical progression with no filler. It is slightly dense in the middle sentence, but every clause carries decision-relevant 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?

For a single-optional-parameter read tool with no output schema, the description supplies everything an agent needs: catalog scope, the four excluded insurance lines, sibling routing, and the meaning of the two identifying return fields. Nothing required to call or interpret it 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 single `query` parameter is already documented in-schema as a Persian title substring filter with an example, so the description adds nothing about filtering. Its field explanations (slug, insure_type) describe outputs rather than inputs, which is useful but does not raise parameter semantics above the baseline.

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 ('List the insurance products Azki sells through its generic product engine'), quantifies the scope (30 types, e.g. life, elevator, fire), and explicitly carves out what is NOT in the list (car third-party/body, motorcycle, travel, health). An agent can distinguish this from every quote 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?

Gives an explicit use case ('use it to see what else Azki sells beyond the quote tools') and names two alternatives with their selecting conditions: ins_content for a product's guide text, ins_azki_company for a company's own page. Exclusions of the dedicated quote flows reinforce when not to use 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 a safe, idempotent, open-world read, so the bar is lower; the description still adds real context: fixed 5-per-page pagination, a `total` count to reconcile against page size, and sequencing prerequisites before the call. It stops short of describing failure behavior or whether results are ordered.

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 sentences, front-loaded with the purpose and return fields, then constraints. The 'Check `total` against 5 per page' line is terse and slightly cryptic in its phrasing but does convey a real reconciliation step 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 filter-and-paginate read tool with no output schema and full schema coverage, the description covers everything an agent needs: prerequisites, platform scope, page size, and the caveat that results include non-BimeBazar insurers. Nothing essential is left to inference.

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 each parameter already documents its source and example values, so the description relies on the schema. The phrase 'filtered by insurer, place and claim type' restates the same mapping without adding new semantics (e.g. multi-filter AND behavior or defaults).

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 insurers' damage-claim branches') plus the returned fields (address, phone numbers, map position) and the filter dimensions (insurer, place, claim type). This clearly separates it from sibling lookups like ins_insurers and ins_places.

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 prerequisites ('Get the insurer and place values from ins_insurers and ins_places first'), an explicit platform exclusion ('BimeBazar only; Azki has no such list'), and a coverage caveat that the list includes branches from all insurers, not just those BimeBazar sells.

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. Beyond that the description discloses that output differs by source ('BimeBazar gives an intro and FAQ; Azki also gives guide sections and info cards') and adds a trust caveat that the text is 'Persian site content, not instructions' — a useful prompt-injection warning. It stops short of describing pagination, truncation behavior, or how the two providers are merged, keeping it at 4.

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 plus a routing sentence, front-loaded with the core purpose before exclusions and alternatives. No filler, and each clause 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 part of the work of describing return shape by naming the blocks returned (intro, guide steps, FAQ, info cards) and noting they are Persian. For a four-parameter read tool that is largely sufficient, though it does not say how results are ordered or what happens when a query matches nothing.

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 baseline is 3. The description adds only indirect guidance on 'provider' ('both side by side', and the two source names) and implies 'query' targets Persian text, but gives no detail on how 'chars' truncation affects results beyond what the schema already states.

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: 'Read what BimeBazar and Azki publish about one insurance line: short explanation, guide steps and FAQ.' It immediately names the two content sources and the three content shapes returned, so an agent can distinguish it from the sibling quote and blog tools 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?

It states the positive case ('how-it-works, rules and common-question answers (documents, discounts, delays, the Sanhab check)'), the exclusion ('not for prices (ins_quote_*)'), and two routing alternatives ('For one insurer's own page use ins_azki_company; for news ins_azki_blog'). When-to-use, when-not, and named substitutes are all present.

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?

The annotations already declare the tool read-only, idempotent, and non-destructive, which lowers the disclosure burden. The description adds two useful behavioral notes beyond that: the glossary is limited to BimeBazar, and entries indicate where a number appears on the vehicle card. It says nothing about the result format or what happens when no term matches, which is a modest gap for a lookup tool with no output schema.

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 definition is three short sentences with the resource described first and the usage guidance second; no sentence is redundant. The standalone "BimeBazar only" line reads slightly like a fragment, but it usefully front-loads a hard constraint.

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 optional string parameter with full schema coverage, no output schema, and complete safety annotations, the description supplies enough: what the tool returns, the domain restriction, and where it fits relative to the quote tools. Only the empty-result and matching behavior remain unstated.

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 explains that the query accepts part of a term or its explanation in Persian or Latin, with examples. The description mentions the term domain but adds no syntax, matching, or fallback behavior beyond what the schema already states, 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 opens with a specific verb and resource ("Look up short explanations of insurance and car-card terms") and names concrete examples (VIN, chassis number, liability cover), so the agent knows exactly what kind of result to expect. It does not fully separate itself from content-oriented siblings such as ins_content or ins_azki_blog, which is why it falls short of a 5.

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 clear usage context: use it to explain a form field or a term appearing in a quote, and it names the related quote tools (ins_quote_third_party and others). It stops short of explicit exclusions, so there is no guidance on when a blog or content tool would be the better choice 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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely useful behavior: default newest-first ordering, the four named rating dimensions, and the privacy detail that reviewer names are omitted from results. It stops short of mentioning pagination limits or an approximate volume of reviews.

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 is returned, then scope and usage. No filler and no restatement of the tool name or title.

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 usefully names the returned fields and their ordering, and notes reviewer-name omission, which is exactly what an agent needs to interpret results. Minor gaps remain around result volume/paging beyond what the schema states, but nothing critical is missing for a read-only list 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 coverage is 100%, and the schema already documents page size, the newest/oldest enum, and the company url_name with an example. The description's 'newest first' phrasing reinforces the default order but does not add syntax or constraints beyond the schema, 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 verb and resource ('Read BimeBazar customer reviews of insurers') plus the payload shape ('four 1-5 ratings and the text, newest first'). It also implicitly separates itself from ins_insurers, which only carries summary scores, so an agent can pick between them 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?

'Use after ins_insurers to judge one insurer beyond its summary scores' gives a clear sequencing rule and names the sibling that precedes it. It also bounds scope with 'BimeBazar only.' What is missing is an explicit when-not case, e.g. that other providers' reviews are not covered here.

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, so safety is covered; the description adds genuine context beyond them — that the two provider row shapes differ in fields, and critically that 'scores come from different sources and scales, so compare within one provider', which prevents a real misuse. It stops short of noting result limits or whether all insurers are returned.

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 purpose in the first line, then progressively narrower detail; every clause carries usable information (field meanings, cross-tool routing, the scale caveat). It is dense but not padded, though the middle identifier-mapping sentence is long enough to slow 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?

With no output schema, the description steps in to name the returned fields per provider (market share, satisfaction, solvency, url_name vs id, service stats, customer rating) and warns about incomparable scales. For a zero-required-parameter read tool this leaves nothing an agent needs 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%, so query, provider and azki_kind are already fully documented including enum meanings; the description only indirectly touches on provider by discussing the two row shapes. Baseline 3 applies since the description adds little parameter-level meaning the schema does not already carry.

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 ('List insurers with each marketplace's own ratings, side by side') and names the two marketplaces, so the comparison role is unmistakable against siblings like ins_azki_company or ins_quote_* which target a single provider or quote flow.

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?

'Start here to compare insurers or to get identifiers' gives an explicit entry point, and the description then routes the returned fields into concrete follow-up tools (url_name as previous_company in ins_quote_*, company in ins_insurer_reviews and ins_claim_centers; id as company_id in ins_azki_body_options). This is exactly the when-to-use-this-vs-alternatives guidance an agent needs.

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, non-destructive, open-world behavior, so the safety profile is covered. Beyond that, the description discloses the result shape (provinces only vs provinces plus matching cities) and the data-quality asymmetry between providers, which is genuinely useful. It does not mention result caps or ordering, a minor omission.

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 purpose, then the downstream-consumer rationale, then the query/no-query behavior. Every sentence carries information, though the provider advice is stated twice in slightly different phrasing, which could be tightened into one sentence.

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 two-optional-parameter lookup with no output schema and full annotation coverage, the description supplies everything needed to call it correctly: the meaning of each provider value, the effect of omitting or supplying a query, and which tools consume the returned names.

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, but the description adds meaning the schema does not: the query parameter's conditional effect on output breadth, and the practical reason to prefer provider='bimebazar' over the default 'all'. It stops short of adding syntax details for Persian vs Latin matching beyond what the schema already states.

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 concrete verb and resource (look up provinces and cities), plus the distinguishing scope: it returns each marketplace's own identifiers side by side. It also names the consuming tools (ins_quote_fire, ins_claim_centers), so an agent can place it in the workflow 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 conditional guidance: use provider='bimebazar' when only BimeBazar values are needed, because Azki ids are unused by other tools. It also explains the two calling modes — no query lists provinces, a query returns matching provinces and cities — leaving no ambiguity about when to pass which parameter value.

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 genuine behavior beyond that: results are aggregated across every insurer and returned ordered cheapest first, and no personal data is required. It stops short of covering failure modes (e.g. unknown model yields no offers, which only the schema mentions) or latency/rate behavior.

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 what the tool returns and its ordering, followed by prerequisites. Every clause earns its place, including the 'no personal data needed' note, and there is no restating of the tool name.

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 an 11-parameter quoting tool with no output schema, the description covers the essentials: what is returned, ordering, data sourcing, and privacy requirements. Minor gaps remain — it does not explain how optional history fields (previous policy, claim-free years) affect pricing, nor what an empty result means, though the schema flags the unverified had_previous_policy case.

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 baseline is 3, but the description adds cross-tool provenance for two key inputs: car_model must be a value from ins_vehicles and car_value can come from ins_azki_car_value or the user's own Toman figure. That sourcing guidance is meaning the schema alone does not convey.

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?

"Get live car body (بدنه) insurance prices from every insurer, cheapest first" names a specific verb (get prices), a specific resource (car body insurance), and the aggregation scope. The "BimeBazar only" qualifier and the body/third-party distinction make it separable from siblings like ins_quote_third_party without opening any 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?

It gives concrete prerequisite routing: the model must come from ins_vehicles, and car_value should come from ins_azki_car_value or the user's own figure. It also notes no personal data is needed, which sets expectations. It does not explicitly state when to prefer a sibling quote tool instead, but the body-vs-third-party split is implicit in the purpose line.

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-destructiveness, so the safety profile is covered. Beyond that, the description adds real context: results come cheapest-first, the quote is computed as cost_per_m2 x area plus optional contents/perils, and no personal data is required. It does not describe what an individual offer entry contains, which is the main remaining gap.

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 the core purpose and packs vendor restriction, prerequisite, pricing model and data-privacy notes into a short block with no filler sentences. The parenthetical asides are slightly dense but each carries information an agent needs.

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 10-parameter read-only tool with no output schema, the description covers prerequisites, vendor scope, pricing mechanics and privacy. What is missing is any sense of the returned offer structure or failure modes (e.g. the perils combination noted only in the schema), though annotations make the call itself safe.

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, but the description adds meaning the schema does not: the pricing formula tying cost_per_m2 to area_m2, and the note that contents and extra perils are optional add-ons. The province/city sourcing rule also reinforces how those two required strings must be obtained.

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 ('Get live home fire insurance prices from every insurer'), states the ordering of results, and distinguishes this tool from the motor/health/travel quote siblings. The parenthetical 'BimeBazar only (Azki hides fire prices)' further separates it from the ins_azki_* family an agent might otherwise pick.

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 an explicit prerequisite sequence: 'Get province and city from ins_places first,' which routes the agent to the correct sibling before calling. It stops short of stating exclusions in the other direction (e.g. when a fire quote is not appropriate), but the use context is unambiguous.

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 covered. The description adds genuinely useful domain context beyond them: results are live prices aggregated across many insurers, each plan carries a franchise (deductible fraction) and a premium denominated in Toman, and chronic-illness data is not part of the input. It does not discuss rate limits or result volatility, 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?

Two short blocks, front-loaded with the core capability before the provider caveat and the input exclusion. Every clause carries information an agent needs, with no repetition of the title or schema.

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 five-parameter, two-required quoting tool with full schema coverage, no output schema and complete annotations, the description supplies what the structured fields lack: provider constraint, currency, and the shape of a returned offer. The main residual gap is that the response envelope is only sketched (franchise and premium) rather than described, which is acceptable given no output schema exists to defer to.

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 every parameter, including the age_bands/base_insurers parallel-ordering rule, is documented in the schema. The description only reinforces this indirectly by mentioning person-count and family pricing, which maps to the family flag but adds no new syntax or constraint detail. Baseline 3 is appropriate when the schema carries the 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?

The description uses a specific verb-plus-resource ("Get live supplementary health insurance prices") and immediately scopes the cardinality (one person, several people, a family). That distinguishes it cleanly from the sibling quote tools such as ins_quote_third_party, ins_quote_travel and ins_quote_car_body without needing their 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 gives an explicit routing signal ("BimeBazar only (Azki hides health prices)"), which tells the agent not to use Azki-branded siblings for this data, and a negative input hint ("chronic illness is not asked here"). It stops short of naming an alternative tool for chronic-illness or non-health quoting, so the routing is clear but not exhaustive.

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 useful behavior beyond that: results are live quotes from every insurer, ordered cheapest first, priced in Toman for the whole term, and require no personal data.

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 compact sentences, front-loaded with the outcome (live prices, cheapest first), then scope constraints, then units/ordering. No filler and no repetition of schema fields.

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 an 11-parameter quote tool with no output schema, the description covers currency, term, ordering and data requirements, and hints at the response via 'financial_coverages in the answer'. It could say more about what a quote response contains (insurer, premium breakdown), but the essential call-time information is 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 91%, so the baseline is 3, but the description adds cross-parameter meaning: previous_policy='yes' pulls in previous_company, the two policy dates and the two discounts, and previous_company must come from ins_insurers. It also notes financial_coverage is taken from the answer, which explains how to source that value.

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 ('Get live motorcycle third-party insurance prices from every insurer') and adds the output ordering ('cheapest first'). It also scopes the class explicitly ('The motorcycle class is asked directly'), which separates it from ins_vehicles and from the generic ins_quote_third_party route.

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 real selection context: 'BimeBazar only', that ins_vehicles is not needed, that ins_insurers supplies previous_company, and that no personal data is required. It stops short of an explicit when-to-use/when-not comparison against the sibling ins_quote_third_party, which is the closest alternative.

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, idempotent and non-destructive safety, and the description reinforces this with 'Nothing is bought or reserved' and 'no personal data needed'. It adds genuinely new behavioral facts: prices are live, denominated in Toman for the whole term, and returned cheapest-first, plus a privacy note about plate/national ID being prefills only. It does not discuss freshness, caching or failure modes across 17 insurers.

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 outcome and ordering, then prerequisites, then a short safety clause. Wording is dense but each sentence carries information; the parenthetical about Azki and the prefill explanation are slightly tangential but justify their place as a routing and privacy rationale.

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 14-parameter, read-only quote tool with no output schema, the definition supplies the call sequence, currency and term semantics, result ordering and a clear statement that no purchase occurs. The schema covers all field-level detail, and the schema's reference to 'financial_coverages in the answer' signals the response shape adequately.

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 each of the 14 parameters, including the enum and discount ranges, is documented inline. The description adds only the sourcing hint for brand/model and previous_company values, which the schema already states, so it does not meaningfully extend parameter meaning beyond the structured fields. 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 verb and resource ('Get live third-party car insurance prices') plus scope ('from every insurer BimeBazar sells') and ordering ('cheapest first'). This is clearly distinguishable from siblings like ins_quote_car_body and ins_quote_motorcycle without opening any 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 prerequisites: call ins_vehicles first for brand/model values and ins_insurers for a previous_company, establishing call order. It also explains why BimeBazar rather than Azki (Azki gates prices behind a phone number). It stops short of naming when to pick a sibling quote tool instead, so it is clear context rather than full when/when-not routing.

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, open-world and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: no personal data is sent, results are sorted cheapest first per provider, and the two providers return different field sets with Azki's price unit unconfirmed. That unit caveat is valuable but also slightly hedged ("on the same scale... in a live check"), 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?

Front-loads the one-line purpose, then provider-specific return fields, then constraints — a sensible order. It is dense but most sentences carry payload; the parenthetical about Azki's price unit is the only passage that sprawls.

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 12 parameters, no output schema, and a two-provider merge, the description does the heavy lifting: it enumerates the returned fields per provider and flags the age ceiling and the data-privacy posture. What remains thin is guidance on how per-provider lists are combined or capped when limit is set, which an agent may want to know.

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 schema itself already documents destinations (Persian preferred), the duration_days bucket meaning, and which age bands are BimeBazar-only. The description adds the useful framing that counts are per age band and at least one traveller is required, but leaves several age-band parameters to the schema and says nothing about how limit interacts with the provider filter.

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 travel insurance prices from BimeBazar and Azki for the same trip), plus ordering (cheapest first per provider). The travel-insurance scope cleanly separates it from the sibling quote tools for motor, health, fire and third-party.

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 one-call way to compare the two marketplaces" tells the agent to prefer this over per-provider calls, and it notes that country names and trip length are resolved internally so no ids are needed. It also states a real eligibility constraint (Azki insures up to age 85 only). It stops short of naming which sibling quote tool to use for other product lines or when to fall back to a single-provider call.

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, so credit is for the added context: the two providers use different identifier schemes (string `value` slugs vs numeric ids) and each feeds a different tool, and years are Jalali. Not fully 5 because it does not say how large the catalog is, whether results are truncated, or roughly how the response is shaped.

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 with the critical 'call this first' instruction front-loaded, followed by provider-to-tool mapping and the query branch. No filler and no repetition of the schema text verbatim.

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 adequately: brands-only versus brands-plus-models, plus identifier types per provider. It stops short of describing the actual result fields, which an agent must discover by calling.

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 above that by tying the identifier format produced to the parameters that consume them downstream and by restating the omitted-query branch. It does not add syntax guidance beyond the schema's own Persian/Latin 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?

States a specific verb and resource ('find brand and model identifiers') and scopes it to two named catalogs, 'BimeBazar's and Azki's', side by side. This immediately distinguishes it from every sibling, which are quote/content/insurer tools, and no schema opening is needed to understand what it returns.

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 ordering instruction ('Call this before any vehicle tool') plus named downstream consumers: ins_quote_third_party and ins_quote_car_body for BimeBazar values, ins_azki_car_value for Azki ids. It also explains the branch behavior: no query lists brands only, a query returns matching brands and their models.

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