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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description is not required to establish safety. It still adds real context beyond them: what the response reveals (linkage state, session status, username) and an explicit assurance that no passwords or secrets are exposed. It does not cover what a failure/expired-session result looks like.

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?

Three short sentences, front-loaded with the action and the systems involved, then the returned information, then the security note. Every sentence carries distinct information and none 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?

With no output schema, the description must convey the return payload, and it does so at a useful level (linked status, session status, username). No annotations or schema gaps remain unexplained; only the shape of edge-case responses is left open, which is minor for a zero-arg status check.

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; there is nothing for the description to disambiguate. It does not need to compensate for any schema gap.

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 (get) and resource (connection status of personal accounts) and names both covered systems (IIS BSUIR, SEO Moodle), which no sibling tool does — siblings read profiles, grades, courses, or schedules rather than account linkage state. An agent can tell this apart from iis_get_profile and lms_get_courses without opening any 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?

Usage is implied: check whether the personal accounts are linked and whether a session is active before relying on the iis_*/lms_* data tools. However, no explicit when-to-use instruction, no prerequisite statement, and no alternative named, so guidance is only inferable rather than 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds no behavioral context beyond that—no caching, timezone, source of the week number, or side-effect notes. It simply restates the return values.

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 a single, front-loaded sentence that states the core return values without any filler. Every part 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 simple zero-parameter getter with no output schema, the description adequately states what is returned (week number and date). It does not specify the date format or timezone, but that is a minor gap given the low 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?

The tool takes zero parameters, so the baseline score of 4 applies. There is no parameter information to clarify in the description.

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: retrieve the current academic week number (1-4) and today's date at BSUIR. It is clear and unambiguous, though it does not differentiate itself from sibling schedule-related tools.

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 only says what is returned; it provides no guidance on when to use this tool versus alternatives, nor any prerequisite or context. An agent gets no help deciding whether to call this or a schedule tool.

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=true, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the default of returning a full weekly schedule when date is omitted, and accepted date token formats.

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?

Three sentences, front-loaded with purpose followed by filtering capabilities and the default behavior. No filler; every sentence 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 read-only lookup with no output schema and fully documented parameters, the description covers purpose, filters, accepted formats, and default behavior. It stops short of describing the response shape or any limits, but nothing critical to invoking it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema. The description restates the date formats, days range, and subgroup values, adding how the date/days interact but no syntax beyond the schema. 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?

States a specific verb (получить) and resource (расписание занятий учебной группы), scoped to BSUIR. The resource scoping ('учебной группы') cleanly distinguishes it from the sibling get_teacher_schedule without needing to name it.

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?

Explains the three filtering modes (specific date, date range via days, subgroup) and, importantly, the fallback: if no date is given, the full weekly schedule is returned. No explicit 'when not to use' or named alternative, but the usage context is clear.

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=true and destructiveHint=false, so the safe read-only nature is known. The description adds that the tool returns direct links to schedule, staff page, and publication repository, which is useful behavioral context beyond safety. It does not mention error behavior or how partial matches are handled.

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 sentences: the first front-loads what the tool returns, the second specifies accepted input formats. Every clause carries information and there is no redundancy 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?

For a single-parameter read-only tool with annotations covering safety, the description is complete enough: it defines the returned data and input formats. It lacks guidance on ambiguity resolution (e.g., multiple teachers matching a surname) or output shape, but given no output schema and simple annotations, the remaining gap is minor.

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 parameter description already lists the accepted formats (surname, full name, urlId) with examples. The description repeats these examples but adds no new syntax or semantics beyond what the schema provides, so 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 states a specific verb and resource – retrieving a detailed profile card for a BSUIR teacher – and enumerates exactly what the card contains (contact info, position, degree, courses, links). This clearly distinguishes it from siblings like get_teacher_schedule or search_teachers.

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: use when you need a teacher's profile. However, there is no explicit when-to-use versus alternatives like search_teachers or get_teacher_schedule, nor any preconditions or 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?

Annotations already declare readOnlyHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds accepted identifier formats and date-filtering behavior, but does not disclose permissions, rate limits, or return characteristics beyond what annotations provide.

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 three sentences, front-loaded with the main purpose, followed by parameter acceptance and filtering support. Every sentence carries useful information 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?

For a read-only schedule lookup with full schema coverage and safe-operation annotations, the description is largely complete for invocation. It does not describe the return shape, but no output schema exists and the core purpose plus parameters are sufficiently 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?

