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

The annotations already declare readOnly, idempotent, non-destructive and openWorld, so the description only has to add depth. It does so by disclosing the bounds of historical data and the Europe/Istanbul timezone, which matters for interpreting the returned timestamps. It stops short of explaining empty-range behavior or error responses.

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

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

The description is short and front-loads the core behavior followed by data-availability constraints. The full English restatement of the final sentence is somewhat redundant, given that the first sentence is already Turkish, which costs it a perfect score.

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

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

For a read-only history tool with no output schema, the description covers what is returned (OHLC), the granularity options, the coverage window and the timezone. Only edge behavior such as out-of-range dates or empty results is left unstated.

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

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

With 100% schema description coverage, the schema already documents all four parameters, including the date pattern, the period enum and example symbols. The description reinforces the YYYY-MM-DD format and the timezone, but it adds no syntax or constraint detail beyond what the schema already says. A 3 reflects this baseline.

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

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

The description names a specific resource and verb ('returns daily or hourly open/high/low/close history') and states the data source ('harem kaynağı'), which distinguishes it from the sibling 'get_prices'. It does not explicitly name the sibling tools as alternatives, 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 through data-availability limits: daily data starts 4 Oct 2026, hourly data covers only the last 45 days. That steers an agent toward the right period value, but there is no explicit statement about when to pick this tool over 'get_prices' or what to do if the requested range falls outside the window.

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