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

Annotations already declare readOnly, idempotent and closed-world, so safety is covered; the description adds the substantive behavior the annotations cannot: the holiday calendar is Turkish and only *full-day* holidays are skipped, implying half-day holidays are not. It doesn't mention error behavior for malformed dates or the return shape, keeping it from a 5.

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

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

Two sentences, zero filler, with the core semantics (what is added, what is skipped) front-loaded before the use-case hint. Nothing repeats the title or the schema.

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

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

For a two-parameter pure function with full schema coverage and no output schema, this covers the essentials: arithmetic direction, calendar scope, and holiday granularity. Only the return type and invalid-date handling are left implicit, which is minor for an obviously date-in/date-out tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: a negative `days` value subtracts, and the unit is business days in the Turkish calendar rather than calendar days. It doesn't restate the ±1000 bound or the YYYY-MM-DD format, which the schema already carries.

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

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

States a specific verb (add/subtract), resource (Turkish business days) and behavior (skip weekends and full-day public holidays). It is clearly distinct from the arithmetic-free siblings in practice, but it never names count_business_days, the one sibling an agent could plausibly confuse it with.

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?

"Useful for legal, payment and delivery deadlines" gives a concrete usage context and the negative-value clause tells the agent subtraction is in-scope rather than a separate tool. There are no explicit exclusions or named alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent and closed-world, so safety is covered; the description goes beyond that by showing the exact output shape via an example, which matters since there is no output schema. It does not address edge cases such as zero, negatives, or very large numbers.

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

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

A single tight sentence front-loads the action, then the use case, then a worked example. Nothing is padded or redundant.

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 pure function with no output schema, the description plus the schema cover everything needed to call it correctly, and the example illustrates the return format. Only numeric edge-case behavior (negatives, rounding of the kuruş part) is left unstated.

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

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

Schema description coverage is 100%, with both amount format and the currency enum (including NONE = plain number words) documented in the schema itself. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

Specific verb ("Write ... in Turkish words") plus a precise resource (a number or money amount), backed by a concrete worked example (1250.50 -> "Bin İki Yüz Elli Türk Lirası Elli Kuruş"). It is unmistakably distinct from siblings like convert_currency or turkish_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?

Names the concrete domains where this is needed (invoices, cheques, contracts), giving an agent a clear trigger for calling it. It stops short of stating when not to use it or pointing at an alternative tool, so it falls just below the top band.

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?

'Works offline' largely restates openWorldHint=false, and readOnlyHint/idempotentHint already cover safety. The valuable addition is the output taxonomy (weekend / full holiday / half day / business day), which goes beyond annotations, but no response shape or edge behavior (e.g., unknown dates, half-day semantics) is given.

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

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

Two tight sentences, front-loaded with the core question and the domain constraint. Nearly zero waste; only 'Works offline' is marginal given the annotations.

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

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

With one optional parameter, full schema coverage, and no output schema, the main missing piece is output shape — partially covered by listing the possible classifications. Adequate for an agent to invoke 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% and already documents the YYYY-MM-DD pattern and the today-in-Türkiye-time default. The description adds no parameter detail beyond that, so baseline 3 applies.

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

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

States a specific verb+resource: tells whether a date in Türkiye is a weekend, public/full or half holiday, or business day. The classification taxonomy makes it distinguishable from list-style siblings like get_public_holidays, though no sibling is named.

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 'is it a business day?' framing implies use (e.g., before scheduling), but there is no explicit when-to-use vs get_public_holidays, add_business_days, or count_business_days. An agent must infer the boundary itself.

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 safety (readOnlyHint) and scope (openWorldHint), but the description adds two real behavioral facts: rates come from the official TCMB bulletin, and cross-currency conversions are computed via TRY rather than from direct pairs. It omits notable operational traits such as what happens on weekends/holidays when TCMB publishes no rate, and whether the result is rounded.

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

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

One sentence, front-loaded with the verb and the currency scope, then the rate source and date qualifier. There is no filler or repetition of the title.

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

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