Schema coverage is 100%, so the baseline is 3, but the description meaningfully adds that a full name ('ФИО') is accepted for the teacher parameter beyond the schema's surname/urlId examples. It also gives a concrete date example ('2026-09-07'), though the days parameter is only briefly summarized as a 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?

The description uses a specific verb and resource: 'Получить расписание занятий преподавателя БГУИР.' It clearly distinguishes this from sibling tools such as get_group_schedule by specifying that the schedule is for a teacher, not a group. An agent can identify the tool's purpose 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 explains what the tool accepts and its filtering capabilities, but gives no explicit when-to-use guidance, no prerequisites, and no routing to alternatives like search_teachers or get_teacher_profile. The agent must infer when this tool is appropriate relative to siblings.

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 declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is already clear. The description adds that it returns both historical records and current statuses, which is useful behavioral context beyond the annotations. However, it doesn't specify freshness of data, whether results are paginated, or any rate limits, so it only partially extends the annotation-provided transparency.

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 single sentence is front-loaded and waste-free, directly stating what is retrieved. It's appropriately sized for a simple no-parameter tool, though it could be slightly more informative about the return format without becoming verbose.

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 read-only, zero-parameter tool with no output schema, the description covers the basics: what is retrieved (history and current statuses) and the domain (BSUIR education certificates). However, it doesn't explain the return structure, sorting, or how to interpret statuses, which an agent might need to use the result correctly. It is adequate but not fully 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?

With zero parameters, the baseline is 4 per the rubric. There are no parameters to describe, so no additional meaning is required, and the description appropriately focuses on the returned data rather than parameters.

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 (Получить, 'retrieve') and resource (историю и текущие статусы заказанных справок об обучении в БГУИР, 'history and current statuses of ordered education certificates at BSUIR'). It is distinguishable from siblings like iis_get_markbook or iis_get_omissions, though it doesn't explicitly name alternatives.

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 doesn't mention prerequisites (e.g., whether a certificate must have been ordered first) or what scenarios warrant fetching certificate history/statuses. The description is purely declarative, leaving the agent to infer usage context.

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, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds the list of returned information but does not disclose auth requirements, rate limits, or other behavioral traits.

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, well-structured sentence that front-loads the verb and resource, with zero wasted words. It is appropriately sized for a simple no-param read tool.

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-only tool with comprehensive annotations and no output schema, the description is largely complete by naming the returned fields. It falls short of 5 only because it lacks any usage context or prerequisites.

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 cannot provide additional semantics. The description appropriately avoids parameter details, and the 0-param baseline is 4.

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 ('информацию об общежитии студента'), and enumerates the exact data returned (queue number, benefits, incentives, penalties). This resource is unique among siblings, so an agent can select it without ambiguity.

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, nor mention of alternatives. Usage is only implied by the resource name; an agent must infer that this tool is for dormitory inquiries.

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=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds the return content (list of disciplines plus latest marks), which is genuinely useful given there is no output schema, but it discloses nothing about scope limits, semester boundaries, or empty-result 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?

