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

Annotations already establish this as a safe, idempotent, open-world read (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the safety profile is covered. The description adds genuinely useful behavior beyond that: the upstream source (bars.itmo.ru), the scope limitation to the current semester, and the shape of the result (per-discipline totals plus per-checkpoint points with min/max). It does not mention auth requirements or behavior for unknown discipline names, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One tightly built sentence: source and scope first, then the return breakdown via a colon list, then the optional filter. No filler and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-shape burden and does so adequately by naming totals, per-checkpoint points, and min/max. The remaining gap is minor: no statement about authorization or what is returned when the discipline filter matches nothing.

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

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

Schema description coverage is 100% and the single optional parameter already documents itself as a 'case-insensitive part of a discipline name'. The description's 'Optionally filter by discipline name' restates that without adding matching syntax or edge-case behavior, so the baseline 3 for schema-covered params 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 gives a specific verb+resource: fetching current-semester points from BARS, broken down as totals per discipline and per checkpoint (labs, tests, exam) with min/max. It is clearly a grades-adjacent tool but never explicitly distinguishes itself from the sibling itmo_get_grades / itmo_get_grade_details, so an agent must infer the split from the 'BARS' and 'checkpoint' framing.

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 only usage statement is 'Optionally filter by discipline name', which is parameter guidance rather than when-to-use guidance. There is no indication of when this should be preferred over itmo_get_grades or itmo_get_grade_details, no prerequisites, and no exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds valuable return-content context by enumerating dormitory queue place, assigned dormitory/address, and contract balance/payment schedule, though it does not mention authentication or data freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single, front-loaded sentence with no filler. Every listed item earns its place by describing returned data.

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 no output schema, the description adequately summarizes the main returned fields and annotations cover the safety profile. It could be slightly more complete by clarifying that the data is for the current user, but it is sufficient for correct selection.

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 input parameters, so the schema cannot document any parameter semantics. Per the baseline for a parameterless tool, the description is not expected to add parameter guidance and a 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (dormitory status, queue place, assigned dormitory and address, and housing contracts with balance and payment schedule) that no sibling tool covers. It is clear but written as a noun phrase rather than an explicit verb+resource, so it falls slightly 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?

No explicit when-to-use, prerequisites, or alternatives are stated. The content implies this is the tool for checking one's dormitory and housing-contract information, but the agent must infer that context rather than being told directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds no behavioral context beyond that — no auth requirements, no explanation of what the returned 'status' values mean, and nothing about freshness or caching of the 'current' campaign.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. It is appropriately sized for a zero-argument status lookup, though it is so terse that it borders on under-specification.

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 describing the return value, and it only gestures at it ('status and dates'). An agent gets no idea what status values exist (e.g., open/closed/upcoming) or what the dates represent, which is a meaningful gap for a status-query 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No argument syntax or filtering options need explaining.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (the elective discipline selection campaign) and states what it returns (status and dates). It is clearly distinguishable from the sport, scholarship, dormitory, and grades siblings, though it never names a verb or explicitly contrasts itself 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?

There is no guidance on when to call this tool versus any alternative, and no prerequisites or trigger conditions are stated. The word 'current' hints at a time scope but nothing tells the agent when this call is warranted.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. With no output schema, the description earns credit for disclosing what the call returns (assessment-level point breakdown), which is genuine context beyond the structured fields.

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 with the resource and returned fields front-loaded and zero filler. Every clause 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 single-param, read-only tool with full annotation coverage and a well-documented schema, the definition is nearly sufficient; the only gap is that it does not explicitly tie itself to itmo_get_grades as the prerequisite call.

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?

Only one parameter with 100% schema description coverage, including the source hint 'entry_id from itmo_get_grades'. The description adds only 'one record book entry' as context, so the schema does the heavy lifting — 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 resource (points breakdown) and enumerates the returned components (assessments, min/max points, received points) scoped to a single record book entry. Clear enough to distinguish the scope from a list tool, but it never names itmo_get_grades as the parent/sibling, so the differentiation is only implied.

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 'for one record book entry' and the schema hint 'entry_id from itmo_get_grades' imply this is a drill-down following a grades listing, but the description itself states no when-to-use condition or explicit alternative. Usage is 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 readOnly/idempotent/non-destructive and openWorld, so safety semantics are covered. The description adds one behavioral fact, the default-to-current-semester scoping, but says nothing about pagination, ordering, or how missing grades for a future semester behave. Adequate but not rich against an already-annotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first front-loads what is returned and the scope, the second handles the default and the routing to the sibling. No filler or 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?

With no output schema, the description usefully enumerates the returned fields and explains the default parameter behavior, which is enough for a one-parameter read tool. Minor gaps remain (ordering, behavior for semesters with no grades), keeping it short of a 5.

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

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

Schema coverage is 100% and the single parameter's meaning ('sequential semester number in the study plan') is fully documented in the schema. The description only adds the default behavior (current semester), which is a mild complement rather than new syntax or format detail, 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?

States a specific resource ('final grades from the ITMO record book (zachetka)') with a concrete scope ('for one semester') and enumerates the returned fields (points, grade, assessment type, date). It also routes the agent away from the similar sibling itmo_get_grade_details, so it is distinguishable from siblings without opening schemas.

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 clear usage context ('Defaults to the current semester') and explicitly names the alternative (itmo_get_grade_details) for the points breakdown. It does not state any when-not-to-use condition, but the alternative is named precisely enough to route correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, covering the safety profile completely. The description adds only the qualifier 'Public', which usefully signals the data is non-sensitive, but says nothing about missing/unknown ISU behavior or response shape. Modest added value on top of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the resource and lookup key, with the returned fields appended efficiently. No filler, no redundancy.

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 partially compensates by naming the return categories (positions, contacts, education), which is genuinely useful for result interpretation. It falls short of stating behavior for invalid or unknown ISU values, but for a one-parameter read tool it is close to sufficient.

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 there is a single parameter, so the schema already carries its own weight and baseline 3 applies. The description's 'by ISU number' merely restates the schema field and adds no format, range, or validation nuance.

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-plus-resource ('Public profile of an ITMO student or employee') scoped tightly to lookup by ISU number, and enumerates the returned content categories. It implies a direct-lookup role that contrasts with itmo_search_people, but never names that sibling, 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?

'by ISU number' implies the precondition that the caller already holds a known ISU, which is the natural routing signal against the search sibling. However, there is no explicit when-to-use statement, no exclusion of itmo_search_people, and no guidance on what to do when only a name is available.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the useful scoping fact that the subject is the signed-in user and lists the returned fields, but says nothing about authentication requirements or what happens when no session exists. Comparable to the calibration HIGH example, where annotations carried safety and the description earned a 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler; the scope ('signed-in') comes first and the field list follows. Nothing to trim.

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 no output schema, the description compensates by enumerating the returned fields, which is exactly the gap an absent output schema leaves. The remaining omission is auth/session-failure behavior, a minor gap given the annotations already mark it a safe, idempotent read.

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 and the baseline is 4. The listed return fields (ISU number, name, faculty, group, course) are output information, not input semantics, but they do not hurt.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (the profile) and pins the scope to 'the signed-in ITMO student', which implicitly distinguishes it from itmo_get_person and itmo_search_people without naming them. It also enumerates the returned fields, so an agent knows exactly what comes back. It stops short of explicit sibling differentiation, which keeps it 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 only implied: the phrase 'signed-in ITMO student' signals this is the self-profile tool rather than a lookup by identifier. No when-to-use statement, no prerequisites, and no pointer to itmo_get_person for fetching another person's profile. Adequate but leaves the agent to infer the routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds only domain context (dean's office, student office) but no behavioral traits beyond that, such as pagination, freshness, or how include_past 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple 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 simple read tool with annotations covering safety, the description is sparse. It omits any guidance on the include_past parameter and does not clarify what the returned appointments represent or whether they are user-specific.

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 single parameter include_past is never mentioned. Although the name is somewhat intuitive, the description fails to clarify what 'past' entails or its default 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?

