NobetciEczane.org

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context: it specifies straight-line distance ranking, the exact fields returned, and instructs the agent to provide pageUrl to the user for additional details. No contradictions with annotations are present.

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 efficient sentences: the first front-loads purpose, scope, sorting, and return fields; the second gives a clear usage instruction. No unnecessary words 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?

For a simple lookup tool with full schema coverage, rich annotations, and an output schema, the description provides everything needed: it clarifies what is returned, how results are ordered, and what to do with the pageUrl. No gaps remain for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema itself fully documents all three parameters (enlem, boylam, adet) including types and constraints. The description merely restates that latitude/longitude are given and does not add any extra meaning or format guidance beyond the schema; 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 states a specific verb ('döndürür') and resource ('en yakın nöbetçi eczaneler'), specifies the scope (Türkiye ve KKTC), the input basis (enlem/boylam), the sorting (yakından uzağa) and the returned fields. It is clearly distinguishable from a generic list tool by its reliance on coordinates and distance ranking, but it does not explicitly reference the sibling tool to reinforce the distinction.

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 by stating it requires latitude/longitude and returns nearest pharmacies, and it gives a post-call instruction to share pageUrl for phone/hours/directions. However, it offers no explicit guidance on when to use this tool instead of the sibling 'nobetci_eczane_listele' or 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely non-schema behavior: the duty day rolls over every morning at 09:00 Türkiye time, which is critical for freshness expectations, and it points to pageUrl for supplementary data.

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, each carrying distinct payload: what it returns, how to use the results, and the duty-day refresh cutoff. Front-loaded with the capability and no filler.

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

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

Output schema exists so the field list is somewhat redundant, but the freshness caveat (09:00 rollover) and the pageUrl delegation note are the right things to include. Only the missing sibling routing keeps it from being fully 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?

Schema description coverage is 100% — il accepts name/slug/plate code and 'kktc', ilce is optional, limit is 1-100 with default 30 — all documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('nöbetçi eczaneleri döndürür') plus coverage scope (81 provinces of Türkiye and KKTC) and the exact fields returned (name, province, district, address). It does not name or contrast with the sibling en_yakin_nobetci_eczane, so the agent must infer that this is the province/district listing rather than the nearest-pharmacy lookup.

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?

Gives clear operating context: ilce is optional and empty means province-wide, and the result-usage directive 'use pageUrl for phone/hours/directions' tells the agent what to do with each record. It stops short of an explicit exclusion ('if you have coordinates use en_yakin_nobetci_eczane'), which is the one guidance gap.

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