VeriApi.Pro

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 genuinely useful non-schema context: the underlying endpoint `GET /v1/akaryakit`, that a paid package is required, and that each request costs 2 units. It stops short of saying what the response contains (current prices? per-distributor rows?) or whether data is live or lagged.

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

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

It is short, but the opening line duplicates the title word-for-word rather than adding information, and the cost/endpoint facts are crammed into the same run-on block. Front-loading the actual capability instead of the title would make it tighter.

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 only three fully documented parameters and no output schema, the description covers the basics plus cost and endpoint, but leaves key ambiguities: how this differs from the two akaryakit siblings and what the returned data represents. For a tool in a dense family of financial/market data tools, that omission matters.

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 (il, tur, dagitici) is documented in the schema, including accepted formats for il and comma-separated fuel codes for tur. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The first line is a verbatim repeat of the title and identifies the resource (province-level gasoline, diesel, LPG and other fuels, broken down by distributor), but it never states the actual verb or payload — presumably returning current fuel prices. It also does nothing to distinguish this from akaryakit_turkiye (country-wide) or akaryakit_gecmis (historical), so an agent must infer the difference from the names alone.

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

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

There is no explicit when-to-use guidance and no routing to alternatives, even though two sibling tools cover closely related data. The only conditional information given is commercial (paid plan required), not situational.

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 safety is covered. The description adds real operational context the annotations do not: a paid package is required and each request costs 2 units. It stops short of describing the response shape, ordering, or what happens when the requested range predates the collection start date.

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 text is very short and front-loaded, but the first sentence is a verbatim copy of the title, which spends the most prominent position restating structured metadata. The endpoint, paid-package, and cost sentences do earn their 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?

With no output schema and zero parameter documentation, the definition should say more about the return values (currency, unit, granularity) and the meaning of the day window. It does at least cover cost and access tier, which are the most consequential unknowns for an agent deciding whether to call it.

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 carries the burden and fails: nothing explains that `il` is a province name (or its expected format) or that `gun` limits the window and defaults to 30 with a 366-day cap. The word 'ilin' hints at the province parameter but adds no usage-level meaning.

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

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

The description states a specific resource and scope: daily average fuel prices for a province, starting from the date data collection began, plus the underlying endpoint `GET /v1/akaryakit/gecmis`. The verb is implicit (it is a history/retrieval tool) and the 'gecmis' suffix distinguishes it from the sibling `akaryakit`, though the description never explicitly contrasts the two.

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

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

There is no guidance on when to call this versus `akaryakit`, `akaryakit_turkiye`, or the other price-history tools such as `altin_gecmis` and `doviz_gecmis`. The only implied usage is 'want history rather than a current snapshot', and nothing is said about prerequisites beyond the paid-package note.

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 readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful non-schema behavior: a paid plan is required and each call costs 2 request units, plus the exact endpoint path. It stops short of describing what the payload contains, which matters since no 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?

Three short, front-loaded elements: scope, endpoint, cost. Nothing is padded. The opening clause largely restates the tool title, which is mild redundancy 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?

For a zero-parameter lookup the contract is simple, and the commercial cost information is a real addition. However, with no output schema the description should say what comes back — average prices per fuel type, currency, unit, or the distributor breakdown — and it is silent on all of 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?

The tool takes zero parameters, so the baseline is 4, but the description offers no information at all about what the parameterless response represents. With an empty schema the description could have compensated by naming the averaged products or units; it does not.

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 and scope: the Türkiye-wide average price computed from the 8 highest-volume fuel distributors, with the concrete endpoint GET /v1/akaryakit/turkiye. It implicitly distinguishes itself from the sibling `akaryakit` by being the country-wide aggregate, though it never states explicitly that it returns fuel prices or which product types are averaged. Clear but the differentiation from siblings is left to inference.

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

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

There is no when-to-use guidance: nothing says when to pick this over the sibling `akaryakit` or `akaryakit_gecmis`, and no prerequisites beyond the commercial note. The 'Ücretli paket gerekir' line is a cost/access constraint rather than a selection criterion. An agent must guess its place in the family.

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 two genuinely new behavioral facts not in the annotations: a paid subscription is required and each call consumes 2 request credits, plus the underlying endpoint GET /v1/altin. That cost/quota disclosure is exactly the kind of context annotations cannot express.

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

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

The definition is short and front-loads the identity of the resource, then the endpoint and billing constraints. The only inefficiency is the opening line duplicating the tool title verbatim, which spends a sentence without adding information.

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

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

