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

With no annotations, the description carries the burden and does disclose the important behavioral traits: the data comes from an official PDF and has known gaps (midterm dates absent), plus a terminology mapping ('bitirme sınavı' = final). It omits how results are shaped or whether failures/parse errors are surfaced, keeping it short of a 5.

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?

Purpose is front-loaded in the first line, data caveats follow immediately, and the Args block is scannable one-liners. No sentence is padding — even the 'ozet' note earns its place since there is no output schema.

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 five-parameter read tool with zero annotation coverage and no output schema, the description covers purpose, data limitations and every parameter's meaning. It falls short of complete by not describing the returned event record shape beyond the 'ozet' summary field and by leaving kategori's allowed values unexplained.

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 0%, so the description must compensate, and it does: sorgu (substring of event name), donem ("guz"/"bahar", empty = both), kategori (event group filter), yaklasan (future dates only, nearest first) and sinir (max rows) are all explained. The one gap is that the seven kategori enum values present in the schema are not enumerated or explained.

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 the exact resource and scope: the İÜ associate/undergraduate 2026-2027 academic calendar, sourced from the official PDF. Combined with the argument list it is clear this queries calendar events, though no explicit verb ('sorgula/listele') is used and no sibling tool is named for contrast.

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?

It provides a genuine usage caveat — midterm exam dates are set by units, so the calendar only holds the announcement deadline — which implicitly tells the agent when this tool will not answer a question. However, there is no explicit routing to or away from siblings such as duyurular_listesi or ders_programi.

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?

No annotations are provided, so the description carries the full burden. It implies a read-only lookup and lists the kinds of information returned, plus the default program behavior, but it does not explicitly state that the operation is read-only, whether authentication is required, or how multiple matches behave.

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 what the tool returns and then documents the arguments. Every sentence carries useful information, with no redundant 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?

For a simple two-parameter lookup with no annotations and no output schema, the description provides enough context to call the tool correctly, including argument semantics, the default program, and the content areas returned. Minor gaps remain around result shape and behavior when multiple courses match.

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 0%, so the description must compensate, and it does: both parameters are explained with examples, including that ders accepts a course code or name substring and that program accepts a program-name substring with a default fallback. It stops short of specifying matching sensitivity or handling of multiple matches.

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 identifies a specific resource and operation: retrieving an EBS course syllabus, with the returned content listed as code, ECTS, instructor, purpose, weekly topics, and assessment. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as ders_programi or mufredat.

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 by the purpose and by the parameter examples, especially the note that program defaults to Computer Engineering when empty. However, there is no explicit guidance about when to choose this tool over ders_programi or mufredat, and no stated 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?

With no annotations, the description carries the burden, and it does disclose meaningful behavior: it returns only links and announced notes rather than schedule data itself, and only the BBTF page layout is currently supported. It says nothing about failure behavior when an unsupported faculty is passed, or about the shape/size of the returned links.

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?

