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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds the clash-checking behavior, which is useful, but says nothing about how shared vs index-specific differences are reported or that this is a pure computation over existing schedule 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?

A single front-loaded sentence with no filler — the core compare action comes first and the optional clash check is appended. It is efficient, though arguably under-specified for a five-parameter tool rather than merely concise.

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?

An output schema exists so return values need not be explained, but for a tool with four required parameters and zero schema coverage the description omits the meaning and accepted forms of nearly every input. An agent could not reliably populate course_code, indexes, academic_year or semester from this text.

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% across five parameters, so the description carries the burden and largely fails it. Only the optional against_sessions ("supplied time slots") is hinted at; course_code, indexes, academic_year and the semester enum (including the "S" value) are given no meaning, format or cardinality guidance anywhere.

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 uses a specific verb ("Compare") plus the resources being compared ("shared and index-specific sessions"), which is more concrete than a restatement of the name. It does not, however, differentiate itself from the near neighbours like find_matching_indexes or get_index_schedule, so sibling disambiguation is left to the agent.

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?

"optionally check clashes with supplied time slots" implies when the against_sessions parameter is relevant, which is genuine usage context. But there is no explicit when-to-use/when-not guidance and no reference to the obvious alternatives (find_matching_indexes, get_index_schedule) that an agent would weigh this against.

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?

The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that the tool avoids supplied timetable clashes and matches day/time/lesson/week rules, which is useful behavioral context, but it does not explain how constraints interact, how uncertainty is handled, or what volume of results to expect.

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 definition is a single, front-loaded sentence with no redundant or filler language. Every clause contributes to understanding what the tool searches for and what it avoids.

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 an output schema available and rich nested schema definitions for TimeSlot, TimeWindow, SearchConstraints, and SessionRequirement, the description need not explain return values or every nested field. The one-sentence summary is broadly complete for a constrained search tool, though it leaves usage and required-parameter semantics to inference.

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?

Top-level schema description coverage is low, so the description must compensate. It loosely maps to constraints ('day/time/lesson/week rules') and against_sessions ('supplied timetable clashes'), but it does not explain the required course_code, academic_year, and semester parameters or the detailed semantics of the nested constraint fields.

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 and resource: 'Find indexes,' and states the filtering criteria as 'day/time/lesson/week rules' and 'avoiding supplied timetable clashes.' It clearly describes a constrained search operation, but it does not explicitly distinguish itself from siblings such as get_course_indexes or compare_indexes.

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: call this when you need indexes that satisfy schedule constraints and avoid clashes. However, there is no explicit when-to-use versus when-not-to-use guidance, and no alternative sibling is named.

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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds useful scope context by saying it returns *every* index with a *complete* timetable (a broad, full-expansion read rather than a paginated summary), but says nothing about authentication, rate limits, or behavior when the course/year/semester combination does not exist.

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 front-loaded sentence with zero filler. The returned scope is stated up front, so an agent can triage the tool in one read.

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?

An output schema exists, so return values need not be explained, and the description does convey what the tool fetches. It is nevertheless incomplete for a 3-required-parameter tool whose parameters carry no documentation at all, particularly the ambiguous semester enum.

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%: none of course_code, academic_year, or semester is documented anywhere. The description only vaguely implies a course identifier is involved and adds nothing about the semester enum values (1, 2, 'S'), which are especially cryptic without explanation.

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 ('Get course metadata and every index with its complete timetable'), which is clearer than a bare 'get course'. However it never differentiates itself from the sibling get_course_indexes or get_index_schedule, so an agent must infer which of the two overlapping-sounding tools to call.

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 when-to-use guidance, no prerequisites, and no mention of any alternative tool. With siblings like get_course_indexes and get_index_schedule that plausibly overlap, the absence of routing guidance is a real gap.

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 readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful scope information about what the returned index set contains (every lecture, tutorial, lab, and other session), but says nothing about permissions, result size, or pagination behavior.

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 front-loaded sentence with no filler. The verb and resource come first and the inclusion scope follows immediately, so nothing needs to be trimmed or reordered.

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?