For a one-optional-parameter read tool with annotations and no output schema, the cost and endpoint disclosures cover the most important unknowns. Still missing are the set of acceptable 'tur' values, the default when the parameter is absent, and any indication of how this differs from altin_gecmis, leaving the agent to guess on the only input it must supply.

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 single 'tur' parameter is already documented as a comma-separated list of types (e.g. gram, ceyrek). The description adds nothing further and, notably, gives no enumeration of valid types and no default behavior when 'tur' is omitted — but with full schema coverage the baseline of 3 applies.

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

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

The description states the resource ('Altın fiyatları' with alış/satış/değişim), so an agent knows it returns current gold buy/sell prices and change values. However, the first sentence is a verbatim restatement of the title, and nothing distinguishes it from the sibling altin_gecmis (historical gold prices), which is the main ambiguity an agent faces here.

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

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

There is no explicit when-to-use or when-not guidance, and no routing to altin_gecmis for historical data. The only conditional information is a prerequisite ('Ücretli paket gerekir'), which is helpful but is a cost gate, not selection guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context the annotations lack: a paid subscription tier is required (upstream data source dependency implied by 'kaynak bağlanınca dolar'). It says nothing about pagination, rate limits, or what happens when the paid tier is absent.

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

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

The text is short and front-loads the resource, but the first line simply restates the tool title verbatim, so a chunk of the content is duplicated structured data rather than added meaning. The endpoint and paid-tier note are the only substantive additions.

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 tool with an unconstrained string parameter, no output schema, and no described response shape, the description is too thin: it never says what a returned record contains or what 'kaynak bağlanınca dolar' means for the caller. The paid-tier warning is the sole completeness gain over the schema and annotations.

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 two parameters, so the description carries the full burden and does not meet it: 'gun' (day count, default 30, max 3660) and especially 'tur' (default 'gram', no enum, no description) are left completely unexplained. The word 'günlük' hints at daily granularity but does not clarify which values 'tur' accepts or how it relates to the sibling altin tool's type parameter.

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 and scope: historical gold prices at daily granularity, backed by the endpoint GET /v1/altin/gecmis. It separates itself from the current-price sibling altin only implicitly through the word 'gecmis' (history), without ever naming altin as the 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?

There is no guidance on when to call this versus altin (current prices) or doviz_gecmis (currency history); the agent must infer the distinction from tool names. The only usage-adjacent note is that a paid package is required, which is a precondition rather than a when-to-use rule.

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 without the description. The description adds that rates come either live from the Grand Bazaar or from a reference source, which is genuine behavioral context about data provenance, but it says nothing about rate freshness, rounding, or failure modes for unsupported currency codes.

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

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

It is short and front-loaded, but almost every token duplicates the title or is a bare endpoint path plus a plan-availability note. There is no wasted verbosity, yet little of the text earns its place as agent-facing guidance.

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

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

With four parameters, three required, zero schema descriptions, and no output schema, the definition should explain what the call returns and what each currency field expects. Instead it offers an endpoint path and a plan note, so an agent must guess at code format expectations and conversion semantics.

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 meaning for four parameters, and it largely does not: 'miktar', 'kaynak' and 'hedef' are undocumented in both places, and only the 'anlik'/'referans' distinction in the title loosely maps to the 'tur' enum. The three-character currency-code constraint and the amount bounds are left entirely to the schema's pattern and length rules.

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 title/description identifies a currency converter and mentions live Grand Bazaar versus reference rates with TRY support, which is a concrete verb+resource. However, the description body itself only repeats the title and appends an endpoint path, and it never distinguishes this tool from the sibling 'doviz' (rate lookup) or 'doviz_gecmis' (historical rates), leaving the agent to infer that this one converts an amount.

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

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

There is no when-to-use guidance: nothing says to pick this over 'doviz' when the user wants a converted amount rather than a rate list, and no prerequisites or edge conditions are stated. The only contextual note, 'Her pakette' (available in every plan), speaks to availability, not usage 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=true and openWorldHint=true, so the safety profile is covered without description text. The description adds nothing beyond that: no mention of result ordering (presumably most recent first), no pagination behavior, no rate limits, and no indication of which fields come back. The trailing fragment 'Her pakette.' conveys no verifiable 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?

