ÖSYM sınav takvimi

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation with potentially changing data. The description adds valuable behavioral context: the default filtering to future dates, the timezone (Turkey time), and the fact that dates come from ÖSYM's own announcements. It doesn't mention pagination or rate limits, but for a read-only calendar tool, the key behaviors are disclosed.

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 compact and front-loaded: it states the resource, lists the exam types, explains the default behavior, and notes the timezone in three sentences. Every sentence earns its place, and the bilingual structure (Turkish with English summary) serves the likely user base without being verbose.

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 has an output schema, so return values are already documented. The description covers the key context: what data is included, the default filtering, the optional filter, and the timezone. It doesn't mention whether the data is cached or how frequently it updates, but for a read-only calendar with openWorldHint, the essential information is present. The only minor gap is not explaining what 'adımlar' (steps) means in the output, but the output schema likely covers that.

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 all three parameters (ara, limit, yalnizGelecek). The description adds the default value for yalnizGelecek (true) and clarifies that 'ara' filters by exam name, which is slightly redundant with the schema but reinforces the semantics. The description doesn't add significant new meaning beyond the schema, so 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 tool provides ÖSYM's annual exam calendar with specific exam types (YKS, KPSS, ALES, YDS, DGS, TUS, MSÜ) and date categories (application, late application, exam, result, preference). It also distinguishes itself from siblings by naming the specific authority and domain, which is unique among the listed tools.

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 explains the default behavior (only future steps) and mentions the optional 'ara' filter for exam name, giving the agent clear context on how to narrow results. It doesn't explicitly state when to use this tool vs alternatives, but the domain is so distinct (exam calendar vs. economic data, weather, legal texts) that the usage context is clear. It could be improved by noting that this is for exam dates only, not other ÖSYM services.

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