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?

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?

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 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 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?

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 provided, the description carries the full burden. It usefully discloses the data source (FRED), the original provider (TUIK), and the metric (annual percentage change), making the behavior reasonably transparent. It does not mention update frequency or data lag, but for a simple read-only data fetch this is a minor 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?

The description is two compact sentences with no filler. The primary purpose is front-loaded first, and the source/metadata detail is placed second, making it easy for an agent to parse quickly.

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

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

The description is sufficient for basic invocation: it defines what data is returned and its source. However, there is no output schema and the description does not specify the response structure (e.g., date-value pairs), which leaves some ambiguity about what the agent should expect in 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 description coverage is 100%, and the only parameter, 'periods', is already well documented in the schema with range and default. The tool description adds no additional parameter-level semantics, 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 the verb ('returns') and the resource ('Turkey CPI inflation data'), and specifies the exact metric: annual percentage change sourced from TUIK via FRED. This makes it immediately distinguishable from the sibling tools, which cover exchange rates, currency conversion, crypto, BIST, and global 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?

The usage context is implied by the purpose: use this tool when Turkish CPI inflation data is needed. However, it does not explicitly state when to use it over alternatives, nor does it name any sibling tool or provide exclusion criteria.

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?

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.