Two short sentences, zero waste: the first gives the action and scope, the second gives the return shape. Front-loaded and appropriately sized for a parameterless read tool.

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, the description's return summary (disciplines and latest marks) fills the most important gap, and annotations cover safety. The remaining weakness is the unresolved ambiguity against near-identical siblings, but for a simple no-argument read tool this is close to 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 tool takes zero parameters, so there is no parameter semantics burden; the baseline of 4 applies. The description correctly signals that no identifier is expected by anchoring everything to the implicit current student and current semester.

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 (текущий журнал отметок студента) with a scope qualifier (за текущий семестр), so the agent knows exactly what is fetched. However it does not distinguish itself from close siblings like iis_get_markbook or iis_get_mark_sheets, which sound like the same artifact, leaving overlap unresolved.

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 indication of when to use this tool versus the several look-alike siblings (iis_get_markbook, iis_get_mark_sheets, iis_get_omissions). There is also no mention of prerequisites such as authentication or which student's book is returned (no parameters implies the caller's own record), which the agent must 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=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description usefully adds what information is surfaced (curator contacts, starosta, classmates), but says nothing about permissions required, whether the user must belong to a group, or failure behavior when no group is assigned.

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 economical sentence that front-loads the verb and enumerates the returned entities. No filler and nothing redundant.

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, the description carries the burden of conveying what comes back, and it does so adequately by naming the three categories of data. It falls short only on scoping details (which group, what happens without a group), which for a zero-parameter self-scoped tool is a minor omission.

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 there is nothing to disambiguate; per the rubric this is the baseline 4. The description does not need to compensate for any schema gap.

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 ('Получить' / retrieve) and names the exact resource contents: curator contacts, group leader (староста), and the classmates list. It is clearly distinguishable from iis_get_profile (own profile) and get_group_schedule, though it does not explicitly state that differentiation.

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 statement of when to use this tool versus iis_get_profile or get_group_schedule, no prerequisites, and no exclusions. Usage must be inferred entirely from the name and the returned-data 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that it returns borrowed books and their due dates, but does not describe pagination, authentication context, or response format. With annotations carrying the safety disclosure, this is adequate but not rich.

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 a single front-loaded sentence that states the operation and the returned information with no filler. Every element 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 zero-parameter, read-only tool with a rich annotation profile and no output schema, the description states the resource and the returned data (books and due dates). No critical invocation detail appears to be missing.

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 per the baseline this dimension is rated 4. The description has no parameter semantics to add, and it does not need to compensate for an empty 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 description gives a specific verb ('Получить') and a precise resource scope: books borrowed by a student at the BSUIR library, including due dates. It is clearly distinguishable from all sibling tools, which cover other student data such as marks, dormitory, profile, and schedules.

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 does not explicitly state when to use this tool versus alternatives, nor does it list prerequisites. However, the very specific resource and the zero-parameter read-only nature imply usage when the agent needs a student's borrowed library books and due dates.

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 establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so this adds value by describing what is returned (grade book number, GPA, per-semester grades across exams/credits/coursework) — meaningful context given no output schema exists. It stops short of saying whether the result is scoped to the caller only or whether pagination/limits apply.

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: the purpose first, the return contents second. No filler, no repetition of the tool name, and it is front-loaded with the core action.

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 parameters and no output schema, the description adequately compensates by enumerating the return payload. The only real gap is the lack of any disambiguation from the very similar iis_get_grade_book sibling.

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 (empty schema), so there is nothing to document and the baseline of 4 applies. The description correctly implies no input is required by tying it to the authorized student.

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 ('Получить электронную зачётную книжку') scoped to the authorized student, and enumerates the returned content (record-book number, GPA, grades by semester/subject). However it does not differentiate from the near-duplicate sibling iis_get_grade_book, leaving the agent to guess which of the two 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 stated prerequisites beyond 'authorized student', and no mention of any alternative — notably it never says how it differs from iis_get_grade_book or iis_get_mark_sheets/iis_get_omissions. The agent gets no routing help.

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=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the returned documents represent (retakes, debts, admissions), but says nothing about scope, filtering, or response shape beyond that.

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 sentence that front-loads the verb and resource and uses the parenthetical to enumerate document types. No wasted words, though it is minimal enough that it could have afforded one clause of routing guidance.

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 annotation coverage and no output schema, the description is serviceable: it tells the agent what set of documents comes back. But with several near-duplicate academic-records siblings, the absence of any disambiguation leaves a real gap in how an agent would choose this tool correctly.

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 of 4 applies. The description correctly does not invent parameter semantics that do not exist.

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 ('Получить экзаменационные ведомости и направления студента') and adds the content scope (пересдачи, задолженности, допуски), which helps distinguish it from siblings like iis_get_markbook or iis_get_grade_book. However, it never explicitly contrasts itself with those closely named siblings, so the differentiation is inferential 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?

There is no guidance on when to use this tool versus iis_get_markbook, iis_get_grade_book, or iis_get_omissions, all of which overlap in the academic-records space. The parenthetical content list hints at scope but stops short of telling the agent when this is the right call.

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=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds that both an unread count and a notification list are returned, but says nothing about ordering, recency, or how paging affects results.

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 no filler, and the resource and return contents are front-loaded. It is efficient, though it is arguably too terse given the undocumented parameter.

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, the description does at least name the two return components (count and list), which is the minimum an agent needs. However, the sole input parameter's semantics and any pagination contract are left entirely unexplained, leaving a real gap for a list-returning 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% and the description never mentions the 'page' parameter, so an agent has no information about whether paging is 0- or 1-indexed, what the page size is, or whether omitting it returns everything. The description fails to compensate for the total lack of schema documentation.

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 ('уведомлений') plus the two things returned (unread count and list). It is distinguishable from the other iis_get_* siblings by the notifications resource, though it does not explicitly contrast with any of 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?

No statement of when to use this tool versus alternatives, no prerequisites (e.g. authentication), and no mention of pagination behavior even though a 'page' parameter exists. Usage is only implied by 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing the return payload (total hours, absences by reason, monthly statistics), which matters because there is no output schema. It stops short of noting optionality/defaults for term.

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?

