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

With no annotations, the description carries the full burden. It usefully discloses the computed output set (valuation, allocation, return, volatility, Sharpe, daily change), which signals a read-only analytical operation. It says nothing about data freshness, rate limits, whether an empty or all-invalid position list errors out, or any cost to calling it.

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, front-loaded with the analytical scope and followed by the input-domain note; no filler or repetition. It is appropriately sized for the tool's complexity, though the second sentence would earn more if it stated a constraint rather than an input capability.

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?

No output schema exists, so the description correctly compensates by enumerating the returned metrics, which is the main thing an agent needs to know. With 100% schema coverage on both parameters and only two parameters, little else is required; a note on data granularity or error behavior would complete 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 100%, so the schema already documents symbol formats (.IS suffix, crypto pairs), quantity, optional cost, and the default 30% risk-free rate. The description's only added parameter meaning is that indices and ETFs are valid in addition to stocks and crypto, a marginal increment over the schema's own examples.

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 ('analiz eder') and resource ('portföy'), then enumerates the exact outputs computed: value, sector/currency breakdown, return, volatility, Sharpe ratio and daily change. An agent immediately knows what it gets back. It does not, however, distinguish itself from the sibling backtest_portfolio, which an agent could easily confuse with this analysis tool.

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

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

The second sentence tells the agent what asset classes can be supplied as positions, which is input guidance rather than usage timing. There is no statement of when to choose this tool over backtest_portfolio (the closest sibling) or over the single-asset price tools, and no prerequisites or 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuinely useful trait — TRY assets are converted to USD before entering the portfolio and FX impact is reported separately — but it is silent on read-only nature, permission/auth needs, rate limits, or failure behavior (e.g., unknown symbols).

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 compact sentences plus a well-placed example; the computed-metrics list is front-loaded and the currency-conversion caveat follows logically. No padding 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?

With no output schema, listing the returned metrics in the description is the right move and largely compensates. The remaining gap is routing against the sibling analyze_portfolio and any statement about error handling or runtime expectations.

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

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

Schema description coverage is 100%, so the schema already documents period, interval, riskFreeRate and the nested symbol/quantity (including the exclusiveMinimum>0 and maxItems=15 constraints). The description adds a concrete positions example, which is mildly helpful, but contributes little beyond the schema. Baseline 3.

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

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

States a specific verb+resource ('Verilen portföy için geçmiş performans analizi yapar') and enumerates the computed outputs (getiri, CAGR, volatilite, max drawdown, Sharpe, varlık katkıları). It clearly describes a historical backtest, but never names or distinguishes itself from the sibling analyze_portfolio, so an agent must infer the split.

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?

Historical performance analysis is implied by the description, so an agent can guess the use case, but there is no explicit when-to-use guidance and no mention of the closely related sibling analyze_portfolio, which is the most likely confusion point. No exclusions or prerequisites 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds the key trait that conversion uses the current exchange rate, but it does not disclose return format, rounding behavior, rate source, or error/edge-case handling, so an agent has only partial transparency.

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 filler. It states the action, resource, and rate context economically.

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 3-parameter conversion tool, the description plus schema covers the core invocation. The main gap is the absence of an explicit return-value description since there is no output schema, but the conversion semantics make the expected result obvious enough.

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%: amount, from, and to each have descriptions with examples and length constraints. The tool description adds no parameter-level detail beyond what the schema already provides, 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 clearly states the action: 'Bir miktarı bir para biriminden diğerine ... çevirir' (converts an amount from one currency to another) and scopes it to the current rate ('güncel kur üzerinden'). This distinguishes the tool from rate-only and historical siblings like get_exchange_rate and get_historical_rate.

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 'güncel kur' qualifier implies this is for current-rate conversions, not historical ones, but there is no explicit statement of when to choose this over get_exchange_rate or get_tcmb_rate, nor any when-not-to-use guidance. Usage is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. It does useful work by naming the data source (Yahoo Finance, gold futures + USD/TRY) and disclosing that the gram prices are calculated rather than quoted. It does not state freshness/latency, failure behavior, or whether a fallback exists when Yahoo data is unavailable.

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 with no filler; the return content is front-loaded and the data source is a compact trailing note. Efficient, though it could fold the source note more tightly.

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

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

For a single-parameter, no-output-schema tool, the description covers what comes back (ounce in USD, gram in TRY), which karats are computed, and where the data originates. Missing only edge-case behavior (market-closed values, staleness), which is minor at this 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% — the karat enum is fully documented with meanings (24 = saf altın, 22 = ziynet altını) and a default. The description mirrors that both karats are supported but adds no syntax or format detail beyond the schema, 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?

States a specific verb+resource: returns the gold price, in both international ounce (USD) and gram (TRY) terms, and names the two karats covered. It is clearly distinguishable from generic siblings like get_crypto_price or get_bist_price. It does not, however, differentiate itself from get_commodity_price, which is a plausible overlap.

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 alternatives, no prerequisites, and no exclusions. The agent must infer from the name alone that this is the gold-specific tool rather than get_commodity_price.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the returned data fields (counts, upside %, 6-period change, average target price) and BIST coverage, which is useful given there is no output schema, but it says nothing about data freshness, rate limits, 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?

Two sentences, front-loaded with the tool's return content, with no wasted words. The second sentence adds coverage context efficiently.

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 usefully enumerates the returned fields, so an agent knows what it gets back. For a simple read-only, one-parameter lookup this is nearly complete, with only freshness/auth behavior 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?

There is a single parameter with 100% schema description coverage, so the schema already documents symbol format with examples (THYAO.IS, AAPL, NVDA). The description adds no further parameter meaning, which matches the baseline-3 expectation 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 verb+resource (return analyst consensus for a stock) and enumerates exactly what it contains: strong buy/buy/hold/sell counts, upside %, change over the last 6 periods, and average target price. This clearly separates it from sibling data tools like get_fundamentals or get_earnings_info, though no sibling is named explicitly.

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

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