The description names a specific resource (appointments) within a clear domain (ITMO electronic queue, dean's office, student office). It distinguishes the tool from siblings like schedules and grades, though it does not 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 is given on when to use this tool versus alternatives, nor any prerequisites such as required permissions or account context. The description is purely a label of the resource.

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, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds the origin scope ('submitted through my.itmo.ru') and the returned fields (applications, certificate requests, status), which is useful context. However, it doesn't discuss pagination, sorting, or auth requirements beyond what annotations imply.

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, zero waste. Could be improved with a bit more specificity about what 'status' entails, but that's optional for a list 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?

Given zero parameters, full schema coverage (trivially), and rich annotations, the description is nearly sufficient. Missing only optional extras like return format details or pagination, which are not mandatory since no output schema exists but the tool likely returns a list. An agent can invoke it 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?

Zero parameters, so per the rubric baseline is 4. The description correctly implies no filtering parameters exist. No additional param detail is possible or needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource type (applications and certificate requests from my.itmo.ru) plus a status attribute. Clear what it returns. Sibling tools cover distinct domains (people, schedule, grades, sport), so no confusion, but the description doesn't explicitly differentiate itself from them. Lacks a verb but 'get' is implied by the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no exclusions, no alternatives named. An agent has no signal for when this tool is preferable to others. The scope 'submitted through my.itmo.ru' implicitly narrows it but doesn't guide selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description usefully clarifies the result set ('booked by or shared with the student'), but says nothing about whether past/future bookings are included, ordering, or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the resource and its scope are stated immediately.

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 no output schema, the description is adequate but thin: it does not say what a booking entry contains or whether the list spans past and future terms, which an agent would need to interpret the result.

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 no parameter semantics to explain, and 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 names a concrete resource (room bookings: meeting rooms, coworkings, classrooms) and scopes it to those 'booked by or shared with the student,' which is more precise than the title alone. It stops short of explicitly contrasting with adjacent siblings like itmo_get_schedule, so an agent must infer the boundary.

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 resource scope — call it when you need the student's own room bookings — but there is no statement of when to prefer this over itmo_get_schedule or other schedule-adjacent tools, and no prerequisites or exclusions are given.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description correctly focuses on added traits: the default 7-day window, Moscow-time basis for dates, and that days with no classes are omitted from results. The last point is genuine return-shape disclosure with no output schema to carry it, though format of individual entries remains unstated.

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 tight sentences: what it returns first, then the default window, then a filtering caveat. No filler, no repetition of the title, and the most decision-relevant fact (what resource) is front-loaded.

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 two optional parameters, the description adequately covers scope, default behaviour, and result omission. It does not say what an entry contains (time, room, teacher) or how the personal scope is resolved, but nothing required to call the tool 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 the baseline is 3, but the description adds the default range applied when date_from/date_to are omitted — information the schema cannot express since both parameters are optional. It stops short of restating the 62-day span constraint, which the schema already handles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource — the personal ITMO class timetable — and enumerates the event types it covers (lectures, practices, labs, exams, consultations). This cleanly separates it from itmo_get_sport_schedule, though it never names that sibling or any other alternative 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?

Gives useful default behaviour (next 7 days starting today) which implies the no-argument use case, but offers no explicit when-to-use/when-not guidance or routing to sibling tools like itmo_get_sport_schedule or itmo_get_grades. 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds one genuine behavioral fact beyond the schema – the default 365-day window – but says nothing about permissions, data freshness, or pagination.

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 tight sentences with zero waste; the return content is front-loaded and the default-period behavior follows immediately. Every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description partially compensates by sketching the return shape (totals by category, itemized payments with breakdown) and the default range. For a two-optional-param read tool with rich annotations, this is close to complete, though auth or scope caveats are 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?

Schema description coverage is 100%: both date_from and date_to carry format and timezone ('Moscow time') details in the schema itself. The description does not add any syntax or interpretation beyond that, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (scholarship and payouts) and specifies what it returns: totals by category for a period plus individual payments with breakdown. It does not explicitly distinguish itself from siblings, but the sibling set covers unrelated domains (sport, grades, dormitory), so overlap risk is low.

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 notes the default period ('last 365 days'), which implies when the tool is useful, but it gives no explicit when-to-use guidance, prerequisites, or alternatives to consider. Usage is only weakly 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the shape of the payload (dates, venue, free places, registration status), but says nothing about pagination, sorting, or how registration status is derived.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence that front-loads the resource and the returned fields with no filler. It is efficient, though slightly terse for a tool with an 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?

For a no-required-parameter, no-output-schema listing tool this covers the gist of the response, and the annotations carry the safety semantics. However, the optional filter parameter is completely unexplained and there is no guidance on scope, so the definition is only minimally 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 sole parameter sport_type_id has 0% schema description coverage and is never mentioned in the description, so neither source explains its meaning, valid values, or what omitting it returns. The description's field list describes the response, not the input, so it does not compensate for the coverage 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?

Names a specific resource (university sports competitions) and enumerates the fields it returns (dates, venue, free places, registration status), which separates it from siblings like itmo_get_sport_schedule and itmo_get_sport_status. It lacks an explicit verb, but 'get' is implied by the name and the noun is 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?

There is no statement of when to call this instead of itmo_get_sport_schedule, itmo_get_sport_filters, or itmo_get_sport_status. The agent must infer that this returns a competition listing, and nothing is said about prerequisites, registration windows, 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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds one piece of behavioral context the annotations lack: that enabling sections and teachers produces a large payload. It says nothing about result shape or how the ids are consumed downstream.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the core payload is stated first and the optional expansion is parenthesized. It is compact and easy to parse, though the grammar is slightly elliptical.

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 gives a high-level summary of returned categories but no structure or usage mapping for the ids. It is adequate to call correctly but leaves the return contract thin, and annotations carry the rest.

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

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

Schema description coverage is 100% and the single parameter is already documented, including the '(large)' warning. The description's parenthetical mirrors the schema almost exactly, adding little beyond it, 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?

The description names the concrete payload (ids and names of sport types, buildings, sports semesters) and implicitly the verb is a lookup, which distinguishes it from data tools like itmo_get_sport_schedule. It stops short of naming a sibling it must not be confused with, but the resource is specific enough that an agent can tell it apart.

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 trailing phrase 'for other sport tools' implies this is a prerequisite reference lookup that feeds other sport calls, which is genuinely useful. However, there is no explicit statement of when to call it versus alternatives, nor what to do with the returned ids, so the guidance remains 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds content scope by naming the award sources (lessons, competitions), but says nothing about ordering, pagination, or how complete the history is. With annotations carrying the safety burden, 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?

A single efficient sentence with the resource front-loaded and a compact parenthetical for the award sources. It is slightly thin rather than padded, but nothing 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?

For a one-optional-parameter, read-only tool with no output schema, the description conveys what is returned at a high level but omits any sense of ordering, volume, or pagination. Adequate but with clear gaps for an agent planning to consume the result.

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

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

Schema description coverage is 100% and the single semester_id parameter already documents its source tool and default behavior ('current if omitted'). The description adds no meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (physical education point awards) and its scope (a sports semester), with a parenthetical listing the award sources (lessons, competitions). It is clearer than the bare title, though it does not explicitly distinguish itself from sibling sport tools such as itmo_get_sport_competitions, which the mention of 'competitions' could actually blur.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit statement of when to use this tool versus alternatives like itmo_get_sport_status or itmo_get_sport_competitions. Usage is only weakly implied by the phrase 'for a sports semester', leaving the agent to infer the selection condition.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, idempotentHint), so the bar is lower, and the description still adds useful behavior: the default 7-day range and the fact that it only surfaces enrollable lessons without enrolling. It does not mention pagination or result-size 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?

