BilYe

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context — results are scoped to today and ranked by cross-platform price gap for a given district/neighborhood — but says nothing about result count, ordering guarantees, or how often the ranking refreshes.

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 the resource, the scoping condition, and the ranking criterion, plus a short clarifying parenthetical. No redundant or filler wording.

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 list tool with full schema coverage and no output schema, the description covers the essentials. It is still thin on what the list actually contains — item count, whether savings are absolute or percentage, and ordering — which an agent would want before selecting this over a comparison 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 description coverage is 100%, so both parameters (ilce, mahalle) are already documented, including the name-or-slug flexibility and the effect of mahalle on price and delivery. The description merely echoes the district/neighborhood scoping, adding no new syntax or format detail beyond the schema; 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?

The description names a specific resource (products with the largest cross-platform price gap today) and its scope (district/neighborhood), plus a parenthetical that it mirrors the site's home-page list. That distinguishes it reasonably from siblings like urun_karsilastir or hangi_uygulama_ucuz, but it never names an alternative explicitly, so it stops short of full sibling differentiation.

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: an agent can infer this is a discovery/browse tool for today's biggest savings. There is no statement of when to prefer it over urun_karsilastir (single-product comparison) or hangi_uygulama_ucuz (which app is cheaper), and no exclusions or prerequisites beyond the district requirement.

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 closed-world, so the safety profile is fully covered. The description adds genuine value by saying what the document contains (per-platform total, delivery fee included when known) and that a report variant may be returned. It still does not explain the 'rapor' case or the shape of the price data, so it improves on annotations without fully characterizing the result.

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 sentence with no filler, and it front-loads the key qualifier (the id comes from search). The phrasing around 'platform platform' and the dangling 'ya da rapor' is slightly awkward 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 one-parameter read tool with no output schema and fully covered annotations, the description plus structured fields are close to sufficient. However, the undefined 'rapor' return variant and the absence of any hint about how the per-platform price data is arranged leave a real gap in the response description.

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 id parameter is already documented as 'the id from the search result, as-is'. The description reinforces this but adds no syntax, format, or edge-case meaning 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?