Very short, but not efficient: the first line duplicates the tool title verbatim, followed by a bare endpoint path, then the meaningless fragment 'Her pakette.' None of these sentences helps an agent decide or call correctly, so the brevity reflects under-specification rather than tight writing.

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 five parameters, no output schema, and a query tool whose value depends on result shape and ordering, the description leaves too much unstated: no return fields, no sorting, no pagination note, and no clarification that results are capped to the last week unless 'saat' is supplied. Reference API path alone is not enough context.

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 80% and the four documented parameters (il, saat, yurtici, min_buyukluk) already explain themselves, including accepted formats (name, slug, or plate number). The description contributes no additional meaning such as units, magnitude scale, or default behavior. Baseline 3 applies when the schema does the heavy lifting.

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 scope: recent earthquakes in Turkey and its surroundings over the last 7 days, plus the backing endpoint GET /v1/deprem/son. Siblings cover unrelated domains (fuel, gold, prayer times), so no sibling differentiation is required. The description mostly restates the title and names no verb explicitly, keeping it short of a 5.

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

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

There is no when-to-use guidance, no exclusion criteria, and no mention of when to prefer a broader or different query. The only usage signal is the implied 'last 7 days' ceiling, which is embedded in the purpose statement rather than framed as guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about data provenance (Kapalıçarşı vs ECB/central bank reference), which goes beyond the annotations, but it says nothing about freshness guarantees, rate limits, or failure behavior for a live external feed.

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 core purpose is front-loaded, but the raw endpoint string 'GET /v1/doviz' and the trailing 'Her pakette' are noise that does not help an agent decide or invoke. The parenthetical is dense but informative.

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 only two optional parameters, full schema coverage, and annotations present, the definition is adequate but thin. It lacks guidance on defaults (tur defaults to anlik), output shape, and how it relates to the historical/conversion siblings, leaving gaps for an agent choosing among 27 tools.

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

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

Schema description coverage is 100%, and the schema already explains both 'kod' (comma-separated codes) and 'tur' (anlik vs referans with source semantics). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific resource (döviz kurları / exchange rates) and its unit (TRY karşılığı), plus the two data sources (anlık Kapalıçarşı vs merkez bankası referans). It does not explicitly differentiate itself from siblings like doviz_gecmis or cevir_doviz, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus doviz_gecmis (historical rates) or cevir_doviz (conversion), which are the obvious alternatives. The phrase 'Her pakette' ('in every package') is opaque and gives no actionable usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds nothing beyond that. It does not explain how the 5-year cap is enforced, what happens when no date arguments are supplied, whether the series is business-day only, or what the response 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?

