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

Annotations already carry readOnlyHint=true and openWorldHint=true, so the safety and open-world profile are covered. The description adds that this searches across multiple CKAN portals and specific metadata fields, but it does not discuss response behavior, pagination, or portal-specific quirks.

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 description is compact and front-loaded with the core action, and the bilingual wording improves accessibility. The Turkish and English sentences are partly redundant, but the downstream-call sentence earns its place and the overall length is appropriate.

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 search tool with a full input schema, annotations, and an output schema, the description covers the supported portals, searchable fields, and the follow-up action. It does not need to explain return values in detail because an output schema exists; no critical calling information 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 coverage is 100%, so all parameters are already documented; the description adds useful semantics for `sorgu` by enumerating the searchable fields (başlık, açıklama, kurum, etiketler, dosya biçimleri). It also ties the result field `ad` to the next tool, clarifying how search results should be consumed.

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-resource pair ('veri seti arar' / 'search datasets') and scopes the action to four named municipal portals and the CKAN platform. It also enumerates the searchable metadata fields (title, description, institution, tags, file formats), and the downstream reference to acikveri_veriseti distinguishes this search step from dataset retrieval.

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 instruction 'Sonuçtaki `ad` ile acikveri_veriseti çağrılır' tells the agent what to do after a successful search, routing it to the sibling dataset-detail tool. It clearly names the supported portals, but does not give explicit conditions for when not to use this tool or compare it against sibling acikveri_kayitlar.

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 and openWorldHint=true, and the description adds useful behavioral details: optional full-text filtering, pagination via limit/offset for large tables, and the fact that the total row count is included in the response. This goes beyond the annotations without contradicting them.

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 description is compact and front-loads the core function in the first sentence, then adds pagination guidance. The Turkish and English phrasing overlap slightly, but the English sentence clarifies the CKAN DataStore nature for a broader audience without adding significant noise.

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

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

Given the output schema, annotations, and 100% parameter coverage, the description is reasonably complete. It covers the key operational concerns: filtering, pagination, and total row count. It could mention the prerequisite of obtaining a resource id from acikveri_veriseti more explicitly, but the parenthetical path already hints at this workflow.

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 all five parameters. The description reinforces the role of limit, offset, and filtre in context (large tables and full-text search) but does not need to compensate for missing parameter documentation.

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 clearly states the tool reads columns and rows from a CKAN DataStore resource that is part of an open dataset, with optional full-text filtering. It references the parent resource path (acikveri_veriseti → kaynaklar → tabloServisi=true), which helps distinguish it from dataset-level tools, though it does not explicitly name a sibling alternative.

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 implies the tool is for retrieving DataStore table rows and gives practical advice for large tables (use limit and offset, total row count is in the response). However, it does not explicitly state when to prefer this tool over siblings like acikveri_ara or acikveri_veriseti, nor does it provide exclusions.

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 and openWorldHint=true, so the read-only, open-world behavior is covered. The description adds useful context about what is returned and that open DataStore resources are handled by another tool, but it does not disclose additional behavioral traits such as pagination, portal-specific quirks, or failure modes.

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 description is short and front-loaded, with the most important result contents stated first. There is some bilingual redundancy between the Turkish and English sentences, but the English sentence adds the useful 'municipal CKAN portal' context and the final sentence earns its place by routing to a sibling tool.

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

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

Given that the input schema is fully documented and an output schema exists, the description is reasonably complete. It covers what the tool returns, the CKAN context, and the boundary with acikveri_kayitlar for row-level data. It could be stronger with explicit when-to-use guidance, but nothing essential for selecting and invoking the tool 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%, so the input schema already documents both `ad` and `portal` clearly, including the enum values for `portal`. The description itself adds no parameter-level meaning beyond what the schema provides, so the 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 clearly identifies the resource: a dataset's description, license, and files/resources, including format, download link, and DataStore status. It does not use an explicit action verb, but it is specific and distinct enough from the sibling tools, especially by pointing row-level access to acikveri_kayitlar.

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 implies the main use case (metadata/resource details) and explicitly routes table-service-enabled resources to acikveri_kayitlar for row-by-row reading. However, it does not explicitly state when this tool should be preferred over acikveri_ara or what preconditions exist beyond the schema hint that `ad` comes from acikveri_ara.

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 readOnlyHint=true, covering the safety profile. The description adds valuable behavioral context beyond that: the results are sorted newest to oldest, and defaults (last 7 days, magnitude ≥3.0, max 50 records) are stated. This enriches the agent's understanding of what to expect without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat verbose and redundant, mixing Turkish and English with a near-duplicate English translation of the opening clause. The core information is present but could be tightened into a single clean sentence without losing meaning. It is not tightly structured or front-loaded.

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

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

For a read-only, optional-parameter query tool with an output schema, the description provides the essential context: data source (AFAD catalogue), fields returned (magnitude, depth, location, province/district), sorting (newest first), and defaults. Nothing critical for correct invocation is missing, and the output schema handles return-value expectations.

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%—every parameter (bitis, limit, baslangic, minBuyukluk) has a clear description with defaults. The tool description repeats these defaults but adds no new semantic detail beyond what the schema already provides. With full schema coverage, baseline 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 clearly states the tool lists earthquakes from AFAD's catalogue within a date range, including magnitude, depth, location, and province/district, and specifies sorting order. This is a specific verb-resource combination that fully distinguishes it from all sibling tools, none of which relate to earthquakes.

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?

While no explicit alternatives are named, the tool's unique purpose among siblings (all unrelated: currency, weather, fuel, holidays, ID verification, plate lookup) makes its usage self-evident. The description clearly implies when to use it—when earthquake data from AFAD is needed—and there are no competing tools requiring exclusions.

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 and openWorldHint, and the description adds meaningful behavioral context on top: data is end-of-day rather than live, it originates from a single broker (a source-reliability caveat), and the default window is 30 days. No statement contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The entry is compact and front-loaded, packing purpose, field list, behavioral caveats, and default range into a single paragraph. The bilingual Turkish/English restatement is mildly redundant but serves multilingual agents, and no sentence 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?