The tool has five parameters, no output schema, and no nested objects, so the description must carry some of the return-shape burden; yet it never says what comes back (converted amount, effective rate, date used). It also leaves the non-publication-day behavior unaddressed, which matters for a rate lookup keyed on a date.

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 each parameter is already documented, including the rate_type enum and its default. The description only adds the 'via TRY' triangulation note and the date framing; it does not enrich amount, from, or to beyond what the schema says, so baseline 3 applies.

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

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

The description names a specific verb (Convert) and resource (an amount between currencies), and adds precise scope: TRY against any TCMB bulletin currency, or foreign-to-foreign via TRY, using official TCMB rates for a date. This is enough to separate it from the sibling get_exchange_rates, which plainly returns rates rather than performing conversion.

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

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

The description implies when to use it (you want a converted amount rather than a rate table), but it never explicitly says 'use get_exchange_rates instead if you only need the quote' or states prerequisites. The 'for a date' phrasing also hints at historical usage without clarifying behavior when no date is given, so guidance is inferable rather than 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?

Annotations already declare readOnly, idempotent and closed-world, so safety is covered. The description adds genuine behavioral detail the annotations cannot: the Turkish holiday calendar and the exclusion rules (weekends plus full-day holidays only, implying half-days are counted). It stops short of stating the return type or what happens if start is after end.

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

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

One sentence, front-loaded with the operation and scoped by the parenthetical exclusions. No filler, and the boundary conditions are stated before the qualifying details.

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 pure calculation with no output schema, the description covers calendar scope, boundaries, and exclusion rules. The main remaining gap is that the return value (an integer count) and error behavior for an inverted range are never stated.

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

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

Schema description coverage is 0%, but the two parameters are self-describing dates constrained by a pattern. The description does add the important boundary semantics ('after start up to and including end'), which the schema cannot express, though it omits the expected YYYY-MM-DD format and ordering constraints.

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?

A specific verb ('Count') plus a specific resource ('Turkish business days'), with the calendar scope named. It doesn't explicitly name the sibling add_business_days that an agent might confuse it with, so sibling differentiation is only implicit in the verb.

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

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

Usage is implied by the calculation it performs, but the description never states when to prefer it over add_business_days or get_public_holidays, nor any exclusions or prerequisites. The agent must infer the choice from the tool name alone.

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

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

Annotations already establish that this is a read-only, closed-world, idempotent lookup. The description adds useful behavioral context: it handles ambiguous names that exist in several provinces and works offline.

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

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

Three short sentences, front-loaded with the core purpose, then two useful behavioral notes. No wasted text.

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 lookup tool with annotations covering safety, the description is complete enough: it states the result, handles ambiguity, and notes offline operation.

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 name parameter is already documented. The description adds meaning by clarifying that district names may be ambiguous across provinces and that the tool handles that case.

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

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

The description gives a specific verb-resource-outcome: find which province a district belongs to. It is clearly distinct from province-focused siblings like get_province and list_provinces.

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 use case is clear: resolve a district name to its province. It also notes handling of duplicate district names, but it does not explicitly name alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: the authority backing the data, the 'indicative' (non-tradable) nature of the rates, the 1996 coverage floor, and the non-obvious fallback behavior for non-business days.

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

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

Two dense sentences with no filler; the core identity is front-loaded and the fallback caveat follows as a natural qualifier.

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

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

For a two-optional-parameter read tool with no output schema, the description covers source, quote direction, default behavior, historical range, and edge-case date resolution. Only the response shape (per-currency rows, rate fields) is left implicit, which is 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 coverage is 100%, so baseline is 3; the description goes further by explaining that the date parameter implicitly supports historical lookups back to 1996 and that out-of-bulletin dates resolve to the previous bulletin. It also clarifies the rate direction (TRY per unit), which the schema does not state.

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

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

States a specific verb+resource ('exchange rates'), the issuing authority (TCMB), and the quote convention ('TRY per unit'), which immediately separates it from the sibling convert_currency, which computes conversions rather than retrieving official bulletins.

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

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

