EVDS serileri (bir veri grubunda)

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

Annotations already cover read-only and open-world behavior, so the bar is lower. The description adds useful behavioral context: it returns series code, name, frequency, and labels, supports optional name filtering, and explicitly warns that EVDS_API_KEY is required. This goes beyond the structured annotations without contradicting them.

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 with the main purpose, followed by a useful concrete example and auth requirement. The Turkish/English bilingual repetition adds slight redundancy, but the overall length is reasonable and every substantive point earns its place.

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 list tool with a full output schema and read-only annotations, the description is largely complete: it names the returned fields, the optional filter, the required API key, and provides an example. It does not explain pagination details, but the schema covers the limit parameter and the output schema covers return structure.

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 baseline is 3. The description does add meaning by explaining that optional ad filtering corresponds to the 'ara' parameter and by giving a concrete example group/series mapping, but it does not add substantial parameter semantics beyond what the schema already documents.

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 action and resource: listing the series contained in a single EVDS data group, including code, name, frequency, and labels. It also hints at differentiation from the sibling evds_seri by noting the series code is what evds_seri needs, so an agent can distinguish the plural list tool from the singular lookup tool.

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 context is clear: use this when you need the series available within a specific EVDS data group, optionally filtered by name. It points to evds_seri by mentioning 'evds_seri için', but it does not explicitly state conditions such as 'use evds_seri when you already have a series code'.

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