With an output schema present and annotations covering the read-only safety profile, the description covers the remaining gaps an agent needs: default range, data freshness, and source limitation. Minor niceties like symbol casing are already handled by the schema's kod examples.

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 kod, bitis, and baslangic with formats, examples, and defaults. The description merely confirms the default 30-day range already stated in the schema; it adds no new parameter 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 names a precise operation: retrieving daily end-of-day prices for a specific Borsa İstanbul stock (kod). It enumerates exact return fields (close, weighted average, intraday low/high, TL volume, market value, plus the same day's BIST 100 close and USD/TRY rate), making the tool's scope unmistakable. No sibling tool covers stock price history, so it is clearly distinguishable from the rest.

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 conveys useful context — data is end-of-day, not real-time, and reflects a single brokerage's publication — which sets expectations about when this tool is appropriate. However, it stops short of naming alternatives or giving explicit when-to-use/when-not-to-use conditions; the 'not real-time' note is the only implicit exclusion.

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 and openWorldHint, and the description adds useful behavior: live data, BtcTurk as the single source, default asset selection, available fields, and a non-advice disclaimer. It does not mention rate limits or invalid-symbol behavior, but for a read-only data query these gaps are minor.

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 description is compact and front-loaded with the core purpose and key data fields, followed by parameter guidance and a disclaimer. The bilingual repetition is mild and does not prevent an agent from quickly parsing the important 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 read-only market data tool with an output schema, the description sufficiently covers source, asset universe, returned fields, symbol syntax, and default behavior. Minor omissions like explicit `limit` semantics and the optional USDT pair are inferable from the schema parameter names/enum.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the schema for `varlik`, giving concrete examples like BTC, ETH and comma-separated symbols, plus the fallback default. The schema already documents `paraBirimi` and `limit` bounds, so the description does not need to repeat them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (crypto prices from BtcTurk), a clear scope (180+ assets, TL prices, live), and enumerates the included data fields such as last trade, bid/ask, daily open, low/high, volume, and change. This makes it distinguishable from sibling tools focused on FX, stocks, or government data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it is a live crypto price feed from a single exchange, BtcTurk, and explains default behavior when `varlik` is omitted (first 30 pairs by volume). It does not explicitly name sibling alternatives to exclude, but the intended use is evident.

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, so the description correctly aligns by stating it does not modify anything. It adds the behavioral detail that it does not verify account existence, which is useful. However, it does not disclose what happens with invalid IBANs (e.g., error vs. boolean return) or the exact output format beyond extracting the bank code, despite having an output schema that might cover this.

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 description is concise, with two sentences that add value. It is front-loaded with the core action (mod-97 validation) and the offline exception. The bilingual duplication is a minor inefficiency but not harmful.

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

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

Given the tool's simplicity (one parameter, read-only, no nested objects) and presence of an output schema, the description covers the essential purpose. The only gap is lack of detail on error handling or return values, but the output schema likely explains the return structure, so what's provided is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'iban' parameter fully with format and length, so coverage is 100%. The description adds little beyond restating 'TR IBAN' and mentioning spaces are allowed, which is already in the schema. Thus, 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 clearly states it performs ISO 13616 mod-97 validation for Turkish IBANs and extracts the 5-digit bank code. While it doesn't explicitly contrast with sibling tools, its purpose is specific and unambiguous among the listed tools, which are unrelated (currency rates, earthquakes, weather, etc.).

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 mentions it is offline and does not verify account existence, implying when to use it (format-only check) versus a tool that would verify account existence. However, it does not explicitly state when to use this over alternatives, as there is no direct sibling for IBAN validation. The context signals (openWorldHint=false) align with the offline claim, but explicit guidance is minimal.

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 description adds significant behavioral context beyond the annotations. It states the tool is fully offline and sends the number nowhere, addressing privacy concerns. It also clarifies that it only validates format, not actual identity, which is a key behavioral trait. This is useful context beyond the readOnlyHint annotation.

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 description is concise with three sentences, each providing essential information. The key purpose is front-loaded, and safety/limitation notes are efficient. No redundancy or filler words.

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

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

Given the tool's low complexity (single parameter, simple validation), the description is complete. It covers the validation logic, constraints, behavior, and limitations. The output schema exists, so return values do not need to be described. The tool is a straightforward utility, and everything an agent needs to call it correctly 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?

The schema already describes the parameter tckn as '11 haneli numara' (11-digit number), so the description doesn't need to repeat it. However, the description does add context like the first digit cannot be zero and the checksum validation, which gives more meaning to the parameter. Since schema coverage is 100%, a baseline of 3 is appropriate, and the description adds slight 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?

The description clearly states the tool's purpose: it validates the checksum of a Turkish national ID number. It specifies the format (11 digits, first digit cannot be zero), and it distinguishes itself from validating a person's existence, which is a common alternative use case. This differentiates it from siblings like dogrula_vkn (tax ID) and dogrula_iban (IBAN) without needing to compare 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?

The description implies when to use the tool: when you need to check the format/checksum of a T.C. Kimlik Numarası. It also explicitly states when not to use it: it does not verify the person's existence, suggesting alternative usage for identity verification. However, it doesn't name specific alternatives like a lookup service, but the exclusion is clear.

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 signal read-only and closed-world behavior, and the description adds valuable operational detail: it performs no GİB lookup and does not verify taxpayer existence. This clearly discloses what the tool does and does not do, consistent with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the core function, followed by important exclusions. The English summary is slightly redundant with the Turkish text but adds accessibility for agents operating in English, so it remains appropriately concise.

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

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

For a single-parameter tool with an output schema, the description covers the essential behavioral constraints: offline operation, no existence check, and checksum-only validation. It does not describe error behavior for invalid input lengths, but the schema and simple scope make this a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description repeats the 10-digit constraint ('10 hane') and adds the Turkish tax ID context, but it does not add format constraints beyond the schema, such as digit-only or no separators.

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 and resource: it computes the checksum digit of a Turkish tax ID (VKN). It clearly distinguishes itself from online/existence-checking tools by explicitly stating 'GİB sorgusu yapılmaz, mükellefin varlığı doğrulanmaz', and the English summary reinforces the offline checksum-only scope.

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 implies usage context through its limitations: it is appropriate for offline checksum validation, not for verifying taxpayer existence. However, it does not explicitly state when to prefer this tool over siblings like dogrula_tckn or dogrula_iban, nor does it name alternatives.

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?

Beyond the readOnlyHint annotation, the description discloses the response contents (latest value, date, series code, formula), the default date range, the EVDS limit of 150 observations, and the EVDS_API_KEY requirement. This is substantial behavioral context that helps the agent set expectations.

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 description is dense and front-loaded with the indicator list, and every sentence adds useful information. The bilingual repetition is slightly redundant but does not obscure the meaning.

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

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

The description is complete for a simple read-only lookup tool: it covers selection, defaults, limits, auth, and response contents. With an output schema present and no nested complexity, nothing essential 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?

The schema already documents all three parameters with full coverage and an enum for gosterge. The description repeats the enum values and adds the 'by name' framing, but does not need to compensate for any schema gap, so the baseline 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 clearly states the tool returns Turkey's headline economic indicators by name, without requiring a series code. It lists the exact indicators and explicitly distinguishes itself from the EVDS code-based sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'seri kodu bilmeden, adıyla' makes clear this is the tool to use for common indicators when the user does not know EVDS series codes. It does not explicitly name an alternative tool, but the usage context is clear and the sibling tools make the intended contrast obvious.

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 and openWorldHint=true. The description adds a useful behavioral constraint beyond annotations: EVDS_API_KEY is required. It also communicates the hierarchical/tree nature and the fields returned, which is meaningful context for a zero-parameter tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loads the core topic tree information before the workflow pointer and API-key note. The bilingual repetition is mild redundancy but does not obscure the content.

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 no-parameter, read-only, output-schema-backed tool, the description supplies all essential context: resource identity, fields, workflow position, and auth requirement. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is 100% by definition, so the description cannot add parameter-level detail. Per the baseline for no-parameter tools, this is satisfactory; it does not mislead.

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 clearly identifies the resource: the topic tree of TCMB EVDS statistics categories, and enumerates returned fields (id, name, level, parent). It lacks an explicit verb like 'get/list', but the noun phrase and zero-parameter schema make the operation obvious, and it is distinguishable from sibling evds_veri_gruplari.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear workflow signal: after fetching categories, the next step is evds_veri_gruplari. It also states the API key prerequisite. It does not explicitly say when not to use it or name alternatives, but for a zero-parameter tree endpoint this is adequate 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a notable truncation behavior — at most 150 observations counted back from the end — plus the need to paginate for longer ranges, the 365-day default window, and the EVDS_API_KEY requirement. These are exactly the behavioral quirks annotations do not convey.

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 is front-loaded and every clause earns its place — examples, limit, default, and auth are all load-bearing. The Turkish/English repetition of the core purpose is mildly redundant but acceptable for a mixed-language audience.

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

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

With an output schema present and annotations covering the safety profile, the description covers the remaining operational essentials: auth, result limit, default range, and pagination strategy. The only notable gap is not clarifying how evds_seri differs from evds_seriler for an agent deciding which to call.

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% with rich per-parameter descriptions, so the baseline is 3. The description adds real-world value: concrete series codes (TP.DK.USD.S.YTL, TP.DK.EUR.S.YTL, TP.TUKFIY2025.GENEL) and a mapping hint (formul=3 gives yıllık enflasyon %), giving the agent ready-to-use parameter combinations.

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 action: fetching observations of one or more series from TCMB EVDS ('bir ya da birkaç serinin gözlemleri'). The example codes and 'Time-series observations' reinforce the data-retrieval purpose, clearly distinguishing it from siblings like evds_kategoriler (categories) and evds_seriler (series metadata).

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 provides operational guidance (150-observation cap, pagination advice, default 365-day range) but never says when to prefer evds_seri over the near-namesake evds_seriler or evds_gosterge. An agent must infer usage from the broader EVDS sibling group rather than being explicitly 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 cover read-only and open-world behavior, so the bar is lower. The description adds useful behavioral context: it returns series code, name, frequency, and labels, supports optional name filtering, and explicitly warns that EVDS_API_KEY is required. This goes beyond the structured annotations without contradicting them.

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 description is compact and front-loaded with the main purpose, followed by a useful concrete example and auth requirement. The Turkish/English bilingual repetition adds slight redundancy, but the overall length is reasonable and every substantive point earns its place.

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

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

For a list tool with a full output schema and read-only annotations, the description is largely complete: it names the returned fields, the optional filter, the required API key, and provides an example. It does not explain pagination details, but the schema covers the limit parameter and the output schema covers return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does add meaning by explaining that optional ad filtering corresponds to the 'ara' parameter and by giving a concrete example group/series mapping, but it does not add substantial parameter semantics beyond what the schema already documents.

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 action and resource: listing the series contained in a single EVDS data group, including code, name, frequency, and labels. It also hints at differentiation from the sibling evds_seri by noting the series code is what evds_seri needs, so an agent can distinguish the plural list tool from the singular lookup tool.

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 context is clear: use this when you need the series available within a specific EVDS data group, optionally filtered by name. It points to evds_seri by mentioning 'evds_seri için', but it does not explicitly state conditions such as 'use evds_seri when you already have a series code'.

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?

With readOnlyHint and openWorldHint already present, the description adds relevant context: an API key is required and the tool operates on a single EVDS category rather than the whole dataset. No contradiction with annotations, though failure behavior for invalid category ids is not disclosed.

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 description is compact and front-loads the main purpose, with concrete examples and a clear next-step pointer. The English sentence partially duplicates the Turkish opening, but the overall size is appropriate and scannable.

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 simple one-parameter read tool with an output schema, the description covers what is returned, the required API key, the source of the input id, and the follow-up tool. Minor edge-case behavior is unspecified, but the agent has enough to invoke it 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 coverage is 100%, so the schema already documents kategoriId as the id from the evds_kategoriler output. The description does not add meaningful parameter-level detail beyond that, so it stays at 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 identifies a specific resource: data groups within one EVDS category, and lists the returned fields with concrete examples such as 'bie_dkdovytl = Döviz Kurları' and 'bie_tukfiy2025 = TÜFE 2025=100'. It is clear enough to distinguish from evds_kategoriler and evds_seriler, though it lacks an explicit verb like 'list' or 'get'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful workflow context: the kategoriId comes from evds_kategoriler output and the next step is evds_seriler. It also states the EVDS_API_KEY prerequisite. However, it does not explicitly say when not to use this tool versus its siblings.

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 and openWorldHint, and the description adds meaningful context: data comes from an RSS feed, full article text requires following the link, and headlines are the publisher's expression. This goes beyond the annotations by explaining the source behavior and the need to fetch article content externally, with no contradiction.

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 description is compact and front-loaded with the core purpose, then covers parameter details efficiently. The English translation partly repeats the Turkish first sentence, which is mild redundancy, but overall every section earns its place.

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

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

For a read-only headline-listing tool with an output schema, the description is complete: it covers all parameters, source-specific categories, defaults, filtering, and how to obtain full article text. No critical missing information prevents correct 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 only 50%, but the description compensates by fully specifying `kaynak` values, complete `kategori` lists per source, `ara` as a title/summary filter, and `limit` defaulting to 20. This is substantial added meaning beyond the sparse input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: retrieving latest headlines from AA or TRT RSS feeds, with title, summary, link, and publication time. It is clearly differentiated from sibling tools like kandilli_depremler or resmi_gazete_fihrist because it explicitly names its news sources and content fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on source and category selection, including the full category list for each source and the default source/category. It does not name alternatives or explicitly state when not to use it, but the context is clear enough for an agent to select the tool appropriately.

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 provide readOnlyHint and openWorldHint, but the description adds valuable behavioral context beyond that: it mentions the data source (web service), specifies the conditional behavior on the parameter, and states the units (µg/m³, CO mg/m³). This is meaningful disclosure beyond the structured fields, with no contradiction.

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 description is bilingual and moderately detailed, but not excessively long. It front-loads the core information (what data it returns) and each sentence adds substantive detail (parameter behavior, units). The bilingual repetition is slightly redundant but does not undermine clarity, so it earns a 4 rather than a 5.

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

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

Given the tool's low complexity (one optional parameter) and the existence of an output schema, the description provides sufficient context: it explains the parameter modes, data source, and units. No critical information is missing for an agent to call the tool correctly, so a 4 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100% for the single optional parameter `istasyon`, which already says it accepts a station name or fragment. The description enriches this by clarifying the two possible response modes (all stations vs. a 24-hour series for one station), which is not evident from the schema alone. This adds real 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?

The description clearly and specifically states that the tool provides the latest air-quality readings from Istanbul's municipal monitoring stations, enumerating the pollutants (AQI, PM10, SO2, O3, NO2, CO) and noting the source (İBB Açık Veri Portalı). It establishes a distinct purpose that is unambiguously different from sibling tools like weather or earthquake services, even without explicit contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on how to use the tool, explaining that omitting the `istasyon` parameter returns all stations and providing it returns a 24-hour series for that station. However, it does not explicitly mention when to prefer this tool over alternatives or state any exclusion criteria, so it falls short of a 5.

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 and openWorldHint. The description adds valuable behavioral context by identifying the source as the İBB Open Data Portal and warning that service times can change. This helps agents avoid treating the data as immutable and clarifies the external dependency, without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact but information-dense, front-loading the resource and main outputs. The Turkish and English repetition is minor and each sentence serves a purpose: detailed field enumeration, a quick English gloss, and a source/volatility caveat. It is structured well for agent consumption.

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 simple read-only tool with one optional parameter and an existing output schema, this description is complete. It explains both invocation modes, the returned content, the data source, and the possibility that schedules may change. No essential information for correct usage 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?

The schema already covers the `hat` parameter at 100% with examples, so a baseline of 3 is appropriate. The description adds further value by giving extra example line codes (M1A, M5, F1) and by explaining the conditional behavior: supplying `hat` triggers station-level detail. This is meaningful semantic enrichment beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource as Istanbul metro lines and stations wire, and enumerates the returned fields: route name, first/last train times, active status, ordered stations, coordinates, accessibility counts, and amenities. It distinguishes itself well from the sibling tool ibb_metro_duyurular by focusing on line/station data rather than announcements.

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 implies usage: without `hat`, line-level data is returned; with `hat`, the station list for that line is provided. However, it does not explicitly state when to prefer this tool over alternatives or provide any exclusion criteria, leaving some selection judgment to the agent.

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 and openWorldHint=true, covering the safety profile. The description adds the return fields (title, full text, start date) and notes the announcements are 'current', which provides some behavioral context. However, it doesn't disclose additional behaviors like pagination or data freshness, but given the annotations, this is acceptable.

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 description is bilingual (Turkish and English), which adds redundancy but remains concise. It front-loads the key purpose and lists examples. The structure is clear and not overly verbose, though the bilingual repetition could be streamlined.

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?

The description covers the tool's purpose, content types, and return fields. An output schema exists, so the return structure is likely documented. For a simple tool with one optional parameter and read-only/open-world annotations, the description is fairly complete. However, it lacks explicit usage guidance and examples of output, but that's not critical 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?

The input schema has one parameter 'ara' with a description that fully explains it as a search fragment in title/text with an example 'M2'. Since schema description coverage is 100%, the baseline is 3. The tool description adds no additional parameter context, so it stays at 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?

The description clearly identifies the tool as providing current service announcements (disruptions, schedule changes) from Istanbul's metro operator, listing specific types (breakdowns, closed stations, night metro changes) and the content fields (title, full text, start date). It's specific about the resource and purpose, but doesn't explicitly differentiate from sibling tools like ibb_metro, so 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?

No guidance is given on when to use this tool versus alternatives. It doesn't mention any exclusions, conditions, or when to prefer a sibling tool like ibb_metro for static metro information. The description is purely informational with no usage direction.

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 mark this read-only/open-world; the description adds meaningful behavioral context beyond them: the data source (İBB Şehir Haritası's service), the fact the duty roster changes daily, and that the response carries a retrieval time. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the main result and scope. The Turkish and English sentences are near-duplicates, which introduces slight redundancy, but the overall length is justified and the key usage notes appear at the end.

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 with an output schema and read-only annotations, the description is complete: it states the city, day scope, returned fields, optional district filter, data source, and freshness/dynamic behavior. Nothing necessary to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers `ilce` with an example, and the description adds valuable filter semantics: if supplied, only that district is returned, implying omission returns all districts for Istanbul. This is useful beyond the raw parameter name and type.

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 concrete resource and scope: today's on-duty pharmacies in Istanbul, and enumerates the returned fields (name, district, address, phone, coordinates). It also identifies the source service, which distinguishes it clearly from the sibling izmir_nobetci_eczane for İzmir.

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 clearly states this is for Istanbul today and explains the optional `ilce` filter ('`ilce` verilirse yalnızca o ilçe'). It does not explicitly mention the sibling `izmir_nobetci_eczane` as the alternative for İzmir, but the city-specific wording makes the intended context 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=true and openWorldHint=true. The description adds concrete behavioral details beyond those annotations: the two sorting modes (nearest by km or most empty spaces), the default limit of 30, and that data comes from the İBB Open Data Portal's web service. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact but packed with information, front-loading the data fields before the sorting/filtering rules. It uses a single structured sentence with semicolons, which is efficient though slightly dense. No wasted words.

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

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

Given the tool has an output schema (so return format is covered) and readOnlyHint/openWorldHint annotations, the description sufficiently covers parameter behavior, sorting, filtering, and defaults. It lacks only minor details like data freshness or pagination, but these are not critical 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 83% (5 of 6 params have descriptions), so baseline is 3. The description adds meaningful semantics: explains the effect of enlem+boylam (sorting), ilce and ara (filtering), and the default for limit, which is not in the schema. This goes beyond what the schema provides.

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 clearly states the tool retrieves live occupancy data for Istanbul's İSPARK car parks, listing specific fields like empty spots, capacity, occupancy percentage, open/closed status, working hours, and coordinates. It distinguishes itself from the sibling ibb_otopark_detay by implication (this is a list/search tool), but does not explicitly name the alternative or contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains parameter-driven behavior (sorting by proximity or vacancy, filtering by district/name, default limit of 30) but does not explicitly state when to use this tool versus alternatives like ibb_otopark_detay. Usage context is implied rather than explicit.

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 and openWorldHint, so the description is not burdened with safety disclosure. It adds useful behavioral context by mentioning 'güncelleme zamanı' (update time) and 'anlık boş yer' (live empty spaces), signaling that the data may be time-sensitive. No contradiction with annotations exists.

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 description is compact and front-loaded with the key detail fields. The bilingual repetition (Turkish and English) adds slight redundancy, but both sentences are informative and the overall length is appropriate for the tool's simple scope.

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-only detail tool with a rich output schema and clear sibling relationship, the description covers everything needed to select and invoke it correctly. It names the source of the id and the expected content of the result, so no critical context 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 coverage is 100%, and the sole parameter `id` is already described as coming from the `ibb_otopark` response. The description reinforces this by saying 'by its id (from `ibb_otopark`)' but does not add new parameter-level semantics beyond what the schema provides.

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 clearly states the tool returns details of one İSPARK car park by its id, enumerating specific fields: address, hourly tariff, monthly subscription fee, update time, and live empty spaces. It distinguishes itself from the sibling `ibb_otopark` by explicitly referencing that list as the source of the id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'by its id (from `ibb_otopark`)' implies the tool should be used after obtaining an id from the list endpoint, providing clear context for when to invoke it. It does not explicitly state exclusions or alternatives, but the relationship to `ibb_otopark` is sufficient guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, read-only operation. The description adds useful behavioral context: the value is live and fetched fresh on every call, and it is a 0–100 index. This goes beyond the annotations without contradicting them.

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 description is compact and front-loaded: it states the subject, source, scale, and freshness in two short sentences. Every sentence adds value, and the bilingual phrasing is not redundant because it reinforces the meaning for different language models.

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?

The tool has no parameters and an output schema exists, so the description does not need to explain return values. It covers the key facts: what is measured, the scale, the source, and the live nature. A minor gap is that it does not state whether the value is a percentage or a raw index, but the 0–100 scale is sufficient for most use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the schema provides no parameter documentation. The description compensates by explaining what the returned value represents (0–100 index, citywide, live), which is the only semantic information an agent needs. A baseline of 4 is appropriate for a parameterless tool.

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 clearly states the tool returns Istanbul's live citywide traffic density index from the metropolitan transport centre, using a 0–100 scale. It distinguishes itself from sibling tools by naming the specific data source and metric, so an agent can tell it apart from other data-fetching tools.

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 implies this is a simple, no-parameter, live-data retrieval tool and notes it is refreshed on each call. It does not explicitly name alternatives or exclusions, but given the zero-parameter schema and unique subject matter, the usage context is clear enough.

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 and openWorldHint=false. The description adds that the lookup is 'çevrimdışı/offline' and enumerates the exact data domains returned, which is useful beyond the annotations. No destructive or auth behavior needs disclosure for this read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is compact: a Turkish field list, an English summary, and a short parameter note. There is minor bilingual redundancy, but the sentences are short and front-loaded, and each contributes either scope, field detail, or usage instruction.

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

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

Given the output schema and read-only annotations, the description covers scope (all 81 provinces), offline behavior, accepted parameter forms, and the optional district list toggle. It is sufficient for correct invocation; only minor details such as error behavior are omitted, which are not critical 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 coverage is 100%, so the baseline is 3, but the description adds concrete accepted formats ('İstanbul, izmir, 06') and clarifies the behavior of ilceler=false. This goes beyond the schema's own parameter descriptions and helps the agent pick correct inputs.

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 explicitly names the resource ('Bir ilin kimliği' / Province profile) and enumerates the fields returned: plate code, population, area, altitude, area codes, coastal/metropolitan status, region, coordinates, and district counts. It scopes the tool to 'any of Türkiye's 81 provinces', making it clearly distinguishable from siblings like iller_listesi or plaka_il.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it is an offline single-province profile lookup for any of Türkiye's 81 provinces, and it explains how to use the parameters ('il ad ya da plaka kodu', 'ilceler=false ile ilçe listesi atlanır'). It does not explicitly compare itself to sibling tools, so it stops short of a 5.

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 and openWorldHint=false, so the tool is known to be read-only with a fixed dataset. The description adds valuable behavior beyond annotations: it returns all districts with matching names, supports partial matching, works offline, and can be narrowed by province. These details help set expectations about results without conflicting with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and includes essential behavior details. It is bilingual (Turkish/English), which adds length but is arguably necessary for this audience. There is no fluff; each clause delivers information. Slightly redundant due to translation, but still concise overall.

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 lookup tool with an output schema (though not shown), the description covers purpose, usage, behavior, and parameters adequately. It explains partial matching, duplicate handling, narrowing, and offline operation. An agent has all necessary information to call this tool correctly without ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema descriptions are 100% covering, providing basic meaning for both parameters. The description goes further by clarifying that the 'ilce' parameter accepts name parts (with example 'kadi' → Kadıköy) and that the 'il' parameter narrows results. This adds semantic value beyond the schema, though not extensive.

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 clearly states the verb 'finds' and the resource: it finds which province a district belongs to, along with population and area. It distinguishes itself from sibling tools like il_bilgisi (province info) and plaka_il (plate-to-province) by focusing specifically on district lookup, including handling of duplicate district names.

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 provides clear usage context: it explains that all districts with the same name are returned and can be narrowed using the 'il' parameter, and that partial names are supported. It does not explicitly state when not to use it or name alternative tools, but the purpose is specific enough that an agent can infer when it's appropriate.

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 mark it as read-only and closed-world. The description adds 'offline' (no network required) and enumerates the exact region values for filtering, which are not in the schema. It does not contradict annotations and provides useful context about the data scope (all 81 provinces). The return format is not described, but the output schema covers that.

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 description is two sentences, front-loaded with the core functionality in Turkish and followed by a concise English summary. No unnecessary words; every part adds information (sorting keys, filter regions, offline capability). It is well-structured and easy to scan.

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 simple list tool with an output schema and fully described parameters, the description is complete. It covers sorting, filtering, the exact regions, and offline behavior. It doesn't explain return fields, but the output schema handles that. No critical information for calling the tool 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 coverage is 100% for both parameters. The description adds value by explicitly listing the enum values for sirala (nufus, yuzolcumu, plaka) and the full set of valid bolge values (Marmara, Ege, Akdeniz, etc.), which the schema only vaguely describes as 'name or part'. This makes the filtering options concrete and actionable.

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 clearly states the tool returns a list of all 81 Turkish provinces, sorted by population, area, or plate code, and optionally filtered by geographic region. This distinguishes it from siblings like il_bilgisi (specific province info) and plaka_il (plate-to-province lookup) by emphasizing the complete list with sorting/filtering.

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 implies when to use it: whenever a complete list of provinces is needed, with optional sorting/filtering. It doesn't explicitly contrast with alternatives, but the phrasing 'Türkiye'nin 81 ilinin listesi' makes the use case obvious. Sibling tools like ilce_ara or il_bilgisi serve different purposes, so the context is clear even without explicit exclusions.

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?

Beyond the readOnly/openWorld annotations, the description discloses a critical behavioral edge case: on days without a bulletin (Sunday, holidays, some fish days), it returns an empty list. It also reveals default behavior for `tur` and `tarih`, which helps the agent predict results without making a test call.

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 content is valuable, but the description is structured as a long run-on sentence, switches between Turkish and English with some redundancy, and places all parameter guidance in a dense block. A bulleted or more clearly segmented structure would make it easier for an agent to parse quickly.

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

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

With an output schema present, the description does not need to explain return structure. It covers source, scope, parameter defaults, output fields, and the empty-list case, so an agent has everything needed to invoke the tool correctly and interpret common outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema documents `ara` and `tarih` but not `tur`, and the description compensates by explaining all parameters: `tur` defaults to `sebzemeyve` or `balik`, `tarih` uses YYYY-AA-GG and defaults to today, and `ara` filters by product name. This adds default values and usage nuance beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly names the resource: a daily price bulletin from İzmir's wholesale produce and fish markets, listing product, type, unit, minimum, maximum, and average TL prices. It is specific enough to be immediately distinguished from unrelated sibling data tools, and it emphasizes that this is the only official daily food-price series.

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 makes the intended use clear: retrieve daily wholesale produce or fish prices from İzmir's metropolitan municipality. It does not explicitly list alternatives or exclusion conditions, but the uniqueness claim and clear scope provide enough contextual guidance for an agent to select it over other market/financial tools.

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 mark it read-only and open-world, and the description adds valuable context: the İzmir Büyükşehir open-data source, the 'today' scope, and an explanation of the duty note field (e.g., after 24:00). Behavior such as response ordering or absence handling is not disclosed, but with readOnlyHint and openWorldHint present this is sufficient.

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 description is compact and front-loads the main content (today's İzmir duty pharmacies) before listing fields and source. The Turkish/English duplication is slightly repetitive but does not bloat the definition materially.

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

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

With one optional parameter, a rich field list, a source note, and an existing output schema, the tool is adequately specified for correct invocation. The only notable gap is the missing explicit statement of behavior when `bolge` is omitted (presumably returning pharmacies for all districts).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers bolge with a type and example (Bornova, Karşıyaka), and the description contributes the filtering semantics ('`bolge` ile süzme'), which is not explicitly stated in the schema. Together they give the agent enough to pass the parameter correctly, though no formatting or case guidance is added.

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 the resource precisely—today's on-duty pharmacies in İzmir—and lists the returned fields (name, district, duty note, address, phone, coordinates), which makes selection easy. It lacks an explicit verb such as 'list' or 'query', and the differentiation from ibb_nobetci_eczane relies on the city name rather than an explicit comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context is provided: the tool is for today's İzmir pharmacies and supports optional district filtering via `bolge`. It does not explicitly state when not to use it or name alternatives such as ibb_nobetci_eczane, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the behavior that an empty list is returned when no buses are present, and mentions it's live data. It does not detail error handling, rate limits, or response format beyond the listed fields, so it adds moderate value but nothing beyond what annotations imply.

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 description is compact and front-loaded with the core purpose, then lists return fields, and finally provides parameter usage guidance. The bilingual repetition (Turkish and English) adds some length but is not excessive. Every sentence contributes functional information, and the structure is logical.

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?

The tool is simple with only two parameters (one required), and the description explains the required parameter's source and the return fields. Although no output schema is provided, the description enumerates the expected fields, so the agent knows what to expect. It is complete enough for a low-complexity 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%, with each parameter described in the schema ('Yalnızca bu hat' for hatNo, 'ESHOT durak numarası, örn. 21050' for durakId). The description adds extra value by telling the agent where to obtain durakId (via acikveri_ara), which is not in the schema. This elevates it above the baseline of 3 for full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Bir ESHOT durağına yaklaşan otobüsler' (live buses approaching an ESHOT stop), and lists specific fields returned (hat no ve adı, kalan durak sayısı, etc.). It identifies the resource (durakId) and the optional filter (hatNo), making it distinct from any sibling tool. The English translation reinforces clarity without ambiguity.

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 provides a key usage guideline: how to find the required durakId via `acikveri_ara` with 'eshot durak'. It also notes that an empty list is returned when no buses are waiting. However, it does not explicitly contrast with alternative tools, though no direct sibling exists for bus arrivals, so the guidance is sufficient.

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 and openWorldHint=true, so the safety profile is known. The description adds behavioral details beyond that: the data is sourced from BDTİM, sorted newest-to-oldest, has a hard 500-event publication cap, uses Turkish local time, and distinguishes preliminary vs revised solutions. It does not mention empty/error responses, but that is a minor gap given the output schema exists.

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 description is reasonably front-loaded with the main purpose and key constraints, but it repeats the same information in Turkish and English ('Boğaziçi... Rasathanesi' vs 'Kandilli Observatory', 'son depremler listesi' vs 'Latest earthquakes'). This redundancy makes it longer than necessary without adding new meaning.

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

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

For a read-only tool with simple optional parameters, an output schema, and strong annotations, the description is nearly complete: it covers data source, retention limits, defaults, timezone, ordering, and included fields. The only missing piece is an explicit pointer to the AFAD sibling for alternative data, but the 'AFAD'dan bağımsız' note already signals the relationship.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of the parameters with descriptions and defaults, so the baseline is 3. The description adds extra meaning by explaining the 500-record publication limit (which explains the limit maximum), reinforcing the defaults, and specifying that times are in Turkish time, which clarifies how sonSaat and timestamps should be interpreted.

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 clearly states a specific resource (Kandilli Observatory's latest earthquake list) and a specific action (returning/listening to earthquakes), and it differentiates itself from the sibling AFAD catalog with 'AFAD'dan bağımsız ikinci katalog.' It also enumerates the returned fields (magnitude type, depth, location, place name, preliminary/revised status) and the ordering (newest to oldest), which makes the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful context for choosing this tool: it is an independent second catalogue to AFAD, publishes only the last 500 events (usually a few days), and has clear defaults (24 hours, magnitude ≥ 3.0, max 50 records). This implies when the tool is appropriate, but it does not explicitly name a sibling alternative or state 'use this when X, use AFAD when Y,' so exclusion guidance is only implicit.

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 declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds useful behavioral context: the search covers both title and full text, returns a `kimlik` identifier for downstream calls, and provides a concrete example. It doesn't disclose pagination or result count behavior beyond the limit parameter, but the schema covers that.

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 description is compact and front-loaded with the core search capability, then the downstream workflow, then an example. The Turkish/English mix is slightly redundant but not wasteful. Every sentence earns its place.

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

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

For a read-only search tool with a rich schema and output schema, the description is complete enough. It explains the search scope, the downstream use of `kimlik`, and gives an example. It could mention result ordering or default behavior, but the schema and annotations cover the essentials.

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 all four parameters. The description adds the search-scope context (title or full text) and the example query, but doesn't add significant meaning beyond the schema. Baseline 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 clearly states the tool searches mevzuat.gov.tr by title or full text, with specific search dimensions (law number, name, type, acceptance date, Official Gazette info). It also distinguishes itself from siblings by noting the returned `kimlik` is used to call mevzuat_metin and mevzuat_madde, which differentiates it from other search tools like acikveri_ara.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete example query and explains the follow-up workflow (use `kimlik` with mevzuat_metin/mevzuat_madde). It implies when to use this tool versus the mevzuat_metin/mevzuat_madde siblings, though it doesn't explicitly state when not to use it or mention alternatives like resmi_gazete_fihrist.

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 signal read-only and open-world behavior. The description adds useful behavioral detail: it returns the current consolidated text, and if the requested article does not exist, it returns the list of existing articles.

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 description is front-loaded with purpose and keeps examples short. The Turkish and English sentences partly repeat the same idea, but they add useful context such as 'consolidated text' and the fallback behavior.

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

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

Given full schema parameter coverage, an output schema, and read-only/open-world annotations, the description is sufficient. It explains the target, article formats, gives an example, and describes the missing-article fallback; remaining details like precedence between kimlik and no are already in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds a concrete example (kimlik 1.5.6698, madde 6 → KVKK special-category data article) and valid madde formats, which help the agent understand parameter intent beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation and resource: returning the current consolidated text of one article of a Turkish act. Its phrasing 'tek bir maddesi' and 'One article' clearly distinguishes it from full-text and search 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?

Usage is implied rather than explicit. The example with kimlik 1.5.6698 suggests using a result from mevzuat_ara, but the description does not directly say when to prefer this tool over mevzuat_metin or mevzuat_ara.

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 and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context: the text is official, consolidated, plain text, delivered in 20,000-character chunks, and accompanied by an article list. This goes beyond the annotations without contradicting them.

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 description is compact and front-loaded with the core purpose. The bilingual repetition is mild but not wasteful, and the chunking detail plus the sibling routing sentence each earn their place. It is appropriately sized for the tool's complexity.

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

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

Given the output schema and annotations, the description covers the main behavior, chunking, article list, and the key alternative. A small gap is that it does not explicitly state that at least one of no or kimlik is required, but the parameter descriptions strongly imply this. Overall it is sufficient for an agent to call the tool 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 baseline is 3. The description adds only marginal reinforcement about no versus kimlik and about baslangic as a continuation offset, but the schema already explains each parameter clearly. There is no substantial new semantic information in the description.

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 clearly states that the tool returns the official current consolidated full text of a Turkish act or regulation from mevzuat.gov.tr as plain text, in 20,000-character chunks, and that it also returns an article list. It explicitly distinguishes itself from the sibling mevzuat_madde by noting that the latter is shorter when a specific article is wanted.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit routing condition: if a specific article is requested, use mevzuat_madde instead. It also implies through the kimlik parameter that mevzuat_ara should be used first to obtain the identity. However, it does not fully spell out when to choose this tool over other alternatives beyond the one sibling.

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 indicate readOnly and open-world behavior, lowering the bar. The description adds useful behavioral context beyond annotations: the authoritative source (MGM), the distinction between current observations and 5-day forecast, the specific metrics returned, and the fallback to province center when district is omitted.

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 description is compact and front-loaded with source and scope, but it duplicates the same information in Turkish and English, which adds redundancy. Also, the key fallback behavior ('İlçe verilmezse il merkezi') appears only in Turkish, so an English-only agent may miss it.

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

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

Given only two simple parameters)Skip this tool is simple and the output schema exists, the description is complete: it states data source, coverage window, included observation/forecast fields, and the district-omission fallback. No critical calling information 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 coverage is 100% and both parameters already have example-rich descriptions Shema describes 'il' and 'ilce' adequately. The description adds the important default behavior that omitting ilce returns the province center, which is not stated in the schema, going beyond 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?

The description clearly identifies the resource (MGM weather data) and the exact scope: current observations and 5-day forecast for a Turkish province or district. It enumerates the returned fields (temperature, feels-like, humidity, wind, pressure, event) and is easily distinguished from all non-weather sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when to use the tool: for Turkish administrative locations and weather data from MGM. It also explains the default behavior when no district is provided ('İlçe verilmezse il merkezi'). No explicit alternatives are named, but no weather sibling exists, so the context is sufficient without exclusions.

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?

With readOnlyHint and openWorldHint already supplied by annotations, the description adds useful behavioral context: warnings are currently in effect, the data is live from MGM, and an empty list is a meaningful result. It also discloses the filtering behavior when `il` is provided. No contradiction with the annotations exists.

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 description is compact and front-loaded with the most important information: what the tool returns and for which weather events. The bilingual phrasing is slightly redundant but not wasteful, and every key behavior is covered in a few sentences.

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 simple optional-parameter lookup tool, the description is complete: it states the data source, the active-warning scope, the included fields, the filtering semantics, and the empty-list behavior. The output schema exists to cover return values, so no additional explanation is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the `il` parameter in detail, including that it searches warning text and provides examples. The description's mention that results are filtered by matches in title or text adds only slight reinforcement and does not materially expand beyond the schema. Baseline 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as returning currently active severe-weather warnings from Turkey's meteorological service, and specifies what each warning contains: event type, severity, risks, validity, and full text. This is a specific verb+resource combination and is easily distinguished from the sibling mgm_hava_durumu, which covers weather forecasts rather than warnings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when the tool is relevant: active warnings only, with optional province filtering.innerText It explains that no warnings results in an empty list, which is useful. It does not explicitly name alternatives or state when not to use this tool, but the context is clear enough for a single-purpose lookup 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?

The description goes beyond the readOnlyHint and openWorldHint annotations by explaining parameter-driven behavior: if 'yaka' is not given, both Anatolian and European sides are returned; if 'ilce' is given, only that district is returned. It does not disclose error handling or data freshness, but the annotations already cover safety, and the output schema exists, so the bar is lowered. This is adequate but not exhaustive.

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 description is four sentences, front-loaded with the core purpose, followed by clarifications. Every sentence adds distinct information: the scope, the distributor limitation, and parameter behaviors. It is not overly verbose and avoids redundancy with the schema, though it could be tightened slightly by removing the English repetition.

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 tool with an output schema and openWorldHint, the description covers the essential usage context: the data source, the parameter effects, and the special case for Istanbul. It does not describe the output structure, but that is handled by the output schema. It also does not mention potential missing data for some districts, but openWorldHint implies this. Overall, it is sufficient for correct 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 description coverage is 100%, so the baseline is 3. The description adds value by clarifying the default behavior for 'yaka' (both sides if omitted) and the filtering effect of 'ilce', which are not evident from the schema alone. It also contextualizes the 'yaka' enum as specific to Istanbul. This meaningfully supplements the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the exact function: providing current fuel pump prices (benzin, motorin, gazyağı, kalorifer yakıtı, fuel oil) in TL from Opet, per district. It specifies the resource (Opet), the scope (district-based), and the currency, leaving no ambiguity. Since no sibling tool covers fuel prices, differentiation is unnecessary, and the description is entirely self-contained.

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 explicitly notes that prices are from a single distributor ('Tek dağıtıcının fiyatıdır') and that other brands may differ, which tells an agent when this tool is not appropriate. It also provides clear usage rules for the 'yaka' and 'ilce' parameters, such as the Istanbul split and default behavior when 'yaka' is omitted. This is strong guidance for correct invocation.

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 and openWorldHint=true, so the agent knows this is a safe read operation with potentially changing data. The description adds valuable behavioral context: the default filtering to future dates, the timezone (Turkey time), and the fact that dates come from ÖSYM's own announcements. It doesn't mention pagination or rate limits, but for a read-only calendar tool, the key behaviors are disclosed.

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 description is compact and front-loaded: it states the resource, lists the exam types, explains the default behavior, and notes the timezone in three sentences. Every sentence earns its place, and the bilingual structure (Turkish with English summary) serves the likely user base without being verbose.

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?

The tool has an output schema, so return values are already documented. The description covers the key context: what data is included, the default filtering, the optional filter, and the timezone. It doesn't mention whether the data is cached or how frequently it updates, but for a read-only calendar with openWorldHint, the essential information is present. The only minor gap is not explaining what 'adımlar' (steps) means in the output, but the output schema likely covers that.

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 all three parameters (ara, limit, yalnizGelecek). The description adds the default value for yalnizGelecek (true) and clarifies that 'ara' filters by exam name, which is slightly redundant with the schema but reinforces the semantics. The description doesn't add significant new meaning beyond the schema, so baseline 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 clearly states the tool provides ÖSYM's annual exam calendar with specific exam types (YKS, KPSS, ALES, YDS, DGS, TUS, MSÜ) and date categories (application, late application, exam, result, preference). It also distinguishes itself from siblings by naming the specific authority and domain, which is unique among the listed tools.

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 explains the default behavior (only future steps) and mentions the optional 'ara' filter for exam name, giving the agent clear context on how to narrow results. It doesn't explicitly state when to use this tool vs alternatives, but the domain is so distinct (exam calendar vs. economic data, weather, legal texts) that the usage context is clear. It could be improved by noting that this is for exam dates only, not other ÖSYM services.

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 and openWorldHint=false, covering the read-only nature. The description adds the bidirectional behavior and the 81-province scope, which is helpful but does not go further into edge cases (e.g., handling of missing parameters or invalid input). This is adequate for a simple lookup with an 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 description is concise and front-loaded with the core behavior and examples. The only minor inefficiency is the English restatement at the end ('Turkish province ↔ plate code lookup'), which partly duplicates the title and Turkish sentence, but overall the text is tight and scannable.

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 simple lookup tool with an output schema and read-only annotations, the description covers the essential behavior and scope. It could be more explicit about whether one parameter is required or mutually exclusive, but this is a minor gap given the low complexity and clear examples.

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%: both 'il' and 'kod' already have meaningful descriptions, including case-insensitivity and code range. The description's examples (34 → İstanbul, Ankara → 06) reinforce the mapping but do not add new constraints or clarify whether exactly one parameter must be provided. Baseline 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 clearly states a bidirectional mapping between plate code and province name, with concrete examples (34 → İstanbul, Ankara → 06) and scope (81 il). It is easily distinguished from siblings like tcmb_kurlar or dogrula_tckn, which cover unrelated domains.

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 clearly conveys the tool's domain and intended use: convert a Turkish plate code to province name or vice versa. It does not explicitly mention when not to use it or name alternatives, but the context is unambiguous given the sibling tool list and the self-contained purpose.

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 and openWorldHint, and the description adds meaningful behavior beyond that: the date defaults to today and duplicate (mükerrer) issues are excluded. This is useful operational context not present in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and includes important caveats, but the Turkish and English sentences largely duplicate the same information. Still, it is compact and every major point is covered without excessive detail.

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 simple read-only tool with one optional parameter and an output schema, the description covers the essential context: scope, default date behavior, content types, sections, and the duplicate-issue exclusion. Nothing critical 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?

The single optional tarih parameter is fully documented in the schema with format and default value. The description repeats the default but adds no new parameter-level meaning beyond what the schema already provides.

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 clearly identifies the tool as returning a daily table of contents for Türkiye's Official Gazette, listing issue number, sections, and document types. This distinguishes it from the sibling resmi_gazete_metin, which is for full gazette text.

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 that it covers one day's contents and that omitting the date defaults to today, giving clear usage context. It does not explicitly name alternatives or exclusion conditions, but the scope is clear enough for an agent to choose it appropriately.

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 convey read-only and open-world intent, and the description adds meaningful behavioral context beyond them: long texts are read incrementally via baslangic, only resmigazete.gov.tr URLs are accepted, and PDF items yield a link rather than extracted text. It does not discuss rate limits or failure modes, but the output schema and read-only annotations cover much of that burden.

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 description is compact and front-loaded with the main operation, then lists restrictions and edge cases. The Turkish and English versions repeat the same information, which adds slight redundancy, but every distinct piece of guidance is useful and the overall length is appropriate.

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 fetch tool, the description covers the essential operational details: source of the URL, accepted domain, plain-text vs. PDF behavior, and pagination for long texts. Since an output schema exists, the description does not need to explain return structure, and nothing critical is missing for correct 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 description coverage is 100%, so the schema already explains both url and baslangic. The description adds mild context by tying url to a fihrist .htm page and baslangic to long-text continuation, but it does not meaningfully go beyond what the schema already provides.

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 action and resource: it returns plain text of a .htm Official Gazette item from the fihrist, naming document types (regulation, notification, decision). It also distinguishes itself by explicitly excluding PDF items, so an agent can tell it apart from related tools like resmi_gazete_fihrist and mevzuat_metin.

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 explicitly scopes usage to .htm items from the fihrist, restricts input to resmigazete.gov.tr addresses, and states the alternative behavior for PDF items (a link is returned, text is not extracted). This gives clear when-to-use and when-not-to-use guidance without requiring 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 and openWorldHint=false, so there is no contradiction. The description adds meaningful behavior: every figure is accompanied by its source instrument, derived values are explained in the `turetme` field, and the embedded year set is limited to 2026, which informs how the tool will respond.

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 description is compact and front-loads the resource and values before the version limitations. The bilingual Turkish/English repetition adds length but serves dual-language users, and every substantive clause (source, derived values, exclusions) earns its place.

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

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

For a read-only tool with one optional parameter and an output schema, the description is complete: it covers the data scope, source attribution, derived-value field, embedded year limitation, and explicit exclusions. No critical calling context 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?

The only parameter `yil` is fully described in the schema (year, default current year), giving a baseline of 3. The description adds critical semantics by disclosing that only 2026 is embedded in this version, which materially qualifies the allowed 2000–2100 range in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource — Türkiye's official annual minimum wage and SGK earnings floor/ceiling — and enumerates exact fields (daily gross, monthly gross, monthly net, floor/ceiling), each with its source instrument. It also states exclusions (severance cap, income tax brackets), which clearly differentiates it from sibling data tools.

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 implies use for retrieving official Turkish annual parameters and explicitly says severance-pay ceiling and income-tax brackets are absent, which is a useful when-not. However, it does not name alternatives or give decision rules for choosing between this and related tools such as resmi_gazete or tcmb_kurlar.

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, so the read-only nature is covered. The description adds a valuable behavioral trait: religious holidays are embedded only for 2026 and 2027, and for other years it returns diniBayramlarDahil=false and omits them without guessing. This goes beyond annotations and clarifies an important edge case.

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 description is compact and front-loaded with the main purpose, followed by the year-specific limitation. Every sentence earns its place; no fluff. It strikes a good balance between brevity and necessary detail.

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

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

With an output schema present (has output schema: true), the description does not need to explain return values. It covers the core behavior, the national/religious distinction, and the critical year limitation, which is sufficient for an agent to call it correctly. Nothing essential 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?

The schema fully describes the 'yil' parameter with min/max range and default (coverage 100%). The description does not add parameter-specific meaning; it focuses on tool behavior. The year limitation is more about behavior than parameter semantics, so it does not elevate the score beyond the schema-driven baseline of 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 clearly states the tool provides Turkey's public holidays for a given year, distinguishing between national (fixed) and religious (Diyanet calendar) holidays. It also highlights the year limitation, which implicitly differentiates it from a single-date holiday checker. The verb and resource are specific, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context that this is for annual holiday lists, but it does not explicitly mention when to prefer this over the sibling 'tatil_mi' tool or exclude single-date queries. It provides the scope (a year) and notes the year-specific religious holiday limitation, which is useful, but lacks explicit alternative 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 mark the tool read-only, and the description adds meaningful behavior beyond that: it reports weekday, weekend/official holiday status, and business-day status, including the specific rule that half days count as business days. This gives an agent useful operational detail without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loading the core behavior and then adding the half-day caveat. The bilingual English sentence is slightly redundant but serves Turkish and non-Turkish agents without bloating the description.

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

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

For a single-parameter read-only tool with an output schema, the description covers the essential logic and an important edge case (half days). It does not state the source of official holidays, but the existence of an output schema and the simple scope make this a minor gap rather than a blocking omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter, documenting the type and pattern. The description adds little beyond calling it 'verilen tarih', so it does not need to compensate; the schema already carries the format requirement.

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?

Description uses a specific verb 'söyler' and names the concrete resource: a given date's weekday, weekend/official holiday status, and business day status. It also scopes the behavior to Türkiye, and the focus on a single-date check distinguishes it from sibling resmi_tatiller, which likely lists holidays.

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 intended use is implied: provide a date to determine if it is a business day. However, there is no explicit guidance about when to choose this tool over resmi_tatiller or other siblings, and no exclusions are stated.

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

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

The annotations already declare readOnlyHint and openWorldHint. The description adds important behavioral context beyond annotations by warning about the `birim` field and that some rates are quoted per 100 units. This is valuable and consistent with read-only 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?

The description is bilingual, repeating the same information in Turkish and English. While this is not excessive, it could be more concise. However, it front-loads the purpose and the warning is placed after, which is acceptable. Score 4 for near-efficient structure.

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?

The tool is simple and has an output schema, so the description does not need to explain return values. It covers the unit warning, and given the output schema exists, the description is sufficiently complete for an agent to call 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?

The schema already provides descriptions for both parameters with 100% coverage. The description adds a few example codes (USD, EUR, GBP, JPY) but does not explain parameter semantics beyond what the schema provides. Baseline 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 clearly states the tool provides a single-currency TCMB indicator rate, with examples of currency codes. It distinguishes from the plural sibling by emphasizing 'tek para birimi' (single currency), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly mention alternative tools, but it provides clear context that this is for a single currency, implying that for multiple currencies the sibling tool tcmb_kurlar should be used. This is implied guidance rather than explicit, so it warrants a 4 for clear 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 declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds value by specifying the exact content (all currencies, buy/sell and effective rates in TL) and the default date behavior when no date is provided. This goes beyond what annotations convey, though it does not discuss other behaviors like rate limits or response structure, which is acceptable given the output schema exists.

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 description is three short sentences, with the core purpose front-loaded in both Turkish and English. It contains no filler, and each sentence adds meaningful information (what it returns, all currencies, default date). The bilingual format is efficient for agents operating across languages.

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 simple read-only tool with one optional parameter, full schema coverage, an existing output schema, and annotations covering safety, the description provides all essential context: purpose, scope (all currencies), and default date behavior. Nothing critical is missing for correct 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?

The schema covers 100% of the single optional parameter 'tarih', including its pattern and default behavior ('Boş bırakılırsa bugünkü (son) bülten'). The description repeats this default ('Tarih verilmezse bugünkü bülten') without adding new syntax or format details. Since schema coverage is high and the description adds no extra semantics, the 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 clearly states the tool provides daily indicative FX rates from the Turkish central bank, for all currencies, with buy/sell and effective buy/sell in TL. It uses a specific verb ('günlük gösterge döviz kurları') and resource, and mentions 'all currencies', which implicitly differentiates from the sibling 'tcmb_kur' (likely single-currency). However, it does not explicitly name the sibling or explain the distinction, so it falls short of a perfect score.

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 implies usage for all-currency FX rates but does not explicitly state when to use this tool versus alternatives like 'tcmb_kur'. It also provides a clear default behavior for the optional date parameter ('Tarih verilmezse bugünkü bülten'), which helps with invocation but not with tool selection. No exclusions or alternative routing are mentioned.

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