Gives clear operating context: latest bulletin by default, any past date since 1996, and the weekend/holiday fallback rule. It does not explicitly name convert_currency as the alternative for arithmetic conversion, so the routing guidance is strong but not complete.

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 and external-dependency profile is partly covered. The description adds useful context by naming the Diyanet method and Aladhan API, but does not mention rate limits, error behavior if the API is unavailable, or the shape of the returned times.

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

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

A single front-loaded sentence that identifies the resource, enumerates the relevant outputs, and adds method/API context without unnecessary preamble or 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 simple read-only lookup with full schema coverage, the description is nearly complete and even helps by enumerating the returned prayer-time fields. However, with no output schema, it could more explicitly describe the response structure or date-default behavior, leaving 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 province, district, and date are already fully documented in the schema. The description reinforces the province/district scope but adds no format, default, or validation detail 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 states a specific verb and resource (daily prayer times), names the exact fields returned (imsak, güneş, öğle, ikindi, akşam, yatsı), and identifies the calculation method and upstream API. This clearly distinguishes it from sibling tools such as get_public_holidays or check_date.

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 'for a province or district' implies the intended input context, but there is no explicit guidance on when to choose this tool versus related siblings, nor any note about using list_provinces/find_district to resolve location names first. Usage is only implied rather than 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?

Annotations already declare read-only, idempotent, and closed-world behavior. The description adds useful context beyond that, notably that it works offline and tolerates casing and missing Turkish characters, but it does not describe return structure or error 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 a single front-loaded sentence with no wasted text. Every clause contributes either input format, output scope, or offline behavior.

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

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

For a simple one-parameter lookup with full schema coverage and annotations, the description covers input forms, output scope, and offline behavior. It stops short of describing the exact returned district structure or failure cases, but no output schema exists to carry that burden.

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 query parameter, so the baseline is 3. The description adds real semantic value by stating that names work in any casing and with or without Turkish characters, and that plate codes are also accepted.

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: look up a province by name or plate code and return its districts. This is clear enough to distinguish it from a bulk province list, but it does not explicitly differentiate it from siblings such as list_provinces or find_district.

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 explains accepted query forms and that the tool works offline, but gives no guidance on when to use this tool versus list_provinces or find_district. There are no routing conditions, exclusions, or 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?

