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=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=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=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.