Three short sentences, front-loaded with the core purpose, then the parameter, then the return shape. Every sentence carries information not available elsewhere in the structured fields.

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 read-only lookup with one optional parameter and no output schema, the description covers purpose, parameter meaning, and return contents. The only real gap is what happens when term is not supplied (aggregate across all terms?), which an agent would need to know.

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 0%, so the sole parameter 'term' is otherwise undocumented. The description compensates by defining it as the semester number and giving a concrete example (term=6), which is exactly the missing semantics. It does not state the behavior when term is omitted.

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+resource: retrieving a student's class-absence statistics, and even enumerates what the statistics contain (total hours, unjustified absences, monthly breakdown). It is unmistakably distinct from the grade/markbook/profile siblings, but it never explicitly names or contrasts an alternative tool, so it lands at 4 rather than 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?

Usage is implied by the specific resource (query a student's absence stats, optionally per semester), and the term parameter's purpose is shown by example. However there is no explicit when-to-use/when-not guidance and no reference to any alternative tool, so this is minimum-viable rather than strong routing guidance.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by enumerating the returned payload (ФИО, group, course, faculty, specialty, rating, photo), which no output schema provides.

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 purpose and followed by the return contents. No filler, no repetition of the title.

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 no-parameter, read-only tool with no output schema, the description supplies exactly what's missing: a precise statement of what data comes back. Combined with annotations covering the safety profile, nothing needed to call it correctly is absent.

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 per the rule the baseline is 4. The description correctly adds no parameter detail because none exists, and the empty schema leaves nothing ambiguous.

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 the authorized student's personal profile). The 'студента' + 'авторизованного' scoping implicitly separates it from get_teacher_profile, but no sibling is named 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 only implied: the zero-parameter 'authorized student' framing makes clear it returns the caller's own profile, but there is no explicit when-to-use or when-not-to-use guidance and no alternative (e.g. get_teacher_profile) is referenced.

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=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds behavioral context by disclosing the underlying mechanism (Moodle AJAX core_courseformat_get_state) and the shape of the payload, but says nothing about permissions, throttling, or failure modes.

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 resource and return contents front-loaded; no padding or repetition. The second sentence is a useful implementation note rather than filler, though it is slightly technical for selection purposes.

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, the description adequately conveys what data comes back and how. The only real gap is the undocumented course_id semantics, which the parameter name largely covers.

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 never mentions course_id, so it fails to compensate for the missing schema documentation. The single parameter's name is self-explanatory and unambiguous, which keeps this at a baseline-adequate 3 rather than lower.

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 ('структуру курса') and enumerates the returned structure — themes, sections, modules, assignments, lectures. This implicitly separates it from the sibling lms_get_courses (list of courses), though that sibling is never named.

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: 'подробную структуру курса' suggests detail for a single course versus lms_get_courses for the catalogue, but there is no explicit when-to-use/when-not or prerequisite statement. An agent can infer the context but is not guided.

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=true and destructiveHint=false, so the safety profile is covered externally. The description adds the return contents (course names, LMS IDs, links), which is useful since no output schema exists, but it discloses nothing about scope limits, pagination, or whether archived/hidden courses 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?

Two short lines, front-loaded with the action and scope, followed by the return payload. No filler sentences and nothing redundant.

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 parameters and no output schema, the description carries the burden of explaining what comes back, and it does list the returned fields. The only gap is routing guidance relative to the very similar lms_get_course sibling.

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 there is nothing for the description to disambiguate; baseline 4 applies. The description correctly conveys that no input is required.

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 ('Получить список доступных учебных курсов студента') in a named system (СЭО БГУИР / Moodle), and the plural 'курсов' implicitly separates it from the singular sibling lms_get_course. It does not, however, explicitly name that sibling or contrast the scope, so differentiation is left to inference.

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 'доступных ... студента' implies the context (current student's enrolled courses), which is enough to infer when to call it. But there is no explicit when-to-use statement, no prerequisites, and no mention of the singular lms_get_course alternative for fetching one course's details.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds the return behavior: cleaned structured page text and links to attached files, which matters especially since no output schema 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?

The description is two short sentences, front-loads the action and resource, and then concisely states the return value. Every sentence earns its place 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 read-only tool with annotations and no output schema, the description gives the essential action, resource type, required identifier, and return contents. It does not cover permission requirements or where module IDs come from, but the core invocation context is complete enough.

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 undocumented parameter. It only says 'по ID модуля', which largely restates the field name 'module_id' and does not explain where to obtain the ID, its expected format, or any constraints.

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 ('текстовый материал или страницу лекции'), and specifies the Moodle module type '(mod/page)'. It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools such as lms_get_resource.

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 'по ID модуля', which gives the required identifier context, but there is no explicit guidance on when to choose this tool over alternatives like lms_get_resource or lms_get_course. No exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds meaningful behavior beyond annotations: it says URLs are checked against a host whitelist for SSRF protection and that the file is downloaded through an authorized session, implying authentication requirements. It still omits rate limits or response handling, but the security context is useful.

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 concise sentences, front-loaded with the core action and the safety mechanism. There is no redundant or filler phrasing.

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 one-parameter read tool, the description covers purpose, safety, and authenticated-session behavior. However, with no output schema, it does not describe what is returned (file content versus metadata shape), and the url parameter remains under-specified.

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 clarify the single url parameter. It adds a constraint by stating that the URL is checked against a host whitelist, but it does not specify URL format, accepted schemes, or how to obtain the resource URL, leaving clear gaps.

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 pair of verbs (download and retrieve metadata) and a specific resource (educational file/document from the Moodle LMS). An agent can distinguish it from sibling tools like lms_get_course or lms_get_page because this tool targets a downloadable file/document resource.

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 implies usage for Moodle file/document resources, but it does not explicitly say when to use this tool instead of siblings such as lms_get_page or lms_get_course. No prerequisites or exclusions are stated, so usage is only implied.

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 establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: output is an interactive widget rendered directly in the ChatGPT client (Apps SDK / MCP Apps), not plain data, which the annotations do not convey.

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 sentences, front-loaded with the core action and resource, followed by the interaction detail. No filler, though the parenthetical SDK reference is slightly incidental.

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 required parameters, the description adequately explains that the result is a rendered interactive widget rather than data. It is a bit thin on how the three optional parameters combine (group vs teacher vs date), which is the main remaining 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 coverage is 100%, so date, group and teacher are already documented with formats and examples. The description only restates that the widget covers either a schedule or a teacher profile, without clarifying accepted parameter combinations, so the schema does the heavy lifting and 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 states a specific verb+resource: rendering an interactive visual schedule or teacher-profile widget inside the ChatGPT interface (ChatGPT Apps SDK / MCP Apps). That separates it from data-returning siblings like get_group_schedule and get_teacher_schedule, though it never names those siblings explicitly to make the boundary unambiguous.

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 tool 'allows showing' a card of classes or contacts with interactivity, so an agent can infer it is the UI-rendering counterpart to the data-fetching schedule tools. There is no explicit when-to-use/when-not or statement of whether data must be fetched first.

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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered externally. The description adds no behavioral context beyond that – no mention of result limits, matching semantics (partial vs exact), or whether the query is case-sensitive.

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 that states the action, the resource, and the searchable dimensions with zero 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 read-only search with full schema coverage and annotations carrying the safety profile, the description is minimally adequate. However, with no output schema and no note on how results are ranked or filtered by course/faculty, it leaves the agent without guidance on result interpretation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter (query, course, faculty) is already documented with examples in the schema. The description restates the searchable facets but adds no syntax or interaction detail (e.g., whether faculty and course combine as AND filters). 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 verb (поиск) and resource (учебные групп БГУИР) and enumerates the searchable facets (номер, специальность, курс, факультет). This clearly differentiates it from siblings like search_teachers or get_group_info, which retrieve rather than search.

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 indication of when to use this tool versus alternatives such as search_teachers (a sibling search tool) or iis_get_group_info (a direct lookup). The usage context is only implied by the presence of a query parameter, leaving routing decisions 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds only that it searches by surname/name/department; it does not disclose return format, pagination, auth requirements, or rate limits. With annotation coverage, a 3 is appropriate.

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?

Single sentence, front-loaded with the action and resource, with zero filler. Every word 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 simple search tool with complete parameter descriptions and safety annotations, the core function is covered. However, it lacks usage guidance and return-value context, and it does not distinguish itself from sibling teacher-profile/schedule tools. No output schema exists, so return details are not required, but the routing gap remains.

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 schema already documents both query and department with examples. The description restates the searchable fields but adds no syntax or format details beyond the schema, so 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?

States a specific verb 'Поиск' and resource 'преподавателей БГУИР' with searchable fields, so the agent can tell it is a lookup tool. However, it does not explicitly differentiate from siblings like get_teacher_profile or get_teacher_schedule, so it is not 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?

No when-to-use or when-not-to-use guidance is provided, and no alternatives are named. The description only states what it searches; it does not say whether to use it before get_teacher_profile or how to handle department versus query.

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