The description never states when to use this tool versus alternatives, and gives no prerequisites or exclusions. The only contextual hint is the note that BIST stocks also carry Turkish brokerage-firm data, which is coverage information rather than 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?

There are no annotations, so the description carries the full burden. It discloses what data is returned (value, change, volume) and the default behavior when indices are omitted. However, it does not mention caching, rate limits, data freshness, or error handling for invalid index codes. For a simple market-data read tool, this is adequate but incomplete.

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, no waste. The return values are front-loaded, followed by the default behavior. Every word 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 single-parameter read tool with full schema coverage and no output schema, the description is nearly complete: it states what is returned and the default. The only gap is lack of guidance on when to prefer this tool over siblings or how errors are handled, which is minor given the tool's simplicity.

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

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

Schema description coverage is 100%, so the schema already documents the indices parameter, including examples and the default behavior. The description's mention of the default index list adds a small amount of context but largely repeats what the schema provides. Baseline 3 is appropriate 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?

Clear verb+resource: returns current value, change, and volume for BIST indices. It does not explicitly distinguish itself from the sibling get_bist_price, which likely targets individual stocks rather than indices, but the resource (indices vs. price) is specific enough for an agent to select correctly.

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

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

The description states a default set of indices, which implies usage for quick overview calls, but there is no explicit when-to-use guidance or mention of alternatives like get_bist_price or get_market_indicators. Usage is implied rather than spelled out.

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

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

With no annotations provided, the description carries the behavioral burden and does a reasonably good job: it discloses the Yahoo Finance data source and the 15-minute delay, which are material behavioral traits. It also clarifies that only the stock code should be provided. It does not describe error behavior or output structure, but the core behavioral context is covered.

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

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

The description is three sentences, with the purpose first, the data-delay detail second, and the input format third. Every sentence earns its place and there is no redundant or filler content.

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

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

For a single-parameter, simple look-up tool, the description is nearly complete: it names the BIST scope, source, delay, and symbol format. Since there is no output schema, it would benefit from a bit more detail on what 'piyasa verileri' includes or the exact return shape, but an agent has enough to invoke it correctly.

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

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

The input schema already documents the single parameter thoroughly, including examples and the instruction not to append .IS, giving 100% schema description coverage. The description adds a similar example set but no meaningfully new parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states that the tool returns Borsa İstanbul (BIST) stock prices, changes, and market data, with a specific verb and resource. It is clearly scoped to BIST stocks, which separates it from exchange-rate, crypto, and global-stock siblings, though it never names an alternative explicitly.

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

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

The description implies the tool is for BIST stocks and gives example symbols, but it does not explicitly state when to prefer this tool over siblings like get_global_stock_price or get_exchange_rate. Usage context is present, but exclusions and alternatives are left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read query but discloses nothing about rate limits, auth requirements, freshness/lag of the quotes, or what the response contains for a price-lookup tool whose output format is undocumented.

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 efficient sentences with the verb+resource front-loaded and the input hint following. The commodity list is somewhat enumerative but proportionate to the tool's breadth.

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

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

For a single-parameter lookup with no output schema, the description covers inputs but says nothing about the returned structure (quote value, currency, timestamp). Adequate but leaves the response contract undocumented.

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

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

Schema coverage is 100%, so the schema already enumerates the accepted names and Yahoo symbols (GC=F, SI=F, etc.). The description only restates the same Turkish-name-or-symbol flexibility, adding no syntax or fallback detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (döndürür = returns) and resource (emtia fiyatları = commodity prices) with concrete examples (gold, silver, WTI/Brent, gas, copper, platinum, palladium). Clear purpose, though it doesn't explicitly distinguish itself from nearby siblings like get_altin_gram_price or get_fund_price, which could overlap for precious metals.

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

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

The description gives only an implied usage (querying a commodity price) and a loose input hint ('Turkish names or symbols'), but no explicit when-to-use, prerequisites, or alternatives. With get_altin_gram_price present in the sibling list, the absence of routing guidance for gold in particular is a real gap.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the result includes both correlation and return statistics, but says nothing about computation method, data source, latency/cost, or error behavior for invalid symbols. Useful but incomplete for a no-annotation tool.

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

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

Three short sentences front-loaded with the verb and resource, then the use case, then examples. No filler, and each sentence adds a distinct piece of 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, the description partially covers return values by naming 'getiri istatistikleri' alongside the correlation. It is sufficient to call the tool correctly given full schema coverage, though the exact contents of the return statistics remain unspecified.

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

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

Schema description coverage is 100%, so the schema already documents period, interval, and the '.IS' symbol convention. The description's example pairs (THYAO.IS, BIST100) / (BTC-USD, XU100.IS) reinforce symbol formatting but add little 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?

The description names a specific verb and resource: it computes the price correlation and return statistics of two assets. It enumerates the asset classes accepted (hisse, endeks, kripto, para birimi), and no sibling tool does the same computation, so an agent can distinguish it immediately.

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 states the concrete use case ('Portföy çeşitlendirme / bağımlılık analizi için kullanılır') and supplies worked examples of argument pairs. There are no explicit exclusions or named alternatives (e.g. analyze_portfolio), which keeps it 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?

With no annotations, the description carries the full burden. It does disclose the output content (current value + 30-day history) and the meaning of the 0-100 scale, which is useful beyond structured fields, but says nothing about read-only nature, data freshness/update cadence, or failure behavior for a retrieval tool.

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

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

Three short, front-loaded sentences with zero filler: purpose and return content first, scale interpretation second, usage context last. Every sentence earns its place.

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

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

