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 describes the return fields (dates, times, reasons, excuse status, notes), which is useful, but doesn't disclose behavior like whether it requires authentication, whether it returns empty vs error for no records, or pagination. No readOnly hint either.

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?

Well-structured: purpose first, then what records contain, then parameter explanations. Concise and front-loaded. The Args block is slightly redundant with the schema but adds format details.

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?

Output schema exists, so return values needn't be explained. The description covers the purpose and parameters adequately, but with zero annotations and no explicit usage context, it leaves some gaps for an agent deciding when and how to call this.

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 by explaining start_date and end_date. It does add the YYYY-MM-DD format and default values (school year start/end), which is valuable. However, with 0% schema coverage, the description could do more to clarify parameter 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 verb (Fetch) and resource (registered absences for the student), and elaborates on the record contents. It distinguishes itself reasonably from siblings like get_timetable or get_homework, though it doesn't explicitly contrast with any 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?

No guidance on when to use this tool versus alternatives. It's a straightforward data-fetch tool, but the description doesn't say when absences data is relevant or whether it's scoped to a particular student or all students.

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 behavioral burden. It does explain the filtering behavior and the default date window (today through start+4 days), which is useful, but it says nothing about permissions, rate limits, or whether results are sorted or paginated.

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 purpose before the filtering detail, and the args block is compact. The 'Filters the timetable...' sentence is mildly redundant with the opening but earns its place by clarifying scope.

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. For a two-optional-parameter read tool this covers what an agent needs to invoke it; the only gap is the absence of any behavioral caveats that annotations would normally have supplied.

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: it names both parameters, specifies the YYYY-MM-DD format, and explains the default behavior of each. That is meaningfully more than the bare schema provides.

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 ('Detect') and resource ('timetable changes') and enumerates concrete change types (cancellations, substitutions, room swaps). The phrase 'modified from the original schedule' separates it from get_timetable, so an agent can pick it without opening the sibling 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 conveys when to use it implicitly ('filters the timetable for lessons that have been modified'), but never names an alternative such as get_timetable or get_today, nor states when NOT to use it. Usage is inferable but not spelled out.

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. 'Fetch' plus 'can show any class at the school' conveys read-only scope and that access is not restricted to the student's own class, and the defaults describe fallback behavior. However, it says nothing about permissions, invalid class-name handling, or range limits.

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 action in the first sentence, then scope, then use cases, then a clean Args block. The 'Useful for...' list is longer than strictly needed but each item maps to a real scenario, so little is wasted.

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. All three parameters are covered with formats and defaults, and the discovery path (list_classes) is given. Only error/edge-case behavior is absent, which is a minor gap for a read-only fetch.

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 carry parameter meaning — and it does, documenting all three parameters with the YYYY-MM-DD format, example class names, and semantic defaults (student's own class, today, start + 4 days). It notably out-documents the schema, whose defaults are empty strings. No constraints on maximum range or invalid input are 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 and resource ('Fetch a class timetable') and immediately scopes it against the obvious sibling by noting it 'Can show any class at the school, not just the student's own' — which is the distinction from get_timetable. An agent can pick between the two without opening either 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?

Gives concrete use cases (religious instruction, split groups, comparing schedules, checking a friend's class) and routes to list_classes for discovering valid class names. It does not state an explicit when-not condition or name get_timetable directly as the alternative, so it stops short of a 5.

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 behavioral burden. 'Fetch' reasonably implies a read-only retrieval and 'upcoming' adds a time-scoping constraint, but it does not explicitly state read-only safety, permissions, rate limits, or side effects.

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?

Very short and front-loaded: the purpose is stated in one sentence, followed by a compact Args section. Every element earns its place with 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?

An output schema exists, so return values do not need explanation. The description covers the tool's purpose and its one parameter; the main gap is missing usage guidance relative to siblings, but for a simple read tool this is mostly complete.

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 single parameter has 0% schema description coverage, so the description must compensate. It explains that days_ahead is the number of days to look ahead and restates the default of 30, which gives adequate semantic meaning for invocation.

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: 'Fetch upcoming exams and tests.' This clearly distinguishes the content from siblings like get_homework, get_absences, or get_timetable, but it does not explicitly differentiate itself from those alternatives by naming when each should be used.

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?

Provides no explicit guidance on when to use this tool versus siblings such as get_timetable, get_today, or get_tomorrow. The days_ahead default is mentioned, but there are no inclusion or exclusion criteria, prerequisites, or alternative-routing hints.

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 conveys that this is a read of pending assignments and lists the return fields, but says nothing about auth requirements, whether completed homework is excluded, or how the window interacts with the pending filter. Adequate but thin for an annotation-free 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?

Short and front-loaded: the one-line purpose leads, followed by return fields and the argument note. The 'Args:' block is slightly verbose for a single optional parameter but wastes little space.

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 present, return values need not be re-explained, and the sole optional parameter is documented. The only remaining gap is the absence of any safety/permission context for an annotation-free tool, which is minor for a read-only fetch.

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 for the single parameter, and it does: days_ahead is explained as 'Number of days to look ahead (default: 14)'. It adds real meaning beyond the bare integer schema, though it doesn't clarify whether the window filters the pending set or the due-date range.

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 (fetch) and resource (pending homework assignments) and enumerates the returned fields, so the agent knows exactly what it retrieves. It does not, however, distinguish itself from the many sibling read tools (get_exams, get_timetable, get_today), so it stops short of a 5.

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 alternatives among the siblings. The word 'pending' hints at scope but the description never says when this tool is the right choice versus get_exams or get_timetable.

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 fetch and discloses the nature of the returned content, but says nothing about authentication, pagination, volume, or whether historical dates are supported. For a simple read tool this is adequate but thin.

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 and content are front-loaded in the first two sentences, and the Args block is compact. Slightly redundant phrasing ('messages of the day' followed by a restatement of what is returned), but nothing wasteful enough to impede selection.

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-value explanation is not required, and the single parameter is well documented. However, for a tool sitting in a dense sibling cluster, the absence of any disambiguation guidance leaves a real gap an agent must resolve on its own.

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's default is an empty string, so the description does the heavy lifting: it specifies the YYYY-MM-DD format and states the default is today. That fully compensates for the single undocumented parameter, though it does not say what happens on an invalid date.

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 ('Fetch messages of the day from the school') and enumerates the content types returned (announcements, notices, information messages). This makes it distinguishable from siblings like get_homework or get_exams, though it never explicitly contrasts itself with the closest siblings (get_changes, get_school_info).

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 use this tool versus alternatives. Siblings such as get_changes and get_school_info could plausibly surface overlapping school communications, yet the description offers no routing criteria or exclusions. Usage must be inferred entirely from the tool name.

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 discloses the returned content categories, which implies a safe read, but says nothing about permissions, caching/refresh behavior, or whether 'last data import' can be stale — context an agent would want for a freshness-sensitive field.

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, front-loaded with the resource and its contents, followed by a brief use case. No filler or repetition.

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 present, return-value detail is not required, and the description covers scope and a use case for a zero-param read tool. Only the lack of any routing guidance relative to the many sibling tools leaves a small 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?

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. No parameter meaning is missing or misrepresented.

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 (Fetch) and resource (school metadata) and enumerates the payload (period times, holidays, last data import). It is distinguishable from siblings like get_timetable or get_today, though it never explicitly contrasts itself with them.

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 second sentence implies usage ('understanding the school's schedule structure and upcoming free days') but gives no when-not conditions and does not point to any alternative sibling for schedule-level vs class-level data.

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 of behavioral disclosure. 'Fetch' implies a read-only operation, and the description adds useful detail about returned lesson fields and change types (cancellations, substitutions, room swaps), but it omits permissions, authentication context, and any rate-limit or error 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?

The description is front-loaded with purpose and return content, then uses a compact Args section for parameters. Every sentence and argument line adds useful information without repetition or 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?

The definition is adequate for a simple two-parameter read tool and benefits from an output schema, so return values needn't be fully explained. However, with ten sibling tools, the description does not disambiguate from get_today, get_tomorrow, or get_class_timetable, leaving an important selection 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 0%, so the description must compensate entirely. It documents both parameters with format (YYYY-MM-DD) and defaults (today; start + 4 days), adding exactly the semantics the schema lacks.

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 a specific verb 'Fetch' and resource 'the student's timetable for a date range,' and it enumerates the returned lesson fields and change types. However, it does not differentiate this tool from siblings like get_today, get_tomorrow, or get_class_timetable, which likely handle narrower or class-specific cases.

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 gives no explicit guidance on when to use this tool versus alternatives such as get_today, get_tomorrow, or get_class_timetable. The date-range defaults imply a multi-day fetch, but the agent receives no when-to-use or when-not-to-use instructions.

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. It usefully discloses that results include cancellations, substitutions, room changes, and teacher changes, which signals the data is change-annotated rather than a raw timetable. It does not say whether this is purely read-only, whether it needs authentication, or how it relates to get_changes, which also appears to surface changes.

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?

Short and front-loaded, with the core purpose in the first sentence. The second sentence largely restates 'all details' by enumerating change types, which is mild redundancy but still adds specificity.

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-value explanation is not required. The description is sufficient for a no-argument read tool, though clarifying its relationship to get_timetable and get_changes would remove the remaining ambiguity.

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 for the description to disambiguate. Baseline 4 applies for a zero-parameter definition.

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 (fetch) and resource (today's schedule) with a clear temporal scope that an agent can distinguish from get_tomorrow or get_timetable. It does not, however, explicitly articulate how it differs from similar siblings such as get_timetable or get_changes.

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 name and the word 'today', but the description never states when to prefer this over get_timetable, get_changes, or get_tomorrow. No exclusions or prerequisites are given, leaving routing 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?

No annotations are provided, so the description carries the full burden. It helpfully discloses that weekends return Monday's schedule, but does not mention permissions, side effects, or that the operation is read-only beyond the implied 'Fetch'.

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 front-loaded with the core purpose and includes a useful edge-case note. It is efficient, though the second sentence slightly restates the first before adding the weekend exception.

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 read tool with an output schema, the description is nearly complete. It covers the main behavior and the weekend edge case, with the only minor gap being explicit usage alternatives.

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?

There are zero parameters, so the baseline is 4. The schema is empty and fully described by its name, and the description does not need to add parameter details.

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: fetching tomorrow's schedule. It is clearly different from get_today by focusing on tomorrow, though it does not explicitly name sibling tools for comparison.

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 tool name and the weekend fallback behavior, but there is no explicit guidance on when to use this instead of get_today, get_timetable, or get_class_timetable.

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 does disclose the scope (current school year) and that it returns class names, but says nothing about permissions, pagination, or whether results are exhaustive/cached for a zero-parameter read.

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 with the purpose front-loaded and the downstream chaining detail second. No filler and no redundancy with the 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?

An output schema exists, so the description needn't document return values, and it correctly stays out of that. For a simple zero-param read tool it is essentially complete, with only minor gaps around freshness and ordering 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?

The tool takes zero parameters, so the baseline is 4. The description adds nothing parameter-related because there is nothing to disambiguate, and the schema fully covers the empty argument object.

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 ('List all classes'), adds a scope ('current school year'), and clarifies that the output is class names. It points at the downstream sibling get_class_timetable, so an agent can place it in the workflow, though it doesn't contrast itself against the other list-like siblings.

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 second sentence gives a clear use context: the returned class names feed get_class_timetable to fetch a schedule. That is an actionable usage hint, but there are no explicit when-not-to-use conditions or alternatives to this call itself.

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