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

With no annotations, the description carries the full disclosure burden and does well: it states the hard network prerequisite (campus Wi-Fi or employee VPN), that failure occurs outside it, and what is returned (id plus label). It stops short of mentioning auth, rate limits, or result-count limits, which keeps it from 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?

Front-loaded with the core action and endpoint, then the critical network caveat and the alternative. Dense but nearly every clause earns its place; the parenthetical tool-provenance note (тул hsemcp, если подключён; API ЕЛК) is slightly noisy but still informative.

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 two-parameter, no-annotation, no-output-schema tool, the description supplies everything an agent needs: what it searches, the network precondition, the failure mode, the shape of the return value, and where the returned ids are consumed next.

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 50%: `term` is documented in the schema, while `type` has only an enum and default with no description. The description partially compensates by enumerating the four searchable entity kinds (студент, преподаватель, группа, аудитория), which map onto the enum, but it never explains the `type` parameter itself or its default.

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 (поиск по подстроке), the exact resources (студент, преподаватель, группа, аудитория ВШЭ) and the backing endpoint (ruz.hse.ru/api/search). It also positions itself against the schedule tools by naming ruz_get_group_schedule as the downstream consumer of the returned ids.

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 an explicit when-not (outside the HSE internal network the request errors) and names an alternative (elk_get_schedule) with the condition that selects it. The gap is that this alternative only covers schedule lookups, so an agent searching for a person while off-network is left without a fallback.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about return format, whether the endpoint is public or requires auth, or how the period window behaves. Only the notion of a 'заданный период' hints at the scope constraint.

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 resource and folds the id-lookup tip into a parenthetical, with no filler. It is efficient, though the parenthetical slightly interrupts the reading order of the main clause.

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 annotations and no output schema, the description should say more about what a schedule response contains and how the time window is applied. It covers the input side adequately but leaves the output and period semantics 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 coverage is 50%: groupId is documented in the schema, while daysAhead has only min/max/default constraints and no description. The phrase 'на заданный период' gestures at the period parameter but does not explain that daysAhead counts forward from today, so it only marginally compensates for the 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?

States a specific verb ('Расписание занятий') and resource ('учебной группы ВШЭ по её RUZ id') with the lookup key explicit. It is distinguishable from ruz_get_my_schedule by being group-scoped rather than personal, though that contrast is only implied 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?

Gives actionable routing: it tells the agent to obtain the id via ruz_find_person with type=group, which is exactly the prerequisite most callers would otherwise miss. It does not state when to prefer ruz_get_my_schedule or any exclusions, so it stops short of a full 5.

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

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

With no annotations, the description carries the burden and discloses the biggest behavioral trait: the RUZ API only returns data from inside the HSE network and will fail outside campus. It does not describe authentication beyond the email, return format, or how many entries come back.

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 block: purpose first, then the network constraint, then the fallback. It is dense and every clause earns its place, though the fallback clause is somewhat parenthetical and slightly clauses-heavy.

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 two-parameter, no-output-schema tool this covers purpose, the critical network limitation, and an alternative. The main omission is what the returned schedule looks like, which matters since there is no output schema to lean on.

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 both parameters are already documented in the schema. The description only reinforces the corporate-email domain ('login@edu.hse.ru') and the notion of a period; it adds no syntax or constraint details beyond the schema, 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 verb and resource ('Расписание занятий студента ВШЭ') plus the scoping key (corporate email) and the time window, which implicitly separates it from a group schedule. It never names the actual siblings (ruz_get_group_schedule, ruz_find_person), so the differentiation is inferable rather than explicit.

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 an explicit precondition (only works from the HSE internal network — Wi-Fi HSE.Student or VPN) and names the fallback tool elk_get_schedule with the condition that selects it ('при ошибке подключения вне кампуса'). This is exactly the when/when-not/alternative pattern.

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