For a simple one-parameter read tool with no output schema, the description adequately covers what is returned, the value scale, and a usage hint. The only real gap is that it doesn't clarify the configurable history range or data recency, both minor for this 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 'history' parameter (1-30, default 30) is fully documented in the schema, so baseline 3 applies. The description's phrase 'son 30 günlük geçmişi' restates the default rather than adding syntax or behavior detail.

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+resource: returns the current Crypto Fear and Greed Index value plus 30-day history. The resource is unique among siblings (no other tool covers a sentiment index), and the scale interpretation (0=extreme fear, 100=extreme greed) removes ambiguity about what the returned number means.

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?

'Piyasa duygu analizi ve zamanlama için' gives an implied usage context (market sentiment analysis and timing) but never states when to prefer this over siblings like get_crypto_market_overview or get_market_indicators, nor any exclusions or prerequisites.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape (OHLC) and supported currencies, which is useful, but says nothing about pagination limits, error behavior, or how limit and period interact. For a low-risk read tool this is adequate but 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?

Three short sentences, zero filler, with the core action (returns historical OHLC data) front-loaded before the use case and examples. Efficient, though the example list adds little beyond the schema's own examples.

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 explain the return payload; it names OHLC and the currency but does not describe the record structure or date fields. Combined with 4 parameters and no annotations, the definition is workable but leaves the agent guessing about the response.

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

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

Schema description coverage is 100%, so the schema already documents coin, limit, period, and vsCurrency. The description's mention of USD/TRY and example coin names duplicates schema content rather than adding syntax or format detail, 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?

States a specific verb and resource: returns a cryptocurrency's historical price (OHLC) data, with the currency scope (USD/TRY) and example coins. An agent can distinguish it from get_crypto_price (spot) and get_multi_crypto_price, though neither sibling is named explicitly.

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

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

The phrase 'grafik/teknik analiz için uygundur' (suitable for charting/technical analysis) implies a usage context, but gives no explicit when-to-use or when-not-to-use versus get_crypto_price or get_technical_indicators. Usage must be inferred from the resource name.

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

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

With no annotations, the description carries the full burden, and it does disclose genuinely useful operational context: the source is CoinGecko, free, and requires no API key. However, it says nothing about rate limits, caching, or freshness of the 24h figures, and the read-only nature is only implied by the 'döndürür' verb.

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 efficient sentences with the returned content front-loaded and the data-source note placed last where it belongs. No filler, though the enumerated field list is slightly dense.

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-required-param read tool with no output schema, the description substitutes for the missing return documentation by listing every field returned. The only gap is the absence of any note on data freshness or update cadence.

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 includeTrending is already fully documented in the schema. The description implies the trending list is part of the response but does not clarify that it can be toggled off or what happens when includeTrending is false, so it stays at the baseline for a fully-covered 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?

It states a specific verb (döndürür) and resource (kripto para piyasasının genel görünümü) and enumerates the exact payload: total market cap, 24h volume and change, BTC/ETH dominance, trending coins. That is far more specific than a sibling like get_crypto_price, though the description never explicitly names which sibling to prefer.

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 or when-not-to-use guidance and no mention of alternatives such as get_market_summary, get_crypto_price, or get_crypto_fear_greed. The only contextual hint is the data source, which is informational 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?

With no annotations provided, the description carries the full burden. It accurately discloses the behavior (returning price, 24h change, market cap) and implies a read-only operation. However, it does not mention error behavior for invalid coin IDs, data freshness, or rate limits—context that would strengthen transparency for an unannotated tool.

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

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

A single sentence with a parenthetical example. Every word earns its place—the verb, resource, return fields, and sample use are all included with no filler. The description is front-loaded with the core action.

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 2-parameter read tool with no output schema, the description covers the essential return values (price, 24h change, market cap) that an agent would need. It does not mention the default vsCurrency (already in the schema) or edge-case behavior, but the missing details are minor given the tool's simplicity.

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

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

Schema description coverage is 100%, so the schema already fully documents both coinId and vsCurrency with examples and clarifications. The description adds only an illustrative example ('bitcoin → try') and does not provide additional parameter semantics beyond the schema, matching the baseline of 3.

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

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

