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

No annotations are supplied, so the description carries the full disclosure burden. It helpfully describes the shape of the return content (topic plan text plus a file list), but says nothing about read-only safety, behavior when the course code is invalid or the page is empty, expected size of the payload, or whether authentication is required.

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?

A single compact sentence that front-loads the resource and then enumerates what is returned. Nothing is redundant and nothing is buried.

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 one-parameter read tool with a fully documented schema and no output schema, this covers what the caller gets back and what it needs to supply. The remaining gaps — overlap with read_learn_page and failure/empty behavior — are modest but real.

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% and the single parameter is documented with an example ("Ders kodu, ör. MCE350"). The description only obliquely implies a course code via "Dersin" and adds no further meaning, so the schema is doing all the work and 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?

The description names a specific resource (the course's "Ders İçeriği" page) and states exactly what it yields: the weekly topic plan text and a list of course files (PDF/PPTX). That is a concrete verb+resource, though it never differentiates itself from the nearby read_learn_page sibling, which sounds like a comparable page-reading 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?

Usage is implied by the content it returns — an agent can infer it should call this when it needs the syllabus/weekly plan or attached lecture files. There is no explicit when-to-use, no exclusions, and no naming of the obvious alternative (read_learn_page) to disambiguate between them.

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 supplied, so the description carries the burden. It does add real behavioral value by disclosing that due dates are normalized to Istanbul time and that the status field uses a controlled vocabulary (pending/submitted/graded), which tells the agent how to interpret results. It says nothing about sort order, pagination, result size, or whether archived/submitted assignments are included.

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?

A single compact sentence with the resource front-loaded and the return fields enumerated after the colon. Every clause carries information, though the field list would read slightly better as a structured enumeration than as a comma run-on.

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 no output schema and no annotations, the description must explain what comes back, and it does list the returned fields including status vocabulary and timezone. For a zero-parameter read tool this covers what an agent needs to call and interpret it. Only minor gaps remain: ordering, volume, and whether all courses or only enrolled ones are covered.

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 tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering input is needed by scoping itself to all courses. No parameter-level gaps exist to compensate for.

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 gives a specific verb (list) and resource (assignments across all courses, 'Tüm derslerin ödevleri'), and it enumerates what each item contains: title, course, status, due date, and link. That clearly separates it from siblings like list_courses and list_exams. The only gap is that the separation from list_exams is inferred rather than stated.

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 phrase 'Tüm derslerin' implies there is no per-course filtering and that the tool returns a full sweep, which is useful scoping. However, it never states when to prefer this over list_exams or course_content, and it names no prerequisites or exclusions. Usage has to be inferred from the scope wording alone.

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 supplied, so the description carries the disclosure burden alone. It does convey scope ('this semester') and the shape of the returned records, which is useful, but it never states that the call is a read-only operation, whether a login/session is required, or whether the list can be empty.

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?

A single short sentence with the core concept front-loaded and no filler. The parenthetical field list earns its place by telling the agent what comes back, though the sentence could be marginally tighter.

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 parameterless list tool with no output schema, the description covers the essential facts: which records are returned, under what time scope, and which fields each record holds. Missing only minor operational detail such as ordering or empty-result behavior.

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 tool takes no parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description adds only the implicit scoping ('this semester') that determines what the empty-argument call returns.

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 (the student's IEULearn courses for the current semester) and enumerates the returned fields (course code, name, IEULearn number), so an agent can distinguish it from list_assignments and list_exams. It does not explicitly differentiate itself from course_content, which is the nearest conceptual sibling.

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 by the phrase 'this semester'; there is no statement of when to prefer this tool over course_content or the other list_* tools, and no mention of prerequisites or exclusions. For a zero-parameter list tool the risk of misuse is low, but the routing guidance is left to inference.

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 mostly does not: it discloses nothing about authentication, whether all exams are returned or only upcoming ones, sorting, or result volume. The only behavioral hint is the UTC timezone and room field, which is thin for a tool with zero annotation coverage.

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?

A single short line with no filler, front-loading the resource and source before the field list. It is a noun-phrase fragment rather than a sentence, which slightly weakens scanability.

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 zero-parameter list tool with no output schema, the description should say what comes back and over what scope; it names the fields and the UTC convention but leaves scope and volume unspecified. Adequate but with a clear gap for an agent deciding whether to call it.

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 tool takes zero parameters, so the baseline is 4; the schema is empty and there is nothing for the description to disambiguate. The listing of returned fields (course, start/end, room) adds a little value ahead of the response.

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?

"Sınav takvimi" (exam schedule) restates the tool name list_exams rather than stating a verb and scope, but it does add the data source (analytics.ieu.edu.tr) and the returned fields, which lets an agent confirm this is the exam-calendar extractor rather than something else.

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 when-to-use guidance and no mention of alternatives such as list_courses or list_assignments, so an agent must infer that exams are distinct from courses and assignments. Nothing states whether the result is limited to the current term, a student, or the whole institution.

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 substantial work: it discloses the return format, that audio is transcribed via ASR when no captions exist, that long recordings can take minutes, and that results are cached so repeat requests are instant. Missing only error behavior and what happens when transcription fails or the recording has no audio.

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 dense sentences, with the purpose front-loaded and the second sentence packing fallback behavior, latency, and caching without a wasted word. Structure is efficient and easy to scan.

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 output schema, the description conveys the return shape, the cost/latency profile, and caching, which is most of what an agent needs to decide to call it. The notable gap is pagination: the presence of 'offset' suggests truncated transcripts, but the description never says so.

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 coverage is 100%, so all three parameters are already documented, which sets the baseline at 3. The description adds the output format example and implies that long transcripts may need to be walked through, but never explains the 'offset' parameter or when a transcript would be truncated.

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 (the timestamped transcript of a Panopto lecture recording) and even shows the output shape with '[12:34] ...'. It is clearly distinct from panopto_videos, which supplies the 'id', but the description itself never names that sibling, so the differentiation comes from the schema rather than the text.

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 implied use case (fetch the spoken content of a recorded lecture) is clear, and the fallback note about missing subtitles is useful context. However, there is no explicit when-to-use / when-not-to-use guidance and no pointer to panopto_videos as the place to obtain the record id.

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 supplied, so the description carries the full burden. It does disclose the return payload (metadata plus a watch URL), which is meaningful behavioral context, and the metadata-only nature implies a non-destructive read. However, it says nothing about permissions, authentication, empty-result behavior, or whether the watch URL is time-limited — real gaps for a tool with zero annotation coverage.

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?

A single compact sentence with the resource front-loaded and the returned fields in a parenthetical. There is no filler, though the dense parenthetical of six fields reads more like a payload spec than a purpose statement; it still earns its place given the absence of an 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 one-parameter read tool with no output schema and no annotations, the definition covers the essentials: what it fetches, for which course, and what fields come back — the field list usefully substitutes for the missing output schema. What is missing is usage routing against the substantial sibling set, which for this complexity is a modest but real gap.

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%: the single required 'course' parameter is documented in the schema with a format example (e.g. MCE412). The description says the recordings belong to the course but adds no further meaning about the parameter's accepted format or matching behavior. Baseline 3 applies because the schema already does the work.

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 — Panopto lecture recordings for a given course — and enumerates the exact fields returned (id, title, date, duration in minutes, subtitle availability, watch URL). That enumeration implicitly separates it from the sibling panopto_transcript, which returns transcript text rather than video metadata. It stops short of an explicit verb ('list'/'get') or a named sibling, so it is clear but not fully differentiated.

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?

There is no guidance on when to call this versus the alternatives in the sibling set (panopto_transcript, course_content, read_learn_page). Nothing states prerequisites, what happens when a course has no recordings, or whether transcripts require a separate call. The agent must infer usage entirely from the tool name and field list.

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 supplied, so the description carries the full burden. It does disclose two useful traits beyond the schema: the return is readable text rather than raw HTML, and the session is already authenticated. It says nothing about rate limits, error behaviour for invalid paths, redirects, or truncated/large pages, which are significant unknowns for a web-fetch 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?

Two short sentences, zero filler, with the resource and return type front-loaded and the path constraint plus examples immediately after. Every clause carries information an agent needs.

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 one-parameter read tool with no output schema and no annotations, the definition covers what matters most: what is returned (readable text), that auth is pre-handled, and which paths are legal, with examples. Only failure-mode and pagination/size behaviour are left unstated, a minor gap at this complexity.

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 coverage is 100% and the single 'path' parameter is already documented in the schema, giving a baseline of 3. The description earns an extra point by supplying two concrete path examples ('/student/courses/16911' and '/student?ann=6160'), which clarify the expected format and that query strings are permitted — meaning beyond the schema text.

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 opens with a specific verb and resource: it fetches the IEULearn student page as readable text. The '/student' path restriction further narrows the scope. It does not explicitly contrast itself with siblings like list_courses or course_content, so an agent must infer that this is the raw-page fallback, but the purpose is unmistakable.

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: the '/student'-only constraint and the example paths show which pages are valid, and '(giriş yapılmış)' signals that authentication is already handled. The description never says when to prefer this over the typed siblings (list_courses, list_assignments, course_content) or what to do for non-/student URLs, so routing between tools is left to inference.

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