Three short sentences, front-loaded with the scope, then defaults, then the dependency and the read-only clarification. Efficient overall, though the 'does not enroll' clause partly restates the readOnlyHint annotation.

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 an 8-parameter, zero-required, read-only query tool with annotations but no output schema, the description supplies the key operational facts (default window, filter source, no enrollment side effect). What is returned is only sketched ('lessons ... with free places'), but the schema covers the parameters well.

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 88%, so the baseline is 3, but the description adds meaning the schema does not: the implicit default date window (7 days from today) and the provenance of the filter ids (itmo_get_sport_filters) that feed sport_type_id/building_id/teacher_isu.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource (physical education lessons open for enrollment, with free places and enrollment restrictions) and thereby distinguishes itself from siblings like itmo_get_sport_status, itmo_get_sport_competitions and itmo_get_sport_filters. It lacks an explicit retrieval verb, but the scope is 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?

It gives clear operating context: the default 7-day window, that filter ids must come from itmo_get_sport_filters, and that this is not an enrollment action. It stops short of explicit when-to-use/when-not guidance against a specific alternative 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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds one genuine behavioral detail beyond that: the upcoming-lessons window is fixed at 14 days, and the response aggregates several distinct data domains. It says nothing about data freshness, permissions, or failure modes, which is acceptable given the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the resource and then enumerates the returned content; nothing is padded or repeated. It is a sentence fragment rather than prose, but for a zero-arg summary tool that is efficient rather than sloppy.

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 input schema fields and no output schema, the description carries the burden of telling the agent what comes back, and it does so by listing six distinct content areas plus the 14-day window. Minor gaps remain: ambiguous terms like 'debt' and 'medical health group' are not explained, and there is no indication of result format or size.

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-based baseline of 4 applies; there are no argument semantics to document. The description's field list usefully doubles as a preview of the result shape, which is the only semantic detail available for a no-arg tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and verb-equivalent (a 'Physical education (sport) summary') and enumerates exactly what it covers: points, enrolled sections, upcoming lessons, enrollment attempts, debt, and medical health group. This differentiates it from sibling sport tools like itmo_get_sport_points_history or itmo_get_sport_schedule, though it never names them 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 enumerated contents signal an overview/status tool to call when a full picture is wanted rather than a single slice. There is no explicit when-to-use statement, no mention of the related sport siblings, and no note that it is parameterless so no scoping is possible.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the default-semester behavior, which is genuine value, but says nothing about the response shape or how much data one call returns for a semester.

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 names the resource first, then its payload fields, then the default behavior. No filler, nothing repeated from the name or 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?