The description states a specific verb ('döndürür' = returns), a precise resource (a cryptocurrency's price), and the exact data returned (current price, 24-hour change, market cap). The example 'bitcoin → try' and the word 'kripto' clearly distinguish it from fiat/exchange-rate siblings.

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

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

The description makes the context clear: use for a single cryptocurrency's current price in a given currency. It does not explicitly exclude batch scenarios or name get_multi_crypto_price as an alternative, so it falls short of a 5, but the singular phrasing and example give sufficient contextual 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses what is measured (accessibility, response time, cache status), which is more than a tautology, but it says nothing about whether the check is read-only/side-effect free, auth or rate-limit implications of pinging many providers, or how failures are surfaced.

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, no filler, with the action and reported dimensions front-loaded before the diagnostic use case. The long parenthetical source list is informative rather than wasteful, though it is the one place the sentence carries extra weight.

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-required-param diagnostic tool with no output schema, the description states what is measured and why to call it, which is close to sufficient. It could go further on the shape of results (per-source status vs. aggregate) but the essential calling context is present.

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

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

Schema description coverage is 100% and the single optional 'only' parameter already documents its filtering purpose and gives a format example in the schema. The description adds no additional meaning about this parameter, 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?

States a specific verb (raporlar) plus the exact resource and the dimensions it reports: live accessibility, response time, and cache status of all data sources. It enumerates the concrete sources covered (Yahoo Finance, TCMB, CoinGecko, etc.), which clearly separates it from the sibling tools that fetch market data rather than diagnose source uptime.

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 second sentence gives explicit intent: 'Hangi kaynağın çalışıp çalışmadığını teşhis etmek için kullanılır' (used to diagnose which source is working). This is clear when-to-use context, but it names no alternatives and offers no exclusions or prerequisites, so it stops short of the top tier.

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?

No annotations are provided, so the description carries the full burden. It discloses the returned content and exchange coverage, and 'döndürür' (returns) makes the read-only nature clear, but it says nothing about data source, latency, or behavior when a symbol has no dividend records.

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 tightly written sentences: the return payload is front-loaded and the exchange support plus examples follow. No filler or redundancy.

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 usefully names the return fields (history, annual totals, 12-month yield), and full parameter coverage means nothing structural is missing. Only the absence of edge-case behavior (e.g. no-dividend symbols) keeps it from a 5.

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%: symbol, years (1-15) and includeSplits are all documented in the schema, so the description only needs to not contradict it. The example tickers mirror the symbol parameter but add no new semantics, 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?

States a specific verb and resource (dividend/profit-share history) and enumerates the concrete outputs: annual totals and trailing 12-month yield. This clearly distinguishes it from price-oriented siblings like get_stock_history or get_earnings_info, though it never names those siblings explicitly.

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

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

Usage is implied rather than stated: the description notes it covers all exchanges including BIST and gives ticker examples, so the agent can infer when it applies. There is no explicit when-to-use vs. when-not, nor any pointer to an alternative 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the operation is a read ('döndürür') and names the exact fields returned, which is helpful, but says nothing about permissions, data freshness, rate limits, or behavior when no upcoming earnings exist.

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 compact sentences that lead with the core purpose and then enumerate the return payload, with no filler. Slightly dense but 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?

With no output schema, the description usefully enumerates the returned fields and states market coverage, which is the key missing structured information. It remains thin on error/empty-result behavior, but for a single-parameter read tool it is nearly complete.

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

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

There is one parameter with 100% schema description coverage and example symbols (THYAO.IS, AAPL, NVDA, MSFT) already documented in the schema. The description adds only the geographic scope (BIST and US), which marginally clarifies valid symbol formats, 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?

States a specific verb and resource (returns a stock's upcoming earnings date and analyst expectations) and enumerates the exact payload fields (EPS range, revenue estimate, last earnings date, EPS growth). This makes it distinguishable from generic quote tools, though it does not explicitly separate itself from the overlapping get_analyst_consensus sibling.

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 signal is the scope note that it works for both BIST and US stocks, which is useful context but not a when-to-use rule. There is no guidance on when to prefer this over get_analyst_consensus or get_fundamentals, so the agent must infer the 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?

With no annotations, the description carries the full burden. It usefully discloses the nature of the return content (an official announcement schedule rather than indicator values), but says nothing about ordering, timezone/date semantics, data source latency, or pagination behavior beyond the limit parameter.

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 with the core purpose front-loaded and the filtering capability trailing. No filler, though the second sentence is fairly generic.

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?

A simple read-only list tool with zero required params, so little is strictly needed. However, with no output schema and no annotations, the description could say more about the shape of returned events (fields, ordering) to be fully self-sufficient.

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

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

Schema description coverage is 100%, so the schema already documents limit, range, impact and country with enum values. The description adds no syntax or format detail beyond restating the country and impact filters, 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?

States a clear verb+resource: returns the official announcement calendar of macro data, explicitly listing the categories (central bank rate decisions, CPI, GDP, employment). This distinguishes it from value-returning siblings like get_macro_indicators or get_inflation_data, though it never names an alternative directly.

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

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

Usage is only implied — an agent infers you call this to see upcoming macro events. The sentence about filtering by country and impact level is parameter description, not guidance. No when-to-use, when-not, or alternative-tool routing is 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?

With no annotations, the description carries the behavioral disclosure burden. It does state the core behavior: returning a current or date-specific exchange rate. But it does not mention the rate source, response format, error behavior for invalid currency codes or dates, or any rate-freshness limitations, which leaves meaningful uncertainty for a tool without annotations or an output schema.

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

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

The description is one concise, front-loaded sentence with no filler. It communicates the operation, the optional date behavior, and a concrete example efficiently, which is ideal for an AI agent scanning available tools.

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

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

The tool is simple and the schema fully covers the three parameters, so the description does not need to repeat parameter details. However, with no output schema and no annotations, the description omits the shape of the returned rate, source/limitations, and how this differs from several closely related sibling tools, leaving moderate gaps for a completely self-contained definition.

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

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

Schema description coverage is 100%, so the schema already documents from, to, and date. The description adds only the example pair and the notion of date-specific rates, which is helpful but does not materially exceed what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb ('returns'), the resource (exchange rate between two currencies), and the optional date dimension. The example 'USD → TRY' makes the input format intuitive. However, it does not explicitly distinguish itself from the sibling tools get_historical_rate or get_tcmb_rate, and the date option creates potential overlap with get_historical_rate.

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

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

The description implies usage for current or date-specific exchange rate lookups, and the date parameter notes that omitting it yields the latest rate. However, it gives no explicit guidance about when to choose this tool over get_historical_rate, get_tcmb_rate, or convert_currency, and no exclusions or alternatives are mentioned.

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?

No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses the data source (Yahoo Finance RSS) and freshness ('güncel'/'current'), but says nothing about rate limits, latency, caching, or error behavior for invalid tickers.

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 purpose front-loaded before the source and examples. Every element 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 simple 2-param read tool the description is adequate, but with no output schema and no annotations it does not describe what the returned news items contain (headline only, link, publish time). The 'limit' schema hints at headlines, but the return shape is left implicit.

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

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

Schema description coverage is 100%, so both 'ticker' and 'limit' are already fully documented in the schema, including the same ticker format examples the description repeats. Baseline 3 applies since the description adds no 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?

States a specific verb ('döndürür'/returns) and resource ('güncel finans haberleri'/current financial news) scoped to stocks, indices, crypto and currencies. An agent can immediately distinguish it from data-oriented siblings like get_stock_history or get_fundamentals that return prices rather than news.

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 description ('current news about an instrument') but there is no explicit when-to-use, when-not-to-use, or named alternative. With ~37 siblings, no routing guidance is offered even though news-based tools are a distinct category, leaving the agent to infer applicability.

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?

No annotations are provided, so the description carries the full behavioral burden. It states what data is returned but not key traits: whether it's read-only (implied), rate limits, data freshness/delay, or failure modes for unsupported symbols. For a market-data tool with zero annotations, this 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 front-loaded sentences: the first lists exactly what is returned, the second states coverage. No filler, no 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 single-parameter read tool with a fully documented schema, the description covers purpose and scope adequately. However, with no annotations and no output schema, the description doesn't explain return structure or data freshness, leaving gaps for an agent.

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 schema already documents the symbol format including '.IS' suffix and examples. The description adds the assurance that BIST and global stocks are both supported, complementing the schema's examples, but adds no syntax beyond that.

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?

Clear verb and resource: returns fundamental analysis indicators for a stock, with an enumerated list of what is included (P/E, EPS, P/B, dividend yield, margins, growth, beta, profile, analyst targets). It distinguishes itself from siblings like get_technical_indicators and get_stock_history by naming the fundamental dimension. It does not explicitly name a sibling, so 4 not 5.

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

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

No explicit when-to-use or when-not-to-use guidance. It implies use for fundamental analysis, but doesn't contrast with siblings such as get_technical_indicators, get_analyst_consensus, or get_earnings_info, nor does it state prerequisites.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses what is returned (current price and recent return), but says nothing about rate limits, authentication, error behavior, or the TEFAS 28-day request constraint mentioned only in the schema. For a no-annotation tool this is a significant gap.

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 that front-load the core purpose (returns NAV and recent return) before giving input examples. No wasted 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 no output schema or annotations, the description covers the input side and the headline outputs (price + return), but it does not clarify the return shape (single value vs. time series implied by the days parameter) or the period semantics. Adequate but leaves ambiguity for a tool with a configurable date window.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (fundCode accepts code or name, days is 7-28). The description's examples (GAF, ABA) reinforce the fundCode flexibility but add little beyond what the schema states, making 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?

States a specific verb (returns) and resource (current NAV price and recent period return of a TEFAS-traded investment fund). The TEFAS/fund scope naturally distinguishes it from siblings like get_bist_price, get_crypto_price, and get_altin_gram_price, though it never names an alternative. Clear but lacks explicit sibling differentiation.

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

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

Usage is implied by the resource scope ('TEFAS'ta işlem gören bir yatırım fonu'), and examples of acceptable inputs (GAF, ABA, fund code or name) are given. However, there is no explicit when-to-use or when-not-to-use guidance relative to sibling price 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?

No annotations are provided, so the description carries the burden. It does disclose that the tool returns real-time/current price and market data, and gives symbol format hints. However, it does not mention limitations such as potential data delays, error behavior for invalid symbols, or any other caveats, leaving the transparency somewhat shallow.

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 stating the core purpose, followed by an example list. It is concise and scannable; the examples add valuable context without excessive verbosity.

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

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

For a single-parameter tool with no output schema, the description is reasonably complete: it states the data returned and provides symbol examples. Yet it does not indicate response structure, potential errors, or rate limits, so an agent may lack full clarity on how to interpret the result.

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% because the input schema already describes the symbol parameter with examples. The tool description adds a few extra examples (SHEL.L, ^IXIC) but does not add meaning beyond what the schema provides. 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 uses a specific verb ('returns') and clearly states the resource: current price and market data for global stocks, indices, and ETFs. The examples (AAPL, ^GSPC, etc.) and explicit mention of worldwide coverage differentiate it from sibling tools like get_bist_price or get_crypto_price.

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

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

The description implies when to use the tool (for global stocks/indices/ETFs) through its wording and examples, but it never explicitly mentions alternatives or when not to use it. There is no 'use X instead of Y' guidance, so it relies on the agent to infer from sibling names.

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?

No annotations are provided, so the description carries the full burden. It discloses the data source (doviz.com tahvil bülteni), which is useful provenance, but does not describe update frequency, freshness, units, or what happens on source unavailability. For a data-fetching tool with no annotations this leaves a meaningful gap.

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 first defines what is returned, the second names the source. Nothing extraneous and the primary payload is front-loaded.

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

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

A zero-parameter, no-output-schema tool so requirements are modest, but the description omits units, update cadence, and fallback behavior. Source attribution partially compensates but the definition is only minimally complete for an agent to trust the data.

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?

Zero parameters, so the baseline is 4. There are no parameters to document, and the description correctly implies a no-argument retrieval.

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 (döndürür/returns) and resources (10-year Turkish government bond yield and the benchmark/reference 2-year bond yield). The term 'gösterge' with parenthetical clarification (referans/2 yıllık) makes it distinguishable from generic bond-yield siblings.

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

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

No explicit when-to-use guidance versus siblings like get_policy_rate or get_tcmb_snapshot. Usage is only implied by the resource name; the agent must infer that this is for Türkiye sovereign bond market yields.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully discloses the historical ECB/Frankfurter source and the 1999-onward range, but it does not mention return format, business-day behavior, holidays, or 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?

The description is two short sentences with no filler. It front-loads the core function and then adds the historical data scope, making it efficient and easy to parse.

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

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

The tool is simple and the schema covers all required parameters, but with no output schema the description should clarify what exact value or structure is returned. It only says 'exchange rate,' omitting return format and edge cases like weekends or unsupported dates.

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 each parameter already documented. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states that the tool returns an exchange rate for a specified date and identifies the data source as historical ECB/Frankfurter data. This distinguishes it from current-rate or crypto/stock tools, though it does not explicitly name sibling alternatives.

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 that this tool is for historical exchange rates and references a specific data source and date range. However, it does not explicitly state when to prefer this over get_exchange_rate or convert_currency, nor does it mention exclusions.

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

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

With no annotations, the description must carry behavioral disclosure, and it does add meaningful provenance (World Bank, TÜİK-sourced) and series nature (annual average, not monthly). It does not cover return format, error behavior, or rate limits, so it is adequate but not rich.

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 purpose before the source and series detail. No filler, though the source detail borders on being reference metadata rather than invocation 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?

For a single-parameter read tool with full schema coverage and no output schema, the description covers purpose, provenance, and series frequency adequately. Only the return shape is unspecified, which is a minor gap given the tool's simplicity.

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% for the single 'periods' parameter, which already documents range and default. The description adds nothing beyond the schema, 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?

States a specific verb (döndürür) and resource (Türkiye TÜFE/CPI inflation data), and goes further by naming the source and indicator code (FP.CPI.TOTL.ZG). It does not explicitly differentiate itself from siblings like get_macro_indicators, so it falls short of a 5.

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

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

Usage is implied rather than stated: an agent can infer this is the tool for annual Turkish CPI data, and 'Yıllık ortalama seridir' usefully signals the frequency. There is no explicit when-to-use, when-not, or alternative (e.g. get_macro_indicators) 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?

No annotations are provided, so the description carries the full behavioral burden. It does add real value by disclosing data provenance (World Bank + FRED), which implies annual, lagged official statistics rather than live market data. It stops short of stating update frequency, latency, or coverage limits per country.

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

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

A single dense sentence with the resource and default country front-loaded, followed by the indicator list and the source attribution. Nothing is padded, though the source sentence could arguably be folded in more tightly.

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 no annotations, the description does the right thing by enumerating the returned indicator set, so an agent knows what payload to expect. Combined with the schema's note that World Bank data is annual, coverage is nearly complete; only rate-limit/permission behavior is unaddressed, which is low-risk for a read-only data lookup.

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

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

Schema description coverage is 100%, so both parameters (years, country) are already documented in the schema, including the ISO-3 constraint and the annual-data caveat. The description adds only the 'default: Türkiye' hint, which is already mirrored by the schema default of TUR. 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+resource ('Bir ülkenin temel makroekonomik göstergelerini döndürür') and enumerates exactly which indicators come back (GDP growth, per-capita GDP, inflation, unemployment, current account, reserves, exports/imports). It does not explicitly differentiate itself from siblings like get_inflation_data or get_market_indicators, but the indicator list makes the scope clear.

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

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

Usage is only implied: the agent can infer this is the country-level macro overview tool and that the default is Türkiye. There is no explicit when-to-use, when-not-to-use, or pointer to overlapping siblings such as get_inflation_data (which likely returns more granular inflation series).

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that all indicators arrive in a single call ('tek çağrıda') and that it is a read-style data retrieval, but it omits auth requirements, data freshness/update frequency, and any failure 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?

Two tightly written sentences: the returned contents are front-loaded and the analysis purpose follows immediately. No filler 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?

With no input schema, no output schema, and no annotations, the description compensates reasonably well by enumerating the exact indicators returned, so an agent knows what to expect. It falls short only on not disambiguating against the overlapping macro/bond siblings.

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 of 4 applies. No parameter confusion is possible here.

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 ('döndürür') and resource ('makro piyasa göstergeleri'), and enumerates the exact contents (VIX, US 13w/5/10/30y yields, DXY). That enumeration partially distinguishes it, but it never names or contrasts with the close sibling get_macro_indicators (or get_gov_bond_yields), so an agent cannot be fully sure which tool to pick.

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 states a use context ('piyasa risk iştahı ve getiri eğrisi analizi için'), which implies when the tool is appropriate. However, there is no explicit when-not guidance and no reference to overlapping siblings such as get_macro_indicators, leaving the routing decision to inference.

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

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

With no annotations the description carries the full burden; it discloses the data source (Yahoo Finance screener) and the read-only nature implied by "döndürür", which is useful behavioral context. However it says nothing about rate limits, caching/freshness, auth needs, or how many/which regions are actually supported.

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 compact sentences with the resource description front-loaded and the usage note trailing. No filler, though the enumerated list slightly overlaps the schema's enum values.

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 3-parameter read tool with 100% schema coverage but no output schema and no annotations, the description covers what it returns at a high level but never describes the return shape (tickers, prices, change %), pagination, or behavior across regions, leaving gaps an agent would need to probe.

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 enum for screen is fully documented, so the schema does the heavy lifting. The description restates the screen categories in prose but adds no syntax, format, or constraint detail beyond what the schema already provides — baseline 3.

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

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

States a specific verb (döndürür/returns) and resource (hazır hisse listeleri / ready-made stock lists), enumerating the concrete list types: day gainers/losers, most actives, tech growth, value. This makes the tool distinguishable from most siblings, though it does not explicitly differentiate itself from the overlapping get_trending_stocks.

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?

"Piyasa taraması ve fırsat keşfi için kullanılır" gives an implied use case (market screening and opportunity discovery) but names no alternatives and states no when-not conditions, even though siblings like get_trending_stocks or get_market_summary could plausibly be chosen instead.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses only that the data is 'anlık' (instant/real-time), implying a read-only live snapshot, but says nothing about refresh cadence, data source, authentication, or failure behavior. For a tool with zero annotation coverage this 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?

A single, front-loaded sentence that names the exchange, the indices, and the payload types with no filler. It is efficient, though the parenthetical stock categories are slightly loose phrasing rather than a crisp scope statement.

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 parameters and no output schema, the description sensibly enumerates what the response contains (index levels plus notable stock prices and changes). That is close to complete for a trivial no-arg read tool; only the routing versus sibling index tools is missing.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies a no-argument call by describing a fixed set of indices and stock categories rather than any filterable 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?

The description names a specific resource (Borsa İstanbul market summary) and enumerates its contents: XU100/XU030/XU050 indices plus key banking and industrial stocks with current price and change. That is a clear verb+resource statement an agent can act on. It does not, however, distinguish itself from siblings like get_bist_indices or get_bist_price, which plausibly overlap.

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 choose this summary over get_bist_indices, get_bist_price, or get_market_movers. The reader must infer that this is a broad snapshot rather than a per-symbol lookup. No exclusions, prerequisites, or alternatives 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?

There are no annotations, so the description must carry the behavioral burden. It clearly conveys a read-only price lookup and the multi-currency batching behavior, but it does not mention rate limits, invalid coin ID handling, data source, or response format. For a simple public price tool this is adequate but not rich.

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 with the core behavior front-loaded and a concrete example in the second sentence. No filler or repetition of schema content.

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

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

For a simple two-parameter tool with no nested objects and full schema coverage, the description plus schema is sufficient to call it correctly. A minor gap is the absence of any return-shape description, but the output is simple enough to infer from the purpose.

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 parameters are already documented. The description's example reinforces coinIds and vsCurrency values (TRY), but it adds no semantic detail beyond what the schema provides, such as accepted currency codes or the maxItems limit.

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 ('döndürür' / returns), names the resource (multiple cryptocurrency prices), and scopes the behavior to a single query. The example with bitcoin, ethereum and solana in TRY makes the tool's purpose unmistakable and implicitly distinguishes it from the single-coin sibling get_crypto_price.

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

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

The description implies the use case: retrieve several crypto prices at once instead of making separate calls. However, it never explicitly names an alternative (e.g., get_crypto_price for a single coin) or states when not to use this tool, so the guidance relies entirely on inference.

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

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

No annotations are provided, so the description carries the full disclosure burden. It only adds provenance ('Kaynak: TCMB resmi web sitesi faiz oranları tablosu') and says nothing about data freshness, refresh cadence, pagination, or the shape of the returned time series for what is essentially a historical-read tool.

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

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

Two short sentences, front-loaded with the purpose followed by the data source. No filler, though the second sentence is essentially citation metadata rather than 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?

For a single-optional-parameter read tool with no output schema, the description covers what is returned well enough. However, with no annotations and several near-duplicate TCMB/rate siblings, the absence of routing guidance leaves a real gap an agent cannot resolve from the description 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 100%, so the single 'history' parameter (default 20, max 58) is fully documented in the schema. The description adds no meaning beyond that, making 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?

States a specific verb (döndürür) and resource (TCMB 1-week repo policy rate) plus the historical changes it also returns. It does not, however, differentiate itself from close siblings such as get_tcmb_rate or get_historical_rate, which an agent could easily confuse with this 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?

There is no statement of when to use this tool versus the many overlapping siblings (get_tcmb_rate, get_historical_rate, get_tcmb_snapshot). The agent is left to infer the distinction, and no prerequisites or 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?

With no annotations, the description must carry the behavioral burden. It does disclose the returned payload shape (OHLC + volume), which is useful, but says nothing about rate limits, error behavior (e.g., invalid symbol), or truncation when limit/period conflict. Adequate but not rich.

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 that front-load the return type and follow with purpose and examples. No filler, though the example list is partly redundant with the schema's symbol description.

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

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

For a 6-parameter data-retrieval tool with no output schema and no annotations, the description covers what is returned and roughly how to shape input, but does not explain the return record structure, ordering, or behavior when both startDate and period are supplied (only the schema hints at precedence).

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 every parameter (including the '.IS' auto-append hint and the startDate/period precedence) is already documented in the schema. The description repeats the symbol examples but adds no semantics beyond structured fields, 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 and resource: returns historical OHLC plus volume for a stock, and scopes it to BIST or global symbols. That is enough to distinguish it from sibling tools like get_stock_price-type calls, though it never explicitly contrasts with get_bist_price/get_global_stock_price.

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?

'Used for technical analysis and chart drawing' gives a usage context, and the sample symbols clarify input expectations. However, it never states when to prefer this over get_technical_indicators, get_bist_price, or get_fundamentals, so alternative selection is left to inference.

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

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

With no annotations provided, the description carries the full disclosure burden. It says the tool returns official daily buying/selling rates from TCMB in TRY, but it does not cover update frequency, supported currencies beyond examples, or response structure. This is moderate transparency for a simple read 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 sentences with no filler. The core return behavior is front-loaded in the first sentence, and the Frankfurter comparison in the second is a concise and effective differentiator.

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

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

For a single-parameter tool with no output schema and no annotations, the description tells an agent what source, what rates, and what currency unit are involved—sufficient for selecting and invoking the tool. The lack of an explicit output format is a minor gap given the operation's simplicity.

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 description does not add additional meaning to the currencyCode parameter beyond what the schema already documents. The baseline 3 applies because the schema carries the parameter burden.

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

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

The description explicitly states the action ('döndürür'), the resource (TCMB official daily bulletin), and the content (buying/selling rates in TRY). It also distinguishes the tool from Frankfurter by its official bid/ask separation, which sets it apart from sibling exchange-rate tools without needing to inspect their schemas.

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

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

The second sentence positions this tool against Frankfurter, indicating it is the right choice when official TCMB bid/ask rates are required. This provides clear context, though it does not explicitly name a sibling tool or state 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?

With no annotations, the description carries the full behavioral burden. It implies read-only retrieval and freshness via 'anlık' (instant/live snapshot), which is meaningful context, but discloses nothing about caching, update delay, rate limits, or auth requirements.

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 padding, with the resource scope front-loaded and the use case trailing. The enumerated indicator list is dense but each item is doing differentiating work.

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?

No output schema exists, yet the description compensates by listing nearly every returned field, so an agent knows what comes back. It falls short on return formatting and units (e.g. how currencies and the gold price are expressed) and on staleness characteristics.

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 of 4 applies. There is no parameter semantics to add beyond what the empty schema already conveys.

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 ('döndürür' / returns) and enumerates the exact resource contents: main FX rates (USD/TRY, EUR/TRY, GBP/TRY, CHF/TRY, EUR/USD), TCMB policy rate, US 10Y yield, and gram gold. The multi-indicator bundle scope clearly separates it from single-purpose siblings like get_tcmb_rate or get_exchange_rate.

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 closing clause ('Hızlı "Türkiye nasıl gidiyor" özeti için') gives one implied use case, so guidance exists but is thin. It never names an alternative (e.g. use get_tcmb_rate for only the policy rate) or states when this tool should not be used, leaving overlap routing to inference.

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

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

No annotations are provided, so the description carries full behavioral burden. It mentions returning values and a signal commentary but does not disclose rate limits, authentication requirements, compute constraints, or what the signal commentary contains. This is a significant gap for a computation-heavy tool.

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

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

The description is two concise sentences plus a brief example. It is front-loaded with the core purpose and indicator list, though the signal commentary detail could be better integrated. No wasted words.

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

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

Given the tool has no output schema and no annotations, the description should explain the return format more. It briefly mentions returning indicator values and a signal commentary but doesn't specify the structure, leaving ambiguity for an agent. Parameter details are fully covered by the schema, but behavioral context is incomplete.

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

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

Schema coverage is 100%, so the schema fully documents all five parameters including defaults, enums, and descriptions. The description adds virtually no parameter-specific information beyond what is already in the schema. Baseline 3 is appropriate when 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?

The description states a specific verb+resource: computes technical indicators from OHLC history. It enumerates the exact indicators (RSI(14), SMA(20/50/200), EMA(12/26), MACD, Bollinger, ATR(14)) and gives symbol examples, clearly distinguishing it from siblings like get_stock_history which return raw data.

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

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

The description specifies the input (OHLC history) and the output (indicator values + current signal commentary in the last N bars), implying when to use it. It provides example symbols but does not explicitly state when to choose this tool over get_stock_history or get_market_indicators, nor any exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the shape of the return content (price and change information), which is useful, but it says nothing about read-only safety, rate limits, ordering criteria for 'trending', or how recency is determined. That is a moderate gap for a no-annotation tool.

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

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

Two short sentences, zero filler, with the core purpose front-loaded and the example following as supporting detail. Nothing could be removed without losing 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 a fully documented schema and no output schema, the description covers purpose, scope, and the nature of the returned data. The main missing piece is how 'trending' is ranked and how this differs from the market-movers 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?

Schema description coverage is 100%, with both count and region fully documented (including bounds and an example list of region codes), so the schema already does the heavy lifting. The description only echoes the region concept without adding format or constraint detail beyond it.

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 (döndürür) and resource (en çok trend olan hisseler) scoped to a region, and even gives a concrete example (TR → BIST). It does not, however, differentiate itself from close siblings like get_market_movers or get_market_summary, which an agent could easily confuse with 'trending'.

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: 'trending/interested stocks in a region' suggests a discovery use case, and the TR/BIST example hints at regional scoping. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as get_market_movers for a different kind of popularity ranking.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that it returns multiple data fields (price, change, bid/ask, volume) but doesn't mention pagination behavior, rate limits, authentication requirements, or the format of the response. For a read-only market data tool, this leaves significant gaps.

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

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

The description is two sentences and front-loads the core purpose (returning VİOP contract data). It efficiently includes a filter example without excess verbosity. Slightly compact but could benefit from clearer separation of usage 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?

Given no output schema and no annotations, the description should ideally cover more about return values and usage scenarios. It states what data fields are returned but lacks details on response structure, pagination, or error behavior. It's adequate but incomplete for a tool with zero structured behavioral hints.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (limit and search) thoroughly. The description adds an example contract code ('F_X10XB1026' or 'X10') which helps illustrate the search parameter's expected format, adding marginal value beyond the schema. However, it doesn't elaborate on the limit parameter or default behavior beyond what the schema states.

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

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

The description clearly states it returns price, change, bid/ask and volume information for VİOP (futures & options) contracts. This is a specific resource and verb combination that distinguishes it from siblings like get_stock_history or get_bist_price. However, it doesn't explicitly differentiate from other price-fetching tools in the sibling list, hence not a full 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 alternatives like get_bist_price or get_stock_history. The description mentions a filter example but doesn't explain when filtering is appropriate or when to leave it blank for all contracts. No explicit when-to-use or when-not-to-use context is provided.

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?

No annotations are provided, so the description carries the full behavioral burden. It conveys that this is a name/symbol lookup returning matching tickers (with examples), but discloses nothing about permissions, read-only nature, result ordering, or behavior when nothing matches.

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 with the core purpose front-loaded, followed by scope and then examples. The examples earn their place by clarifying intent, though the scope sentence could be 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?

For a simple 2-parameter search tool with a fully documented schema and no output schema, the description covers purpose, scope, and output examples well. It only falls short on explicit usage routing and on behavioral details like return format or empty-result handling.

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

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

Schema description coverage is 100%: both query and limit already carry their own descriptions with format hints and a default. The description adds illustrative query values but no semantics beyond what the schema documents, 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?

States a specific verb+resource (search an exchange-traded asset by symbol or name to find the correct ticker) and reinforces it with concrete mappings ('ASELSAN' → ASELS.IS). It is implicitly distinguishable from the sibling get_* price/history tools since it is the only discovery/lookup tool, but it never explicitly frames itself that way.

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

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

The description names the asset classes it covers (BIST stocks, global stocks, ETFs, indices), which implies when it applies, but gives no explicit when-to-use vs alternatives, no exclusions, and no guidance such as 'use this to resolve a ticker before calling get_stock_history'.

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