An output schema exists, so return-format explanation is unnecessary, and annotations cover the read-only/idempotent profile. However, with three required parameters at 0% schema description coverage, the definition never tells the agent how to supply course_code, academic_year, or semester, leaving a real gap for a tool this simple.

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 description mentions none of the three required parameters. It does not clarify the course_code format, the academic_year convention, or the meaning of semester values (though 1/2/'S' is at least enumerated in the schema). With low coverage, the description should compensate but does not.

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 ('List') and resource ('indexes for a course'), then scopes the result by naming the session types included (lecture, tutorial, lab, other). It clearly distinguishes itself from schedule-oriented siblings by being a course-level index listing, though it never names an alternative tool explicitly.

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, prerequisites, or alternative routing is given. Usage is only implied by the purpose statement ('list indexes for a course'), which is adequate for a simple lookup but leaves the relationship to siblings like get_index_schedule, compare_indexes, and find_matching_indexes for the agent to infer.

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 readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds a genuinely useful behavioral constraint beyond them: only the currently published academic term is served, so historical terms are unavailable. It still says nothing about behavior when a course code is not found.

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 tight sentence with the resource front-loaded and the temporal scope trailing. No filler, though it is arguably too terse to carry the parameter burden.

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?

An output schema exists, so return values need not be explained, and the term scoping is covered. The remaining gap is the undocumented course_code format, which is the one thing an agent must get right to invoke the tool.

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% for the single required parameter course_code, so the description carries the burden. 'A graduate course's' only loosely implies that course_code identifies the course; no format, example, or case sensitivity is given.

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 (Get) and resource (a graduate course's class groups) with the scope qualifier 'currently published academic term'. The 'graduate' qualifier implicitly separates it from get_undergraduate_exam_schedule, though it never names a sibling explicitly.

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, no prerequisites, and no mention of alternatives such as get_index_schedule or get_course. The agent must infer from the name alone which schedule tool applies.

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 readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered structurally. The description adds no behavioral context beyond that — no mention of pagination, term-scoping behavior, or what happens when an index has no sessions.

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 efficient sentence with the object of the operation front-loaded, no filler. Its brevity is appropriate to the sentence itself, though it leaves the tool under-specified rather than genuinely concise.

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?

An output schema exists, so return values need not be described. However, for a tool with four required, undocumented parameters and no usage framing, the description is too thin to let an agent call it confidently versus its five schedule-related siblings.

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?

All four parameters (course_code, index, academic_year, semester) are required with 0% schema description coverage, so the description carries the full burden — yet it only obliquely references 'course index'. It adds no format, range, or interpretation guidance for semester, academic_year, or the index value.

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 and resource ('Get every scheduled session') scoped to 'one course index', so an agent can tell it retrieves schedule data rather than course metadata or index lists. It does not distinguish itself from siblings like get_graduate_course_schedule or get_undergraduate_exam_schedule, which cover overlapping schedule territory.

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 explicit when-to-use, when-not-to-use, or alternative tool named. The phrase 'for one course index' only weakly implies you must already have an index (presumably from get_course_indexes); nothing tells the agent how this differs from the other schedule tools.

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 cover read-only, idempotent, and open-world behavior, and the description adds real context on top: results are limited to 'public General Access' exams (excluding restricted/non-public exam types) and the term defaults to the latest published one when not supplied. It stops short of stating what happens when no published schedule exists.

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 tight sentence with the resource and the default-term behavior front-loaded and no filler. Every clause carries information the 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?

An output schema exists, so return values need not be described, and the safety profile is handled by annotations. The remaining gap is the undocumented parameter formats (0% schema coverage) and the absence of any routing hint toward the graduate or index-schedule siblings.

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. It clarifies that course_code identifies the course and that semester/academic_year are optional, defaulting to the latest published term, but it gives no format for academic_year (e.g. 2024 vs 24) or semester values beyond the schema enum.

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?

Specific verb ('Get') plus a precise resource: public General Access exam dates and times for a course. The word 'undergraduate' in the name plus 'General Access' scoping separates it from get_graduate_course_schedule, though the description never names that sibling explicitly.

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 'for a course' and by the 'latest or specified published term' phrasing, which tells the agent the term arguments are optional. There is no explicit when-to-use vs when-not guidance and no pointer to get_graduate_course_schedule for graduate courses.

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