With one optional parameter, no output schema and read-only annotations, the definition covers what an agent needs: what is returned, at what scope, and what happens when the parameter is omitted. Only finer details (ordering, result size) are absent, which is acceptable for this simple read 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 coverage is 100% and the lone parameter is documented as a sequential semester number, so the baseline is 3. The description adds a behavior the schema does not state: omitting the parameter defaults to the current semester, which meaningfully clarifies the optional parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: the disciplines of a student's study plan for one semester, enumerating the returned fields (credits, hours by activity, department, language, elective flag). This clearly distinguishes it from siblings like itmo_get_grades or itmo_get_schedule, though the verb is only implied by the name.

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 clause 'Defaults to the current semester' gives a useful calling hint, so usage is implied. There is no explicit when-to-use guidance or mention of alternatives (e.g., how this differs from get_grades or get_grade_details for a given term).

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description usefully adds the returned fields (ISU numbers, contacts, positions) but says nothing about pagination behavior despite limit/offset parameters, nor about result caps or empty-result handling.

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 tight sentences, front-loaded with the search capability and followed by return fields. No filler; slightly more room existed to fold in pagination guidance without bloat.

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 steps up by naming what comes back (ISU numbers, contacts, positions), which is genuinely needed. The remaining gap is pagination and result-limit semantics, which is meaningful but not fatal for a read-only search 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 coverage is only 33%: the query parameter is documented, but limit and offset have no description anywhere. The description partially compensates by naming searchable attributes ('name, ISU number or other attributes'), but it never explains pagination, defaults, or the 50-item ceiling.

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+resource ('Search ITMO students and employees') and enumerates queryable attributes plus returned fields. It is clearly distinguishable from sibling get-style tools like itmo_get_person, though it never names that sibling explicitly to sharpen the contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb 'search' versus the 'get_*' siblings that retrieve a single known entity, but the description never states when to use this over itmo_get_person or what to do when a query is ambiguous. No exclusions or prerequisites are given.

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