The description identifies a concrete verb+resource pair (fetch the full text of the document whose id came from search) and even previews the payload: per-platform total price including delivery, or a report. It is distinguishable from the search sibling because it explicitly consumes a search-returned id. The only fuzziness is the unexplained 'rapor' alternative, which leaves the second possible return type ambiguous.

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 implied by the phrase 'search sonucundaki' — the agent is meant to call search first and then pass the returned id here. There is no explicit statement of when not to use it or which sibling handles the same information (e.g., urun_karsilastir, hangi_uygulama_ucuz), so the agent has to infer sequencing and boundaries.

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, openWorldHint=false), so the description only needs to add context. It contributes the aggregation semantics and the 'tarihli' (dated) hint that results are time-bound, but says nothing about how fresh the data is, whether it is a cached snapshot, or how the frequency is computed.

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 compact sentence with the scope stated up front and no filler. The parenthetical placement of the district breakdown makes it slightly less readable but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must convey the return shape; 'ne sıklıkla en ucuz çıktığı' implies frequency/ranking figures, which is reasonable but leaves the exact structure and the length of the comparison period unspecified. For a read-only, single-optional-param tool this is adequate but not 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 coverage is 100% and the single optional 'ilce' parameter is documented in the schema as restricting to one district. The description's 'İstanbul geneli ve ilçe ilçe' adds the useful counterpart — that omitting the parameter yields the Istanbul-wide answer — but nothing beyond that 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 resource and metric: how often each platform comes out cheapest, broken down Istanbul-wide and by district, with dates. This distinguishes it from sepet_karsilastir and urun_karsilastir, which compare single baskets/products rather than aggregate win-frequency. The only weakness is 'bugünkü karşılaştırmalarda', which is vague about the window being summarized.

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 aggregation framing suggests using this for 'which app is generally cheapest' questions rather than a concrete price check. It never explicitly says when to prefer this over the sibling comparison tools or when not to use it, so the agent must infer the 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 readOnlyHint, idempotentHint, non-destructive, and a closed-world hint, so the safety profile is covered. The description adds genuine context beyond that: the results are limited to the Istanbul districts BilYe actually price-compares, and the output changes shape depending on whether 'ilce' is supplied. It does not describe ordering or formatting of the returned list.

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 essentially one sentence with three tight clauses: the default listing, the parameterized mode, and the use case. The dual-mode behavior is front-loaded and nothing is redundant. The semicolon-joined structure is dense but still readable.

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 full annotation coverage and no output schema, the description tells the agent what comes back (districts or neighborhoods) and when to call it. It leaves minor gaps, such as handling of an unrecognized district name and result ordering, that may matter for error recovery.

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 optional parameter already documents that supplying it lists that district's neighborhoods. The description restates the same fact rather than adding new meaning such as accepted name formats, case sensitivity, or behavior for an unsupported district. 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 states a specific verb ('listeler') and resource ('İstanbul ilçeleri' / 'mahalleler'), and it spells out both operating modes: no argument returns the price-comparable districts, while an 'ilce' argument returns that district's neighborhoods. This separates it cleanly from the sibling 'konumdan_ilce', which starts from a known location.

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 names the situation that selects this tool: telling a user whose location is unknown which districts are supported. That is a concrete when-to-use condition. It stops short of explicitly naming alternative tools or stating when not to call it, so it is clear but not fully routed.

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=false, so safety and determinism are covered. The description adds the useful fact that results mix platform-wide and restaurant-specific campaigns, but omits whether results are limited to today (as the title implies) or how they are ordered/filtered by validity.

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 a clarifying example — nothing wasted. It is perhaps over-lean for the amount of missing guidance, but the structure itself is clean.

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 two fully documented parameters and rich annotations, the core is covered, but there is no output schema and the description does not indicate what a campaign entry looks like or whether only currently valid campaigns are returned. Adequate, with a clear gap around return content and time scope.

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%: 'ilce' is documented as accepting a district name or slug, and 'mahalle' as an optional neighbourhood that localizes price and delivery. The description contributes nothing beyond this, 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?

The description names the resource ('kampanyalar') and its scope precisely: district-level platform-wide campaigns plus restaurant campaigns, with a concrete example ('700 TL üstü ücretsiz teslimat'). This makes the content distinguishable from price-comparison siblings, though it never explicitly contrasts itself with tools like en_cok_tasarruf or hangi_uygulama_ucuz.

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 when-to-use guidance: it does not say whether to call this before or instead of the savings/comparison tools, nor does it state any precondition. The only usage signal is implicit in the word 'İlçedeki', leaving the agent to infer 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds one genuinely useful behavioral fact — it depends on the user having shared a location — but says nothing about what happens when the coordinates fall outside the service area or what the call returns on failure.

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, front-loaded with the input-to-output mapping with no filler. Its brevity is efficient rather than cryptic, though the parenthetical precondition could have been phrased more crisply.

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, non-destructive lookup with a fully documented schema and no output schema, this is close to sufficient. The gap is behavioral edge cases: coordinates outside coverage, and whether the result is a single district/neighborhood pair or a list, are left unaddressed.

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 both parameters carry their own examples in decimal degrees. The description merely names the same two inputs without adding format, range, or precision guidance, so the schema is doing all the work — the 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 states a specific verb (bulur/find) and specific resources (ilçe ve mahalle) derived from a specific input (enlem/boylam), so the operation is unambiguous. It does not, however, distinguish this reverse-geocoding tool from the sibling 'ilceler' or explain how they differ, so it stops 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?

The parenthetical '(kullanıcı konumunu paylaştıysa)' implies a precondition — the user must have shared their location — which is real usage context. But there is no explicit when-to-use versus 'ilceler' or the other location-adjacent siblings, leaving the choice to inference.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral note that results are ranked by popularity and limited to multi-platform-comparable restaurants, but says nothing about result volume, pagination, or what happens when no restaurants match.

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 dense sentence with no filler, and the listing behavior plus the optional dish narrowing are front-loaded. It is compact enough that the 'birden çok platformda karşılaştırılabilen' qualifier takes a moment to parse, 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 read-only, three-parameter list tool with full schema coverage and no output schema, the description covers purpose, ranking, and the dish filter adequately. Only edge-case behavior (empty results, result limits) is absent, which is minor here.

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 all three parameters are already documented, including that mahalle adjusts price and delivery scoping. The description only restates the optional dish filter with an example ('pizza') and adds no syntax or format detail 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?

