İzmir hal fiyatları: sebze-meyve ve balık, günlük (asgari/azami/ortalama)

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

Beyond the readOnly/openWorld annotations, the description discloses a critical behavioral edge case: on days without a bulletin (Sunday, holidays, some fish days), it returns an empty list. It also reveals default behavior for `tur` and `tarih`, which helps the agent predict results without making a test call.

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 content is valuable, but the description is structured as a long run-on sentence, switches between Turkish and English with some redundancy, and places all parameter guidance in a dense block. A bulleted or more clearly segmented structure would make it easier 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?

With an output schema present, the description does not need to explain return structure. It covers source, scope, parameter defaults, output fields, and the empty-list case, so an agent has everything needed to invoke the tool correctly and interpret common outcomes.

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 schema documents `ara` and `tarih` but not `tur`, and the description compensates by explaining all parameters: `tur` defaults to `sebzemeyve` or `balik`, `tarih` uses YYYY-AA-GG and defaults to today, and `ara` filters by product name. This adds default values and usage nuance beyond the raw schema.

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

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

The description clearly names the resource: a daily price bulletin from İzmir's wholesale produce and fish markets, listing product, type, unit, minimum, maximum, and average TL prices. It is specific enough to be immediately distinguished from unrelated sibling data tools, and it emphasizes that this is the only official daily food-price series.

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 intended use clear: retrieve daily wholesale produce or fish prices from İzmir's metropolitan municipality. It does not explicitly list alternatives or exclusion conditions, but the uniqueness claim and clear scope provide enough contextual guidance for an agent to select it over other market/financial tools.

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