Front-loaded with the core statement, followed by an important caveat, then args. Roughly three dense sentences/sections with little waste; the prose caveat sentence is slightly long but each clause adds information.

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 two-optional-parameter read tool with no output schema and no annotations, the description covers purpose, return nature (links + notes), the single-dependency limitation, and both parameters. What remains missing (link format, empty-result behavior) is minor at this complexity level.

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 0%, so the description must compensate, and it does: fakulte is documented as defaulting to bilgisayar with only BBTF layout supported, and program is documented as a name-substring filter with a concrete example ('yapay zeka'). Minor gap: no guidance on matching case or partial-word behavior.

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 resource (the faculty's current course schedule) and what it returns: program/class-based table links plus important notes. It also clarifies the tool is only a pointer to externally hosted tables, which sharpens its identity. It does not, however, explicitly distinguish itself from close siblings like ders_bilgisi or mufredat.

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 the args explanation (empty fakulte defaults to bilgisayar/BBTF, program is a filter substring with an example like 'yapay zeka'). There is no explicit statement of when to prefer this over ders_bilgisi, mufredat, or akademik_takvim, so the agent must infer the boundary.

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?

There are no annotations, so the description must carry the load. It usefully states defaults ('bilgisayar' when fakulte is empty, student type by default) and a range not in the schema (adet 1–100), but it never says whether the call is read-only, what auth/rate conditions apply, or what an item contains.

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?

Purpose is front-loaded in one sentence, followed by a compact Args block where each line adds distinct value. The docstring-style layout is slightly verbose but nothing is 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?

For a simple 4-parameter read tool with no annotations and no output schema, the description supplies defaults, ranges, enum semantics, and filter behavior. The only gap is that the shape of returned records (fields, dates, links) 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 0% schema coverage, the description carries parameter meaning entirely — and does it well: it explains each 'tur' enum member, states the 'adet' range, defines 'ara' as matching title or özet, and clarifies that 'fakulte' accepts a name fragment and falls back to computer science when empty. This is meaningfully more than the bare 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 first line names a specific resource (İÜ faculty announcements, news, and events) and even states the default scope (Computer and Informatics Technologies Faculty). The verb is implicit in the tool name (list) rather than the description, and no sibling such as fakulte_pagesi is named, so it is clear but not disambiguated.

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 defines the categories available via 'tur' (student announcements, faculty announcements, news, events), which implies when each is appropriate, but it never states when to choose this tool over siblings like fakulte_bilgisi or akademik_takvim. Usage must be inferred.

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?

No annotations exist, so the description carries the full burden, and it does disclose the two fallback behaviors (empty konu yields the whole page list, empty fakulte defaults to bilgisayar) — information not present in the schema, whose defaults are just null. However, it never clarifies whether matching pages are returned as a list of links/titles or as page content, and says nothing about result size or format.

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?

Two short blocks: a purpose line followed by a clearly labeled Args section, with the discovery hint placed where it matters. The trailing ellipsis in the opening line is slightly loose but costs nothing.

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 two-parameter, zero-required lookup with no output schema and no annotations, an agent has everything needed: what the tool covers, how to discover available topics, and the faculty default. No structural gap remains beyond fine-grained return-format detail, which is minor for this tool type.

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 0%, so the description must compensate, and it does: konu is explained as a menu search term with example values, and fakulte is given as a concrete enumerated list plus its default. The remaining gap is that the enum is prose-only rather than enforced, and matching semantics (exact vs. substring) for konu are unstated.

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 (faculty site information pages) and enumerates representative content types (internship rules, FAQ, Erasmus, exchange programs), which clearly separates it from topic-specific siblings like yemekhane_menusu or akademik_takvim. The retrieval verb itself is only implied by the noun phrase, so it falls short of the explicit verb+resource pairing a 5 requires.

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?

It gives concrete operating guidance: calling with an empty konu returns the full page list and is recommended first to discover what can be asked. That is a clear usage context, but no when-not conditions or explicit alternatives among the sibling tools are stated.

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?

With no annotations, the description carries the full burden and does disclose real behavior: offline operation, AKTS/ECTS-weighted averaging, the default 4.0 scale (AA 4.0 … FF 0), and that results are advisory rather than official. It omits edge-case behavior (unknown letter grades, rounding, what happens if only one of onceki_akts/onceki_gno is given), which keeps it from a 5.

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 output behavior and offline property are front-loaded in the first two lines, then the weighting/scale rules, then a per-argument block. Every sentence carries information an agent needs; there is 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?

For a 4-parameter, no-annotation, no-output-schema computation tool, the description covers inputs, the weighting rule, the optional new-GPA output, and the official-vs-advisory caveat. It lacks only numeric precision/rounding details and error behavior for malformed grade values.

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 0% and `dersler` is an untyped object array, so the description is the only source of truth — and it delivers with concrete examples: [{"ad": "Veri Yapıları", "akts": 6, "not": "BB"}] and {"AA": 4, "BA": 3.5, ...}. It also defines onceki_akts and onceki_gno as prior cumulative credits and GPA, adding meaning the bare schema cannot.

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 first sentence states a specific verb and resource: computes the semester average from letter grades and, optionally, a new cumulative GPA. None of the sibling tools (yemekhane_menusu, akademik_takvim, ders_bilgisi, mufredat, etc.) do computation, so the tool is easy to tell apart without opening the schema.

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 says the tool works offline and tells the agent to pass `olcek` when the regulation's coefficients differ from the default 4-point table, plus a clear boundary: 'Resmî hesap için OBS/transkript geçerlidir.' It stops short of an explicit 'use this when…' statement, but the context for use is unambiguous.

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?

No annotations exist, so the description carries the full burden. It does disclose a genuinely useful non-obvious behavior: an unset program silently falls back to Bilgisayar Mühendisliği (İngilizce), and unset filters broaden rather than error. It does not clarify whether the tool is read-only, ordering, or what happens when a program name matches nothing.

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?

One front-loaded sentence states the purpose and return content, followed by a compact Args block with one line per parameter. Every sentence earns its place and no restatement of the schema's type information is included.

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 three-parameter read tool with no annotations and no output schema, the definition covers the parameter semantics and the shape of the return (year, courses, ECTS) reasonably well. It only leaves open edge behavior — no match on program, ordering, or result size — which is minor for a curriculum lookup.

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 0% and the schema itself carries only titles and null defaults, so the Args block does all the work. It adds real meaning beyond the schema: sinif is bounded to 1-4 and means 'year', yariyil is constrained to Güz/Bahar and means semester, and program is a substring match with a documented default — none of which appears in the 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 first line names a specific resource and scope: a program's 2026-27 curriculum, returning which courses fall in which year and their ECTS. That is far more than a restatement of the name 'mufredat', and the output shape is stated. It stops short of a 5 because it never distinguishes itself from plausible siblings such as ders_bilgisi or ders_programi.

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 only implied through the parameter defaults ('boşsa hepsi', 'boşsa Bilgisayar Mühendisliği (İngilizce)'), which tell the agent what happens when it passes nothing. There is no explicit statement of when to prefer this tool over ders_programi or ders_bilgisi, and no 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?

With no annotations, the description carries the full behavioral burden, and it discloses only the source site. It says nothing about whether data is scraped live or cached, latency, rate limits, or what is returned when no menu is published — gaps that matter for a web-sourced tool.

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 purpose statement is front-loaded in one sentence and the parameter notes are a compact list. Slight redundancy between the 'Args' block and the schema titles, but each line adds a format detail, so it mostly 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 3-parameter, no-annotation, no-output-schema tool, the description should also say what a menu entry contains (dishes, calories, prices) and which timezone defines 'bugun'. It defines inputs adequately but leaves the output and edge-case behavior 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?

Schema description coverage is 0%, so the description must compensate, and it does: 'gun' accepts 'bugun', 'yarin' or YYYY-MM-DD; 'gun_sayisi' is the count of days (1-7) from the start day; 'ogun' lists the meal categories. The accepted string literals for 'gun' are genuinely new information the schema lacks; only the default values are left to the 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 first line names a specific resource — the İÜ SKS student cafeteria menu — and cites the source domain (sks.istanbul.edu.tr), so the agent knows exactly what data it returns. It is clearly distinct from the sibling tools (academic calendar, announcements, course info), though the retrieval verb is only implied by 'menüsü'.

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?

No explicit when-to-use or when-not-to-use guidance is given; usage is implied by the 'Args' list. In fairness there is no sibling offering campus food data, so no alternative needs to be named, but nothing states prerequisites or what happens on holidays when no menu exists.

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