The description gives a specific verb and resource ('restoranları ... listeler') plus a distinguishing scope: only restaurants comparable across multiple platforms, sorted by popularity. That differentiates it from siblings like yemek_ara or search, though it doesn't name those alternatives 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 implied rather than stated: use it for a district/neighborhood restaurant listing and optionally narrow by dish. There is no explicit 'use X instead when...' routing guidance against yemek_ara, urun_karsilastir, or fetch, so the agent must infer the boundary.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail about in-menu searching and the sirala ordering semantics, but does not describe what the result looks like (per-platform price rows) or any coverage limits such as which platforms are included.

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 compact sentence with the purpose front-loaded, then the two optional modifiers. The telegraphic 'sirala=fiyat en ucuzdan, kazanc en çok tasarruftan' phrasing is dense but wastes no words; no filler or redundant restatement of the 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?

For a five-parameter read-only listing tool with full schema coverage and annotations, the description covers purpose, in-menu search and ordering. The only material gap is that no output schema exists, so the shape of the returned menu (item rows with per-platform prices) is only hinted at by 'platform fiyatlarıyla'.

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 every parameter, including the full enum explanation for sirala. The description merely restates the sirala behavior ('fiyat en ucuzdan, kazanc en çok tasarruftan') and the ara behavior, adding no meaning beyond the structured fields, and never touches zincir, ilce or mahalle. Baseline 3 is appropriate when the schema does the work.

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 and resource: 'Bir restoranın menüsünü ... verir' (returns a restaurant's menu), scoped to platform prices, which separates it from price-comparison siblings like urun_karsilastir. It does not explicitly contrast with siblings such as yemek_ara or restoranlar, so an agent must infer the boundary from the name and scope 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?

Usage is only implied: the required zincir/ilce pairing signals 'fetch the menu for a chain in a district', and 'ara ile menüde arar' tells the agent how to narrow within a menu. There is no explicit guidance on when to pick this over yemek_ara (item search) or urun_karsilastir (item comparison), and no stated prerequisites beyond what the schema implies.

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, closed-world behavior, and the description adds genuinely new context: results are opaque identifiers that must be resolved with fetch, and behavior degrades to a generic report when no district is supplied. It does not mention result counts, ranking, or pagination, keeping it short of 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, each front-loaded with a distinct fact: what it searches, how results are consumed, and the fallback. No filler or restated 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 correctly fills the gap by explaining that results are IDs resolved via fetch and what happens without a district. Sufficient to call the tool correctly, with only sibling routing left unspecified.

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 already documents the single query parameter, but the description adds the hard requirement that a district name be present and shows the accepted ordering of terms, which is meaning the schema only implies. That is a real increment over the structured field.

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: free-text search for food prices, with the constraint that the query must contain a district name. That scope distinguishes it from fetch/ilceler/konumdan_ilce, but it never contrasts itself with the close sibling yemek_ara, so an agent must guess which search path to take.

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 the required query shape with two literal examples and explains the follow-up step (results are IDs opened via fetch) plus the no-district fallback to a general cheapness report. Explicit and actionable, though it does not say when to prefer this over yemek_ara or urun_karsilastir.

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 read-only, idempotent, non-destructive, closed-world behavior, so the description's burden is lower. It nonetheless contributes real information beyond them: the computed figure bundles delivery fee when known, public campaign discounts, and minimum-basket rules, and the parenthetical 'teslimat ücreti biliniyorsa' warns that results may be partial. It does not disclose what the response looks like or how platforms are ranked.

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 dense sentence with no filler, and the core object (the per-platform payable total) is front-loaded. The stacked parentheticals make it harder to parse than necessary, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four fully documented parameters and annotations covering the safety profile, the main missing piece is what the tool returns — since there is no output schema, an agent cannot know whether it gets per-platform totals, a ranked list, or a savings delta, and the description does not fill that gap. It also doesn't say how unknown delivery fees affect the comparison.

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 zincir, ilce, mahalle, and the nested urun/adet fields with concrete examples. The description only adds the constraint that all urunler must come from the same restaurant, which is useful but largely a restatement of what the per-parameter text implies. Baseline of 3 is appropriate.

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-and-resource pair ('sepetin ... her platformda ödenecek tutarı') and scopes it to a multi-item basket from a single restaurant, which implicitly separates it from the single-item sibling urun_karsilastir. It never names an alternative tool explicitly, so the differentiation is inferred rather than stated.

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: 'birden çok ürünlük sepet' hints that this is the multi-item counterpart to a single-product comparison, and 'aynı restorandan' hints at the input constraint. There is no explicit when-to-use or when-not-to-use statement, and no routing to hangi_uygulama_ucuz or urun_karsilastir for the cases this tool does not cover.

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, and destructiveHint=false, so safety is covered. Beyond that, the description discloses return payload contents — per-platform total, campaign, branch open/closed, minimum cart, platform link, and the literal 'bilinmiyor' marker when a delivery fee is unknown — which meaningfully compensates for the absent 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?

One dense but front-loaded sentence that leads with the core deliverable (total payable amount), then enumerates secondary return fields and input provenance. It is efficient, though the run-on structure packs multiple distinct ideas without separation, making it slightly harder to parse.

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 burden of describing results and does so by enumerating returned fields and the unknown-fee convention. What remains unstated — behavior when a chain has no branch in the given district, or geographic limits implied by the 'ilce' parameter — is minor for a read-only price lookup.

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 parameter already documents its source and format (e.g. urun as "menu|whopper" from yemek_ara/restoran_menusu output). The description's note about zincir and urun provenance largely restates what the schema says, and it says nothing about the optional 'mahalle' locality parameter, so it adds little beyond structured data.

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 comparison operation on a clearly bounded resource: the TOTAL payable amount for a single product across all platforms, explicitly including product price plus delivery fee. That scope separates it in spirit from sibling tools like sepet_karsilastir (cart) and hangi_uygulama_ucuz (which app is cheaper), though it never names a sibling to make the contrast explicit.

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 a valuable chaining prerequisite — the 'zincir' and 'urun' values must come from yemek_ara or restoran_menusu output — which tells the agent how to obtain valid inputs. However, it offers no explicit when-to-use versus when-not-to-use guidance against the sibling comparison tools, so the agent must infer the choice between single-product, cart, and savings comparisons.

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 only say read-only/idempotent; the description goes far beyond by defining what the returned price actually means — single-item price with any public basket campaign already deducted, delivery included when known, otherwise flagged as 'teslimat hariç'. That pricing semantics is essential to interpreting results and is nowhere in the structured fields.

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?

Purpose and output shape are front-loaded in the first sentence, followed by pricing caveats and then sibling routing — a sensible order. It is dense and somewhat long, but essentially every clause carries non-obvious information; only minor tightening would help.

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 search tool with no output schema, the description sufficiently explains what comes back (per-platform prices, cheapest, delivery annotation) and how pricing is computed. It does not cover edge cases such as no results or the adet cap of 20, but those are minor against the richness delivered.

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 all five parameters (yemek, ilce, mahalle, adet, sirala) are already documented in the schema, including the enum meanings. The description adds no syntax, format, or default guidance beyond what the schema 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?

Opens with a concrete verb and resource in the very first clause ('Bir yemeği ... ilçede/mahallede arar') and immediately states the output shape: per-platform price plus the cheapest option. It also names the sibling tools it is not (urun_karsilastir, sepet_karsilastir), so an agent can route 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?

Explicitly routes to alternatives with the condition that selects them: urun_karsilastir when the caller needs product and delivery broken out, sepet_karsilastir for multiple quantities or multiple products. It even explains the campaign arithmetic difference (applied once per basket, not quantity × card price), which is exactly the kind of when-to-use distinction an agent needs.

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