It is short and front-loaded, but the length comes from under-specification rather than efficiency. The raw endpoint `GET /v1/doviz/gecmis` and the phrase 'Her pakette' add no value an agent can act on.

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, 0% parameter coverage, and only a read-only annotation, the description carries the full explanatory burden and does not meet it. An agent could not determine date-window precedence or result shape from this text alone.

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% across four parameters, and the description gives no parameter meaning whatsoever. Critical ambiguities are untouched: whether `gun` (default 30) overrides or combines with `baslangic`/`bitis`, and what `kod` accepts beyond a 3-character code (the 5-year mention only loosely hints at the 1830 maximum).

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 text names the resource (TCMB buy/sell exchange rate history) and the granularity (daily, up to 5 years), so an agent can tell it is a historical-rates lookup. However, the body is essentially a verbatim repeat of the title plus an endpoint path, and it never distinguishes itself from siblings such as `doviz` (current rates), `altin_gecmis` (gold history), or `cevir_doviz` (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?

There is no when-to-use guidance at all: nothing says to pick this over `doviz` for current quotes or over `cevir_doviz` for conversion. The trailing fragment 'Her pakette' ('in every package') conveys no actionable selection criterion.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the paid-package requirement and the cost of 2 request units per call, which an agent cannot infer from structured fields.

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

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

Three short, front-loaded fragments with no filler: purpose, endpoint, cost. Slightly telegraphic, but every element carries information.

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

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

For a simple two-parameter read tool with no output schema, the description covers purpose, endpoint, cost, and prerequisites. The only gap is the undocumented 'ilce' parameter, 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 50%: 'il' is documented in the schema, 'ilce' is not. The description only restates that ilce is optional, which the required list already implies, and adds no format or semantics for the undocumented district parameter.

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

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

The description names the resource (nöbetçi eczaneler) and its scope (il, isteğe bağlı ilçe), so an agent knows exactly what it returns. It does not need sibling differentiation since no sibling covers pharmacies, but it also does not explicitly say so.

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 prerequisite 'Ücretli paket gerekir' tells the agent a paid plan is needed, which is real usage context. However, there is no guidance on when to prefer this over alternatives or what happens if the district is omitted.

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 safety and openness are covered. The description adds only a raw endpoint path and the opaque phrase 'Her pakette', neither of which tells the agent anything behavioral (units, currency basis, freshness, or that missing months are 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?

Very short and front-loaded with the data content. The trailing 'Her pakette' is unexplained filler, but there is no other padding.

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

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

There is no output schema, so the description should explain what is actually returned — units of the endeks, whether changes are percentages, period labeling. It only echoes the field names and omits all of this for a data-retrieval tool.

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

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

Schema description coverage is 100% and the single optional 'ay' parameter is documented in the schema as 'Kaç ay geriye (en çok 60)'. The description adds no meaning about the parameter, which is acceptable at full coverage but earns only 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 text names the resource (TÜFE/CPI) and enumerates the data it covers (index, monthly, yearly, 12-month average change), which is more than a bare title. However, there is no verb (get/list/retrieve), and it is largely a restatement of the title, so the agent must infer that this is a retrieval call.

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

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

There is no statement of when to use this tool, when not to, or how it relates to any of the sibling tools (doviz, altin, vergi_maas, etc.). The agent gets no routing guidance at all.

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 readOnlyHint=true and openWorldHint=true, so safety is covered. Beyond that the description adds only the raw endpoint path and an unclear phrase ('Her pakette'), and is silent on how the five optional location parameters interact, which one takes precedence, or what happens when none is supplied.

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

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

It is short and the capability is front-loaded, but the trailing sentence 'Her pakette.' is cryptic and does not earn its place, while the mid-sentence endpoint path is low-value for an agent.

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 five optional location parameters, no required fields and no output schema, the description should explain location-resolution precedence and default behavior, but it does none of that. An agent calling it with a mix of il, ilce, enlem/boylam and konum has no documented rule to follow.

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 in the schema and the baseline of 3 applies. The description adds no meaning about precedence or combination rules across il, ilce, konum, enlem and boylam.

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

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

The description names the resource and its scope concretely (current conditions plus 24-hour and 7-day forecasts), which is more than a restatement of the title. However, it never distinguishes this tool from the sibling hava_detay, so an agent cannot tell which weather endpoint to choose from the text alone.

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

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

There is no when-to-use guidance, no mention of when to prefer hava_detay or the konumlar_* lookup tools, and no statement of preconditions. The phrase 'Her pakette' does not function as usable selection guidance.

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

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

Annotations already establish a safe read-only, open-world lookup, and the description adds real operational context: a paid-tier requirement, a 2-credit cost per request, and the underlying GET route. What it omits is error behavior when no paid plan is active and how partial location inputs are resolved.

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?

Roughly three telegraphic segments, all front-loaded: what it returns, the endpoint, the cost. Nothing is redundant, though the fragment style reads as a keyword dump rather than flowing guidance.

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 seven optional parameters, no required fields, and no output schema, the description covers pricing and payload scope but leaves the caller to work out how to select a location and how to bound the forecast window. Adequate for a weather lookup, but not self-sufficient for a first correct 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 a moderate 71%, so several parameters are already documented and the baseline of 3 applies. The description adds nothing about parameter interplay, notably that 'il'/'ilce'/'konum' form one locator mode while 'enlem'/'boylam' form another, nor how 'gun' and 'saat' constrain each other.

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 the resource and enumerates the distinctive payload it returns (feels-like, dew point, pressure, visibility, gusts) plus the 16-day horizon, which separates it from the plain 'hava' sibling. It never explicitly names that sibling or says how the two differ, so differentiation is implied rather than stated.

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

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

The 'Ücretli paket gerekir' note functions as a gating condition, telling the agent this call is only usable on a paid plan, and 'İstek birimi: 2 birim' signals a higher-cost call. There is no explicit statement of when to prefer this over 'hava' or which location-input mode to choose, so usage is only inferable.

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 two genuinely useful pieces of context: the operation is a GET endpoint, and a paid subscription is required to call it. It says nothing about rate limits, error behavior, or output shape beyond the tavan/damga vergisi/net outline.

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 text is short and front-loaded, and the endpoint path plus package requirement earn their space. But the first line is a pure restatement of the title, and the extreme brevity here reflects under-specification rather than efficient writing.

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 four-parameter financial calculator with no output schema, the description should at minimum explain what the two date parameters mean and what the returned figures represent. The parenthetical result hints (cap, stamp tax, net) help slightly, but an agent still cannot tell what the response object looks like or what convention the calculation follows.

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 only 50%: 'brut' and 'ek_odeme' are documented in the schema, while 'giris' and 'cikis' carry only a date format and no description at all. The description contributes no parameter meaning of its own, so it fails to compensate for the undocumented hire/termination dates, which are the crux of a severance computation.

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

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

The description names the resource (kıdem tazminatı) and the aspects it computes (tavan, damga vergisi, net), so an agent familiar with Turkish payroll terms can infer it is a severance-pay calculator. However, it is essentially a verbatim copy of the title with no verb and no differentiation from the sibling calculators hesapla_kredi, hesapla_mevduat, or vergi_maas.

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

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

No when-to-use or when-not-to-use guidance is given; nothing tells the agent to prefer this over vergi_maas or hesapla_kredi. The only contextual note, 'Ücretli paket gerekir' (paid package required), is a prerequisite for access rather than a routing rule.

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's `GET /v1/hesapla/kredi` line is consistent with that read-only profile. It adds one piece of behavioral context beyond the annotations — the paid-tier requirement — but says nothing about rounding conventions, default tax rates, error behavior, or how the response is shaped.

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

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

The definition is short and front-loads the outcome before the endpoint and prerequisite. The only waste is that the opening clause duplicates the title word for word instead of using that space for parameter or default-rate 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 7-parameter financial calculator with no output schema and low schema coverage, the description is thin — it never explains loan-type defaults, KKDF/BSMV rate semantics, or how vade/faiz units interact. An agent can guess the tool's purpose but not call it confidently without reading the raw 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 only 43% across 7 parameters, so the description is expected to compensate and does not. It never mentions tur (loan type categories), kkdf, bsmv, or the plan flag that controls whether the payment table is included, leaving more than half the inputs with no explanatory text anywhere.

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+resource in context (a loan payment plan calculation) and enumerates the outputs it computes: monthly installment, total interest, KKDF, BSMV, and annual cost. This is enough to separate it from siblings like hesapla_mevduat (deposit) and hesapla_kidem (severance), although the first clause is a verbatim repeat of 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 only implied by the domain wording; there is no explicit statement of when to pick this over hesapla_mevduat or hesapla_kidem, and no exclusions. The one genuine guidance element is 'Ücretli paket gerekir' (a paid package is required), which tells the agent about an access prerequisite but not about selection between tools.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: the paid-plan prerequisite, the underlying GET endpoint, and the fact that the result covers gross interest, withholding, and net return — meaningful because no 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?

Two short lines with the purpose front-loaded and no filler; the endpoint path and paid-plan note each carry information. It is efficiently sized, though the repetition of the title phrasing means the first line adds little beyond the title field.

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

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

For a five-parameter calculator with no output schema, the description does state what the result contains and that payment is required, which covers the essentials. It still leaves the currency dimension (tl/doviz) and the maturity parameter unexplained, so an agent must infer behavior from the schema alone.

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

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

Schema coverage is only 40%, so the description carries extra burden. It does clarify that 'faiz' is a gross rate and that 'stopaj' is withholding, but it says nothing about 'tutar', 'para' (tl vs doviz), or the 'gun' maturity default, leaving half the parameters explained only by terse schema text or not at all.

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

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

The description names a concrete calculation and its outputs: 'Vadeli mevduat getirisi: brüt faiz, stopaj, net getiri', which tells an agent this computes term-deposit yield with gross interest, withholding, and net return. It is clearly distinct from siblings like hesapla_kredi or hesapla_kidem by domain, though it never explicitly contrasts itself with 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 only implied by the domain wording; there is no explicit statement of when to choose this over hesapla_kredi or hesapla_kidem. The one genuine guideline present is the prerequisite 'Ücretli paket gerekir' (a paid plan is required), which is useful but is a constraint rather than a when-to-use rule.

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 safe-read profile is covered and the 'GET /v1/konumlar/bul' line adds nothing new. The only extra fact is 'Her pakette' (available on all plans), which is minor; nothing explains how ambiguity is resolved when several params are supplied, what happens with zero params, or what the result 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?

It is short and front-loaded, but the first clause simply repeats the title verbatim and the endpoint path is redundant with the readOnly annotation. The final fragment 'Her pakette' is terse to the point of being cryptic without surrounding context.

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 five optional parameters, no required fields, and no output schema, the agent needs to know which parameter combinations are valid and what is returned when nothing matches. The description supplies none of this, so it is thin for a multi-mode resolver with sibling overlap.

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

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

Schema description coverage is 100% and every one of the five parameters carries its own Turkish description with examples, so the schema does the heavy lifting. The description adds no precedence rules (e.g. konum vs il+ilce vs enlem/boylam) or formatting detail beyond what the schema states, so the baseline of 3 applies.

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

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

The description names a specific verb ('Konum çöz') and enumerates three input modes (slug, il/ilçe, en yakın koordinat), so the operation is identifiable. However, it is nearly a verbatim echo of the title and does not differentiate itself from siblings like konumlar_iller or konumlar_iller_il_ilceler, leaving an agent to guess why it would pick this one.

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 three input modes hint at when the tool applies, but there is no explicit when-to-use statement, no mention of when NOT to use it, and no routing to the two sibling konumlar_* tools that overlap heavily with it. The trailing phrase 'Her pakette' concerns plan availability, not usage guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds essentially nothing beyond the raw endpoint string. "Her pakette" ("in every package") is unexplained jargon that does not tell the agent anything actionable about output shape or 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?

It is short, but the second line is an unexplained API path and the trailing "Her pakette." is cryptic filler that does not earn its place. Front-loading is fine but the content is not self-explanatory.

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 to learn what comes back, and it says nothing about the response (province names, plate codes, IDs?). For a simple lookup tool it should still mention the return shape and explicitly contrast with the il/ilce sibling.

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; baseline 4 applies. No misleading parameter cues are present.

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?

"81 il" plus the endpoint path identifies the resource as Turkey's 81 provinces, which is more specific than a bare name restatement, but no verb states what the tool actually returns to the caller (names? IDs? structured records?). It also fails to distinguish it from the sibling konumlar_iller_il_ilceler, which sounds like the same province data plus districts.

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

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

No guidance on when to call this versus konumlar_iller_il_ilceler or konumlar_bul; the agent must infer the difference from tool names alone. No prerequisites or context 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds two pieces of context beyond that: the underlying HTTP endpoint and the fact that it is available on every plan ('Her pakette'). It says nothing about response shape, pagination, or error behaviour for an unknown province.

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

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

It is short, but that shortness comes from under-specification rather than efficiency: a title fragment, a raw endpoint, and a cryptic two-word note are stitched together without a clear lead sentence. The endpoint is front-loadable context but the particle 'Her pakette.' is unexplained.

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

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

For a one-parameter lookup tool with no output schema, the description should at minimum state the identifier format and what the result contains. Neither is given, so an agent knows the endpoint exists but not how to populate `il` or what it will receive back.

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 `il`, so the description must carry the meaning. Embedding `{il}` in the path template weakly signals that it is a path identifier, but it never states whether `il` is a plate code, a province name, or an ID — the one thing an agent most needs to call it correctly.

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

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

The description identifies the resource — the districts of a province — and pairs it with the endpoint `GET /v1/konumlar/iller/{il}/ilceler`, so an agent can infer it lists districts for a given province. However, it is a bare noun phrase that largely restates the title 'İlin ilçeleri', with no verb and no mention of how it differs from siblings like `konumlar_iller` or `konumlar_bul`.

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

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

There is no when-to-use guidance, no prerequisite (e.g. that a province identifier must first come from `konumlar_iller`), and no exclusions. The trailing note 'Her pakette' refers to plan availability, not to invocation context, so it does not help an agent decide between this and neighbouring location tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely new fact — availability in every package tier ('Her pakette') — but says nothing about year defaults, out-of-range handling, or whether values are current-year versus historical.

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?

Very short with no padding, and the resource name is front-loaded. However, the raw endpoint path (`GET /v1/mevzuat/asgari-ucret`) and the opaque 'Her pakette' fragment are stitched together without connective structure, leaving an under-specified rather than efficient definition.

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

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

For a one-optional-parameter read tool with no output schema and readOnly annotations, the field list partly conveys what comes back (gross, net, daily). The critical missing piece is default-year semantics and the unit/period of the returned amounts, which an agent needs to call 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 description coverage is 0% for the single parameter 'yil', so the description must compensate and does not: it never mentions the year filter, its 2000–2100 bounds, or that it is optional and presumably defaults to the current year. 'Günlük' hints that daily figures are derived, but no parameter meaning is added.

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

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

The description names the resource (asgari ücret) and enumerates the three figures returned (brüt, net, günlük), which an agent can distinguish from siblings like vergi_maas or ekonomi_enflasyon. It lacks an explicit verb (fetch/retrieve) and reads as a title restatement plus field list, but the field enumeration carries real identifying value.

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

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

No guidance on when to pick this over vergi_maas or other economy siblings, and no statement about what happens when 'yil' is omitted. 'Her pakette' describes plan availability, not usage conditions, so the agent gets no routing or prerequisite information.

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 only a redundant endpoint path (GET /v1/namaz) and an unclear phrase 'Her pakette', providing no additional behavioral context such as response format, rate limits, or how the Diyanet method affects results.

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 very short and front-loads the purpose, but the second sentence ('GET /v1/namaz. Her pakette.') is either redundant or cryptic and does not earn 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 tool with seven optional parameters and no output schema, the description does not explain how to combine location parameters (il, ilce, konum, enlem/boylam), what 'gun' controls, or what the returned data contains. It leaves significant gaps for an agent to infer.

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 seven parameters are fully documented in the schema. The description adds no extra semantics or usage hints beyond the endpoint path, so it meets the baseline for high 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 states the tool provides prayer times (namaz vakitleri), iftar, and sahur using the Diyanet calculation method, which is a specific resource. However, it largely repeats the title and does not differentiate from siblings beyond the obvious domain.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of typical use cases. 'Her pakette' is unclear and does not help an agent decide.

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 safety is covered. The description adds genuinely new operational context: a paid-tier requirement and a cost of 2 request units per call, which matters for an agent managing quota. It stops short of describing response shape or how the 100-symbol cap behaves at the boundary.

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, front-loaded lines: what it returns, the endpoint, then the cost/auth caveats. Efficient, though the first line largely duplicates the tool title rather than adding information.

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

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

With only two optional, fully documented parameters and no output schema, the tool is simple and the description covers cost and access tier. It nonetheless leaves open what happens with zero arguments (all symbols? all groups?) and how this differs from the asset-specific sibling tools, which is the main gap 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% — `grup` carries its enum explanation and `sembol` explains the comma-separated format and 100-item limit — so the schema does the work. The description contributes nothing about the parameters, leaving the baseline 3 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 phrase 'Anlık fiyatlar (alış, satış, günlük değişim)' names the resource and the three fields returned, and the endpoint `GET /v1/piyasa/fiyat` confirms the surface. However, it provides no differentiation from siblings like `doviz`, `altin`, or `cevir_doviz`, which plausibly return overlapping price data, so an agent cannot tell from the description alone why it should pick this tool over those.

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 only usage-relevant statement is 'Ücretli paket gerekir' (paid package required), which is a prerequisite rather than a when-to-use rule. There is no guidance on when this bulk price endpoint should be chosen instead of the per-asset tools such as `doviz` or `altin`, and no note on behavior when no parameters are supplied.

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 only adds the raw endpoint path ('GET /v1/takvim/gun'), which tells the agent nothing about output shape, default date behavior when tarih is omitted, or any external-data limitations.

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

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

It is short and front-loads the returned fields, which is good. But 'Her pakette' is unexplained filler and the raw endpoint path occupies space without adding decision-relevant information.

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

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

With no output schema and 0% parameter coverage, the description carries the full burden, and it only partially compensates by listing the returned fields. It leaves the default-date behavior and the distinction from takvim_tatiller undefined for a date-dependent lookup tool.

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

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

Schema description coverage is 0% for the single 'tarih' parameter, and the description never mentions it. The agent cannot tell from either source what happens if tarih is omitted (required count is 0), nor the expected date format beyond the schema's format hint.

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

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

The description names the resource and the three data points it returns (week number, business day, holiday), which is informative about content. However there is no verb, and it does not distinguish this from the sibling takvim_tatiller, which an agent could easily confuse with it.

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

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

There is no guidance on when to use this versus takvim_tatiller or any other calendar-related sibling. The phrase 'Her pakette' ("in every package") conveys no actionable usage condition and is never explained.

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 safety and external-data behavior are covered. The description adds no behavioral context whatsoever — not what a holiday entry looks like, whether the list spans the whole year, or whether the underlying service is rate-limited. "Her pakette" is unexplained and contributes no usable signal.

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

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

The definition is short and front-loaded, but the second line — a raw HTTP path plus the cryptic "Her pakette" — does not earn its place for an agent and should have been replaced by a sentence describing the returned data.

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?

This is a simple read-only tool with one optional parameter, yet with no output schema the description must explain what the tool returns, and it does not. An agent cannot tell whether the result is a list of dates, names, day-of-week, or holiday type, which leaves the definition incomplete for its complexity.

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

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

Schema description coverage is 100% and the single `yil` parameter is documented in-schema, including the default of the current year. The description adds nothing about the parameter, but with full schema coverage 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 is essentially the title restated: "Resmî tatiller ve dini bayramlar" adds no verb and no scope beyond what the name and title already say. The only extra content is the raw endpoint string `GET /v1/takvim/tatiller`, which tells an agent nothing about what the response contains or how this differs from the sibling takvim_gun.

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

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

There is no when-to-use guidance whatsoever — no mention of choosing this over takvim_gun, no note that the year defaults to the current year, no prerequisites. The fragment "Her pakette" is opaque and does not function as guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior by stating the search is Turkish and case-insensitive, that it does not consume quota, and what fields come back (path, name, description, parameters, paid/free). It stops short of describing result limits, ranking, or empty-result behavior, so it is strong 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?

Four short sentences, front-loaded with the core purpose, followed by return fields, the quota note, and the next-step call. Every sentence carries distinct information with no repetition of the schema or 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?

For a one-parameter read-only search tool with no output schema, the description supplies everything an agent needs: what is searched, language and case behavior, what is returned, cost in quota, and the follow-up invocation path. No material gap remains.

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

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

Schema coverage is 100% and the single parameter is documented as 'Aranacak kelimeler', so the baseline is 3. The description earns above baseline by clarifying that multi-word Turkish phrases with special characters ('şarj istasyonu', 'resmi gazete', 'posta kodu') are valid and matched case-insensitively, which meaningfully constrains how the parameter should be filled.

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

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

The description gives a specific verb and resource ('Tüm API uçlarında arama') and immediately separates itself from the sibling uc_cagir, which is the tool that actually invokes an endpoint. An agent can tell from the first sentence that this is a discovery/search tool, not an execution 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?

It explicitly routes the agent: search here, then call the discovered endpoint with uc_cagir, which is the exact alternative workflow a searcher needs. There is no explicit 'when not to use' or note about preferring a direct sibling tool when the endpoint is already known, which keeps it from 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so an agent knows the operation is a safe read against an open API. The description adds genuinely new behavior: the call deducts from a quota ('Kotadan düşer'), which is important cost information not present in the annotations. It omits error behavior and rate-limit details, so it stops short of a 5.

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

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

Three short sentences: the capability first, then the sourcing rule, then the placeholder behavior, and finally the quota warning. Nothing is padded, and each sentence carries actionable information.

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

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

For a two-parameter passthrough tool with no output schema, the definition covers purpose, sourcing, placeholder resolution, and quota cost. It does not describe the shape of the returned payload or what happens on a failed call, but no output schema exists to make that redundant, so a small gap remains.

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 both parameters are already documented. The description still adds meaning beyond the schema: it explains that `{ad}` placeholders in the path can be filled either through `parametreler` or inline in the path itself, which is a real usage rule not stated 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?

Description states a specific verb and scope: it calls any GET /v1 endpoint. It also distinguishes itself from the sibling `uc_ara`, which is the discovery tool that supplies the path and parameters; this is the execution 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?

It gives an explicit workflow: obtain the path and parameters from `uc_ara`, then invoke here. It also limits scope to GET endpoints, implicitly excluding write methods. It does not name a condition under which another tool should be preferred instead, but the routing to `uc_ara` covers the main ambiguity.

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 genuinely useful context beyond that: a paid package is required and each request costs 2 units, which matters for budgeting calls. It stops short of disclosing what the 12-month payroll response contains or how the two modes behave differently.

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

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

The definition is short and front-loads the operation before the endpoint and pricing notes. The endpoint path is arguably redundant with the tool itself, but the pricing sentence earns its place. 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?

With five optional parameters, no required fields, and no output schema, the description carries the burden of explaining how to call it correctly. It never states the brut/net exclusivity, what the 12-month payroll output looks like, or what happens if neither is supplied. For a dual-mode calculator this is a meaningful 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 80%, so the schema already documents ay, net, brut and engelli. The description adds nothing about parameter interaction, notably that 'ay' only matters in the net-to-gross direction and that brut/net are mutually exclusive. Baseline 3 is appropriate given the schema does most of the work.

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

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

The description names a specific domain operation: gross-to-net salary over a 12-month payroll, or net-to-gross. That is a clear verb+resource statement an agent can act on. It does not differentiate itself from the calculator siblings (hesapla_kidem, hesapla_kredi, hesapla_mevduat), which keeps it from a 5.

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

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

There is no guidance on when to use this tool versus the other hesapla_* calculators, and crucially no statement that the caller supplies either 'brut' or 'net' but not both. The two operating modes are named in the title but never explained as a choice the agent must make.

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