Annotations already cover read-only, idempotent and closed-world behavior, so the bar is lower. The description still adds real context: data provenance (Diyanet's official tables), that eves are half-days, the 2024-2035 coverage window, and offline operation.

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

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

Two short sentences, front-loaded with the core resource and followed by the differentiating details. No filler.

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

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

For a single optional-parameter read tool with no output schema, the description covers scope, provenance, special cases and the validity window. Only the shape of the returned entries (fields, half-day flag representation) is left implicit, which is minor.

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

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

Schema coverage is 100% and the sole parameter already documents its default. The description goes beyond the schema by giving the supported year range (2024-2035), which the schema does not state and which an agent needs to avoid requesting uncovered years.

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

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

States a specific verb and resource ('Official public holidays for a year'), names the jurisdiction (Türkiye via the title) and the exact content returned (Ramazan/Kurban Bayramı dates, arife half-days). Clearly distinct from sibling date tools like check_date or add_business_days.

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 domain (Turkish public holidays) and valid year span are implied, but nothing tells the agent when to pick this over check_date or count_business_days, nor what happens for out-of-range years. Usage must be inferred.

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 and openWorldHint=true, so the safety and openness profile is covered. The description adds useful context that results are timestamped in both UTC and Türkiye local time, but it does not describe ordering, pagination, or what an earthquake record contains.

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

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

The description is two short sentences, front-loaded with the core resource and sources, followed by the most important return-format detail. There is no wasted text.

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 open-world data tool with fully described parameters, the description covers the basics. However, it omits the geographic scope mentioned only in the title and does not explain result ordering or the shape of returned earthquake records, which matters more because there is no output 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 description coverage is 100%, so all five parameters are already documented in the schema. The description only reinforces the source choices and time-zone behavior, adding little parameter-level meaning beyond the structured fields.

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

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

The description clearly identifies the resource as latest earthquakes and names the two possible data sources (AFAD and Kandilli). It is specific enough to distinguish this from unrelated sibling tools, though it does not explicitly state the geographic scope already present in the title.

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 strongly implied by the name and description, but there is no explicit when-to-use guidance, no comparison to alternatives, and no stated exclusions or caveats about source selection.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety and external-dependency profile are covered. The description adds genuinely useful operational context — free, no API key required, external provider Open-Meteo — but says nothing about units (metric vs imperial), output language, or what happens when a province/district name is unrecognized.

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

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

One sentence, front-loaded with the primary capability, with the provider caveat trailing as parenthetical. Nothing is wasted and nothing needs trimming.

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 full schema coverage and annotations, most needs are met. The remaining material gaps are the shape of the result (no output schema, and the description doesn't say whether it returns temperature, condition text, wind, or units), which directly affects how an agent presents the answer.

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 province, district, and the 1–7 day range with a default of 3 are already documented in the schema. The description only reinforces the province/district concept and the 'short daily forecast' nature of the days parameter, adding no format or validation detail beyond structured fields.

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

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

Names a specific verb (returns current weather plus a short daily forecast) and a specific resource (a Turkish province or district), plus the upstream source (Open-Meteo). No sibling tool overlaps on weather, so explicit differentiation isn't required, but the description could have said 'the only weather tool' to be airtight.

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

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

Usage is implied by naming the resource rather than stated: an agent infers it should call this for weather queries. There is no guidance on when not to use it (e.g. historical weather, marine/sea conditions, or hours-level forecasts it doesn't provide), and no pointer to list_provinces/find_district for resolving names even though those siblings obviously feed this tool.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description still adds value beyond them: 'Works offline' confirms no network dependency, and it discloses the payload contents (plate codes and district counts), which matters since there is no output schema. It stops short of describing ordering or total size beyond the count in the title.

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

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

Two short, front-loaded sentences with zero waste: the first names the resource and its fields, the second adds the offline property. Nothing irrelevant or repeated.

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

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

With no input params, no output schema and full annotation coverage, the description supplies the essential missing piece, namely what each province record contains. It could go slightly further on ordering or return shape, but an agent has enough to call and use 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The only caveat is that it doesn't warn there are no filtering options, but none are expected.

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 (all 81 provinces of Türkiye) and what each entry contains (plate codes, district counts), which is clear enough for an agent to know this is the enumerate-all tool. It does not explicitly contrast itself with the sibling get_province, so the list-vs-single distinction must be inferred from the plural name.

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 'all 81' wording implies bulk enumeration and the sibling get_province implies a single-lookup alternative, so the routing is reasonably implied. However, there is no explicit statement of when to use this versus get_province or find_district, and no exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is fully covered. The description adds the useful motivation (LLM case-folding errors) but says nothing about the output form, e.g. whether slug/ascii return empty strings for unsupported characters or how whitespace is handled. That rationale is value-add, but behavioral disclosure is thin.

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

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

Two short sentences with zero waste: the capability list comes first, followed by the reason to prefer this tool. Every clause 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 two-parameter, closed-world string transform with no output schema, the agent has everything needed to pick an operation and call it. Only the exact shape of the returned string (and edge-case behavior of slug/ascii) is left implicit, which is a small gap rather than a blocking one.

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

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

Schema description coverage is 0%, so the description must carry the load, and it largely does: 'upper/lower/title case', 'ASCII transliteration' and 'URL slugs' map onto all five enum values of 'operation'. The 'text' parameter needs no explanation for a pure transform. Minor residual gap: no guidance on what slug does with non-ASCII or punctuation.

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

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

The description uses a specific verb ('Correct') plus concrete resources (Turkish upper/lower/title case, ASCII transliteration, URL slugs) and even names the exact characters that make it hard (i/İ, ı/I). It is instantly distinguishable from the numeric, date and validation siblings. It stops short of a 5 only because the five operations are embedded in prose rather than mapped one-to-one to the enum values.

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?

'LLMs often get the dotted/dotless i wrong; use this instead' is an explicit routing cue telling the agent to prefer this tool over native/naive string handling. There are no alternative tools in the sibling list that overlap, so no exclusions are needed. It lacks a 'when not to use' clause, keeping it below 5.

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

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

Annotations already cover readOnly/idempotent/closed-world, so the bar is lower; the description still adds real value by naming the mod-97 algorithm, the TCMB participant list as the bank source, and 'Offline', which tells the agent no network call or rate limit applies. It stops short of saying what happens on an invalid IBAN (thrown error vs. falsy result).

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

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

Two tight sentences, no filler, with the core action first and the supplementary detail (bank identification, offline) trailing. Nothing to trim.

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

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

With no output schema, the description should sketch the return shape, and it only hints that a bank name comes back alongside validity. For a one-parameter validation tool with annotations carrying the safety profile, it is adequate but leaves the response contract ambiguous.

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

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

Schema coverage is 0% for the single `iban` parameter, but the description only implies the constraint ('Turkish IBAN') without specifying expected format — country prefix, length, whether spaces or lowercase are tolerated.

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?

Uses a specific verb+resource ('Validate a Turkish IBAN') and adds two distinguishing details: mod-97 checksum and bank lookup via the TCMB participant list. Sibling validators are validate_tckn/validate_vkn, and the 'Turkish IBAN' scoping is enough to tell them apart, though the description never names them.

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

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

Usage is implied by the name and the 'Turkish IBAN' scope, but there is no explicit statement of when to reach for this versus validate_tckn/validate_vkn, nor any prerequisite (e.g. input must be a TR-prefixed 26-char IBAN).

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

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely non-redundant context: it clarifies the operation is purely a checksum test (not a registry lookup of whether the number is real) and that it runs offline so the PII is never transmitted — exactly what an agent needs before passing an ID number in.

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

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

Two short sentences, zero filler. The operation is front-loaded and the privacy qualifier follows immediately, so 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?

There is no output schema, and the description never says what comes back — a boolean, a validity flag plus reason, or a thrown error — nor how invalid-format input is treated. For a one-parameter validator with annotations covering safety, that return-shape gap is the main outstanding omission.

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

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

Schema description coverage is 0% for the single required parameter, so the description must compensate and only partly does: it identifies the parameter's meaning as a T.C. Kimlik No but gives no format guidance (11 digits, digits only, no spaces) that would prevent malformed input.

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

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

States a specific verb and scope ("check the checksum") against a specific resource (Turkish national ID number, T.C. Kimlik No). Naming the exact ID type implicitly separates it from the sibling validators validate_vkn (tax number) and validate_iban, so an agent can route correctly without opening the schema.

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

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

Usage is implied: an agent holding a TCKN value will know this is the tool for it. However, there is no explicit when-to-use, no prerequisite statement, and no routing to the sibling validators for other identifier types — the distinction is left to the name alone.

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

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

Annotations already declare readOnly, idempotent and closed-world, and 'Offline' merely corroborates openWorldHint=false. The genuinely additive disclosure is the 11-digit fallback to TCKN validation, which is a real behavioral quirk not visible in the schema — but the description says nothing about what is returned (boolean vs. error) or how invalid input is reported.

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

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

Two short sentences, the digit-length constraint is front-loaded, and no words are wasted. Ideal size for a single-purpose validator.

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

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

With no output schema, the description is the only place return semantics could be documented, and it omits them entirely — an agent cannot tell whether to expect a boolean, a status object, or a thrown error. For an otherwise trivial tool this is the main remaining gap.

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

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

Schema description coverage is 0% and the single parameter is a bare string, so the description must carry the burden — and it does, specifying 10-digit VKN format and the 11-digit TCKN fallback. It stops short of stating whether whitespace, separators, or non-digit characters are tolerated.

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

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

States a specific verb (check the checksum) and resource (Turkish tax ID / VKN) with the exact digit length, so an agent knows precisely what is validated. It does not name the sibling validate_tckn as the preferred route for 11-digit input, leaving that differentiation implicit.

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 strongly implied: call this when you need to verify a Turkish tax number. However, it never states when NOT to use it, and given a validate_tckn sibling exists, the fact that 11-digit input is silently handled as a TCKN should have been framed as 'use validate_tckn instead for TCKN'.

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