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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds the underlying endpoint and the substitution relationship to elk_get_section, which is useful context, but says nothing about freshness, latency, error modes, or what happens when the student has no card.

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 the resource with its endpoint and a dense field enumeration, the second delivers the sibling-routing instruction. No filler and nothing is 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 must carry the return-value burden, and the field enumeration does that well. Minor gap: terms like 'КУД' and the shape of nested data (per-semester vs aggregate GPA/credits) are not clarified, but for a zero-parameter 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 nothing for the description to disambiguate and the baseline is 4. The description cannot be faulted for parameter semantics here.

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 (академическая карточка студента) and enumerates exactly what it contains — рейтинг, GPA, кредиты, программа, факультет, курс, группа, статус — so an agent knows precisely what it gets. It also explicitly distinguishes itself from the sibling elk_get_section by positioning itself as the structured replacement for its profile section.

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 'Структурированная замена разделу profile в elk_get_section' tells the agent to prefer this tool over elk_get_section for profile data, which is a genuine routing signal. It stops short of any explicit when-not condition or other alternatives, but the sibling relationship 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds real value by listing the fields the caller will get back (no output schema exists) and identifying the backing source. It does not disclose ordering, truncation behavior, or whether the 100-item cap silently drops 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 zero filler; the resource identity and its UI location are front-loaded. It is terse to the point of being slightly telegraphic (the field list reads as a fragment), 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 simple one-parameter read tool with full annotations and no output schema, the description is adequate: it tells the agent what the tool returns and where the data lives. It is incomplete on the operational details an agent would want — result ordering, and whether 'limit' truncates the newest notifications.

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 optional parameter and schema coverage is 100%, so the schema already documents 'limit' (max 100, default 20). The description adds nothing about what the limit counts against or what happens when it is exceeded, so baseline 3 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?

Names a specific resource (ELK notifications) and pins it to a concrete surface ('колокольчик в шапке, lk.hse.ru/notification'), which unambiguously separates it from LMS-message siblings such as lms_list_messages. It also enumerates the returned content (title, text, date, importance, read status). It stops just short of a 5 because the verb is implicit — the phrasing is a noun list rather than 'retrieves/lists'.

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 instead of the many sibling listing tools (lms_list_messages, lms_list_assignments, my_today). The UI location helps an agent recognize the concept but gives no exclusion or selection rule.

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, open-world and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the upstream endpoint, network reachability compared to RUZ, and that returned entries carry online-class links. It stops short of noting caching, rate limits, or freshness of the data.

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

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

One dense sentence plus a parenthetical contrast: purpose first, then the network reachability differentiator, then the source-of-truth claim. No filler, 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?

With one optional parameter at full schema coverage, full annotations, and an output schema that explains return values, nothing an agent needs before calling is missing. The network-reachability caveat is the one piece of non-structured knowledge that matters, and it is present.

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% for the single optional daysAhead parameter, including default, min and max, so the schema carries the semantics. The description says nothing about the window parameter or its bounds, which is acceptable at full coverage but adds no value.

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

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

Names a specific verb+resource (student class schedule) and pins the exact backing API (lk.hse.ru/api/get-myschedule), plus notes it includes online-class links. It explicitly distinguishes itself from RUZ, so an agent can separate it from the sibling read tools without opening a 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?

"Работает из ЛЮБОЙ сети (в отличие от RUZ...)" plus "основной источник расписания" gives a clear selection rule: prefer this for schedule data unless on the HSE internal network. No explicit when-not-to-use is stated, and no sibling tool name in the provided list is called out as an alternative.

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

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

Annotations already cover read-only/idempotent/non-destructive. The description adds genuinely new behavioral detail: write operations (submission of requests) are not implemented, several sections return empty under stated conditions, and task fields are 'не подтверждены' so output is returned as-is. This is useful beyond the annotations, though it doesn't cover rate limits or pagination limits of the response.

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 purpose followed by a dense but purposeful per-section enumeration; every clause about a section adds meaningful semantics. It is a single long paragraph that would read better as a list, 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 polymorphic tool with no output schema, the description carries the burden well by explaining what each section returns, which fields to expect, and empty-result conditions. A few sections ('ответ как есть') remain vague about exact shape, keeping it just under 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 schema already documents that limit applies only to tasks and offset only to login_history. The description restates these constraints (max tasks, offset pagination) without adding format or syntax detail 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?

States a specific verb+resource (read a named section of the Unified Personal Cabinet) and enumerates every section with its concrete contents. It actively distinguishes itself from the sibling elk_get_academic_data for rating/GPA/group.

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?

Repeatedly routes the agent: 'для рейтинга, GPA и группы есть elk_get_academic_data', and each section note frames its purpose (login_history for security checking, portfolio for stipend achievements). It lacks an explicit 'when not to use this whole tool' or routing to other siblings like elk_get_user_info, so it stops short of 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds value by naming the underlying endpoint and by scoping out academic data, but says nothing about nullability/empty fields or how role values look in practice.

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 compact sentences: capability and returned fields first, scope exclusion and alternative second. Every clause carries information; 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?

No output schema exists, so the description must sketch the return value — it does so by listing the main fields and the endpoint. Slightly incomplete because only example fields are given ('т.п.') and the response envelope structure is unstated.

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

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

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no input is needed to identify the account.

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: retrieves basic structured account info from the ELK service, and enumerates the returned fields (name, email, roles). It explicitly distinguishes itself from the sibling elk_get_academic_data by naming what it does NOT return.

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?

Explicitly routes the agent: for academic card data (rating, group, faculty) use elk_get_academic_data. This gives both the exclusion condition and the named alternative, leaving nothing to infer.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that the tool returns all user-submitted requests and enumerating the returned fields, including status examples such as 'Выполнено' and 'На проверке'.

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

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

The description is front-loaded with the tool's purpose, followed by the returned fields and a practical usage note. It is appropriately sized, with every sentence adding useful information about scope, output, or application.

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 list tool with no output schema, the description explains both the scope of the operation and the fields returned. The only parameter is fully covered by the schema, and annotations cover the safety profile, so an agent has enough information to invoke 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?

Schema description coverage is 100%, and the single parameter `limit` is already documented with a default and maximum. The description does not mention `limit` or add any additional meaning beyond what the schema provides, so the baseline score 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 states a specific verb and resource: it lists all requests submitted by the user in ELK, with an explicit domain hint (lk.hse.ru/claim). It also names the returned fields (number, content, service, status, dates, assignee, link), making the operation unambiguous compared with sibling tools such as notifications, services, or user info.

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

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

The description gives a clear use case: checking the status of previously submitted inquiries (certificates, scholarships, military registration) without using the web interface. It does not explicitly name alternatives or when-not-to-use conditions, but the context is sufficiently clear for an agent to select this tool for request history.

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/openWorld/idempotent/non-destructive, so the bar is lower, yet the description adds real context: requests run under an authorized SSO session and the result is page-visible text plus links. It also discloses an important boundary — ticket creation happens on a different domain — which prevents a futile call. It stops short of describing auth-failure behavior or dynamic-content rendering limits.

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

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

The core action and return values are front-loaded in the first sentence, with the domain caveat placed last. The long parenthetical enumerating student-services subsections is dense but earns its space as routing knowledge; it is the only slightly bloated element.

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 correctly compensates by stating what comes back (visible text and links). Combined with the route catalog and the cross-domain caveat, an agent has enough to call this correctly; only failure modes and content-size expectations 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 coverage is 100% and the single parameter is already documented, so baseline would be 3. The description adds value by supplying concrete path examples (/claim, /student-services?section=documents&subsection=certificates) and enumerating valid route families, which makes the relative-path format unambiguous beyond the schema's single example.

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+resource ('Открыть любую страницу lk.hse.ru по относительному пути') and even states the return shape (visible text plus a list of links), so an agent knows exactly what the call produces. It does not explicitly contrast itself with the sibling elk_get_section or lms_open_page, so differentiation is only implied by the 'any arbitrary page by path' 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 catalog of known sections (/task, /claim, /service, /student-services with query examples, /faq) tells the agent concretely when this tool is the right reach, and the note that helpdesk forms live on a separate domain pmo.hse.ru effectively says when NOT to use it. What is missing is an explicit rule such as 'prefer elk_get_section for structured section data'.

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

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

Annotations already declare read-only, idempotent, open-world behavior, so the description focuses on what it adds: the exact result fields (id, name, description, direct link, relevance score) and the subtle fact that `categories` counts come from ALL search categories even though results are services-only. That is genuinely non-obvious behavior an agent would otherwise misread.

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 verb, resource and endpoint, then the return shape. Slightly dense with parenthetical metadata (catalog size, date) that is helpful but close to excess; still 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?

With no output schema, the description carries the return-value burden and does so well, naming each field and explaining the categories counter semantics. What is missing is only a note on result ordering/limit behavior and explicit sibling routing, which are secondary for a simple two-parameter search.

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%, with `query` already documented with examples and `limit` bounded 1-50 by the schema. The description adds only topical framing of what queries hit (services catalog), and never mentions the limit parameter, so it does not exceed the schema baseline.

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 ('Полнотекстовый поиск по каталогу сервисов ЕЛК'), names the backing endpoint and category, and enumerates what is findable (справки, заявки, психолог, антиплагиат). An agent can tell immediately this is a service-catalog text search, distinct from elk_get_user_info or elk_list_requests.

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 note that `categories` counters reveal whether it is worth also searching people/departments hints at follow-up routing. There is no explicit statement of when to prefer this over siblings like elk_get_section or elk_list_requests, 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 mark it readOnly, openWorld, idempotent and non-destructive, while the description adds substantial context: baseline creation, cursor/ack semantics, persisted:false behavior, 200-event truncation with omitted, source failure isolation, and grades expense. The local snapshot write is disclosed and framed as internal, not as a contradiction of reading external HSE systems.

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

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

Purpose and alternatives are front-loaded, and every sentence carries operational detail. The dense single paragraph could be more scannable for the ack/truncation rules, so it is strong but not perfect.

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 lists the return fields (changes, scopes, sources, ackSeq, omitted, gap, persisted, warnings) and explains baseline, truncation, persistence failure and source-failure cases. An agent has enough information to call 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?

Although schema coverage is already 100%, the description adds cross-parameter meaning: ack must be ackSeq from the last response, an event seq is not an ack, since does not move the cursor by itself, default scopes exclude grades, and omitted>0 means the response is truncated and must be continued with ack. This goes beyond the schema field descriptions.

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?

Opens with a specific verb and resource: it snapshots deadlines, schedule, inbox, claims and optionally grades, then returns only changes since the previous snapshot. It explicitly distinguishes itself from my_today/my_week/my_deadlines for current-state queries, so sibling selection is clear.

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?

States when to use it (changes since last snapshot) and when not to use it (use my_today/my_week/my_deadlines for current state). It also explains the first-call baseline behavior and the ack workflow, giving clear operational conditions.

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?

Goes well beyond the destructive/idempotent annotations by naming exactly what is destroyed (snapshot DBs, event log, corrupt-file copies, temp files), scoping the blast radius to local files only, and stating that recovery happens implicitly via the next hse_changes call. This is precisely the concrete destructive-behavior detail an agent needs before committing an irreversible-looking delete.

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?

Four short sentences, front-loaded with the core destructive action and the recovery path, then escalating detail on the full reset and the local-only scope. Nothing is redundant with the schema or annotations.

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 destructive tool with no output schema, the description covers what is deleted, what is preserved (local files only), how state is rebuilt, and the confirmation gate. Nothing an agent needs before invoking 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 coverage is 100%, so the baseline is 3, but the description adds real meaning about the scope parameter: omitting it means all scopes and additionally triggers deletion of corrupt-file and temp-file remnants. It restates the confirm requirement rather than adding to it, keeping it out of the 5 band.

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: wipes local snapshot databases and the scope's event log, and names the follow-on effect on hse_changes. This clearly distinguishes it from the sibling hse_changes (which builds the DB) and hse_clear_cache without needing to open 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?

Explains the operational context (next hse_changes recreates the DB) and distinguishes degraded-state reset from full reset, which effectively tells the agent when each variant applies. It does not explicitly contrast against the sibling hse_clear_cache, so it stops short of the top band.

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 only say it is non-read-only but idempotent and non-destructive; the description adds the real behavioral story: what is cached, the 2–30 minute TTL, that the call invalidates rather than mutates data, and that scope can narrow the effect. It does not say what the call returns or confirm there are no other side effects, but the substantive behavior is disclosed.

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 dense sentences, no filler, and the caching rationale sets up why the tool exists before the call instruction. Slightly back-loaded: the actionable 'вызовите этот тул' arrives after a long explanatory clause, 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-parameter maintenance tool with no output schema, the description covers what is invalidated, why, when to invoke, and what to do afterward. The only gap is that it doesn't indicate whether a confirmation or status is returned, which an agent may want before re-issuing its query.

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 enum (all/elk/lms) is already documented in the schema. The description's 'scope сужает сброс до одного сервиса' restates the enum rather than adding format, precedence, or interaction details 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?

Names the operation (cache reset), the resource (HSE tool data), and precisely enumerates the affected tools (lms_*, elk_*, and the my_today/my_week/my_deadlines summaries that share those resources). No sibling tool does this, so an agent can tell it apart from hse_changes_reset or any read tool 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?

Explicitly states the trigger condition ('если нужно гарантированно свежее значение — например, сразу после подачи работы или заявки') and gives the follow-up action (repeat the request). It also implicitly discourages routine calls by explaining the TTL exists to avoid unnecessary browser work, but there is no explicit 'do not call when' clause.

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 value beyond that by stating the shape of the response (type, title, URL per element), anticipating what the agent will get 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?

Two short sentences: the resource scope and input source come first, the return contents second. Nothing is padded and nothing needed is missing.

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, annotated read tool with no output schema, the description covers what is listed, what identifies the course, and what each result contains. An agent has everything needed to call 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?

Schema coverage is 100% — the courseId parameter is already documented with its edu.hse.ru URL form. The description only restates that the id refers to a course and points at lms_list_courses, adding minimal semantics beyond the schema; baseline 3 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?

States a specific verb and resource ('Список элементов курса SmartLMS') and enumerates what counts as an element (файлы, задания, тесты, форумы), which lets an agent distinguish it from lms_list_assignments and lms_list_courses. It also names the return payload (тип, название, ссылка).

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?

Explicitly tells the agent the input is a course id and points to lms_list_courses as the way to obtain one — a concrete prerequisite chain. It does not, however, say when to prefer this over lms_list_assignments for assignment-only needs.

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, openWorld), so the description adds real value beyond them: the shape of the returned items, the meaning of null vs "-" in grade, and an explicit failure mode when the course journal layout is unrecognized. Only pagination/ordering guarantees across calls remain 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?

Front-loaded with the purpose, then the return contract, then the error case — a logical order with no filler. It is a single dense run-on sentence, and splitting the item-field list would improve scanability, 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?

With no output schema, the description carries the burden of explaining returns and does so thoroughly, including field-by-field semantics and the error condition. It stops short of saying how to obtain courseId or whether the report is scoped to the authenticated user, which would complete it.

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% — courseId is already documented as the course id on edu.hse.ru with a positivity constraint — so the baseline is a 3. The description adds no further semantics about the parameter, such as whether it is a course id versus a journal id.

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: grades of a student for a SmartLMS course, plus explicitly the per-user report scope. It does not contrast itself with siblings such as lms_list_courses or lms_list_assignments, but the purpose itself 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 when-to-use guidance: no statement that courseId comes from lms_list_courses, no note on when to prefer this versus other LMS tools, and no prerequisites or exclusions. The agent must infer usage purely from the name and the single required parameter.

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. The description adds value the annotations do not: it discloses the exact returned fields, including attachment name, size and download link, which matters given there is no output schema. Missing only edge behavior such as what happens for an unknown or inaccessible messageId.

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, no filler, front-loaded with the operation and its identifier source, followed by the return-field enumeration. 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-parameter read tool with no output schema, the enumeration of returned fields compensates well for the absent output contract, and annotations cover safety. Only minor gaps remain: no mention of behavior when the id is invalid or the caller lacks access.

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 is a single parameter with 100% schema description coverage ('id письма (из lms_list_messages)'), so the description merely repeats the schema wording verbatim. Baseline 3 is correct when the schema already carries the semantics.

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 ('Полный текст письма ... по id') and immediately enumerates the payload (text, course, sender, recipients, attachments). It names the sibling lms_list_messages as the source of the id, so an agent can distinguish fetching one message from listing many without opening either schema.

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

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

The parenthetical '(см. lms_list_messages)' establishes the workflow: list first, then fetch by id, which implicitly rules out using this tool for discovery. It gives clear context but no explicit when-not-to-use or error/precondition 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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds that each item carries сроки сдачи and статусы, which tells the agent what fields come back, but nothing about permissions, enrollment scoping, or pagination. Adequate but thin for a tool with annotations doing most of the disclosure work.

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 short sentence with no filler, and the resource scope is front-loaded. It is terse to the point of omitting usage framing, but nothing is 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 an output schema present and a fully documented single parameter, the definition covers enough to invoke the tool correctly. It is incomplete on the selection side: an agent choosing among my_deadlines, lms_get_grades, and lms_list_courses gets no basis for picking this one.

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 is a single parameter with 100% schema description coverage ('id курса на edu.hse.ru'), so the schema already carries the meaning. The description only implies that results are scoped to that course and adds no format or constraint detail beyond what the schema states.

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 ('заданий курса'), names the Moodle module type (mod/assign), and says the payload includes deadlines and statuses. It is not differentiated from overlapping siblings such as my_deadlines or lms_get_grades, which also surface assignment/grade data.

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 inferable from the required courseId: list assignments for one course. There is no statement of when to prefer this over my_deadlines (deadline aggregation) or lms_get_course_materials, and no exclusions or prerequisites.

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 safety is covered; the description adds genuinely new context that SSO auth is required and happens automatically with credentials from .env, which matters for an open-world scraper tool. It stops short of mentioning latency, rate limits, or failure modes on auth expiry.

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 with no filler: the resource and returned fields come first, followed by the operational prerequisite. Every clause carries information an agent would otherwise have to guess.

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

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

An output schema exists, so return values needn't be spelled out, and the auth prerequisite is disclosed. The one gap is the absence of any routing hint among the many sibling lms_* tools for agents unsure whether courses or assignments/grades are wanted.

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 enumerated return fields are informative but relate to output, not 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?

States a specific verb and resource (list of the current student's courses on SmartLMS/edu.hse.ru Moodle) and enumerates the returned fields, so the purpose is unambiguous. It does not explicitly distinguish itself from siblings such as lms_get_course_materials or lms_list_assignments, which keeps it 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?

Scope is implied by 'текущего студента' (current student only), which tells the agent whose courses are returned, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling tool. Usage must be inferred from the name and 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 readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds value by enumerating the returned fields (subject, course, sender, date, read status, attachment count), 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?

Three short sentences, front-loaded with what the tool lists, then the source system, then the return fields. The 'important announcements often arrive here' line is mildly promotional but does double duty as usage 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?

With no output schema, the description carries the return-shape burden and does so adequately for a read-only list tool. Pagination/limit behavior and how to fetch a single message are the only material gaps.

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 (limit) exists and schema coverage is 100%, so the schema fully documents it. The description never mentions the limit or default paging behavior, so it adds nothing beyond the structured field — baseline 3.

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

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

States a specific verb and resource (list incoming internal-mail messages), plus the underlying plugin (local_mail) and scope (correspondence with teachers within courses). It implicitly distinguishes itself from the singular sibling lms_get_message, but never names it 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?

The sentence about important announcements and materials from teachers arriving here hints at when to check this inbox, but usage is only implied — there is no explicit 'use lms_get_message to read one message' routing or any exclusion criteria.

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 value annotations cannot: the request runs under an authenticated session and returns visible page text plus links. It omits failure behavior (redirects to login page, invalid path), 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?

Two sentences, no filler: the action and scope come first, the return value second, and the positioning clause last. 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?

With one required parameter, full schema coverage, no output schema, and safety covered by annotations, the description supplies the missing return-value context. Only edge-case behavior (unauthenticated redirects, non-200 paths) is left implicit, a minor gap for a generic page-fetch 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 100% and the single parameter is already documented with an example in the schema itself. The description repeats 'относительный путь' and an example path, adding no syntax or format detail beyond structured data; 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 (открыть), resource (любая страница edu.hse.ru), access context (под авторизованной сессией) and output (видимый текст и ссылки). The final clause carves out its niche versus the specialized siblings, so an agent can tell it is the generic escape hatch rather than a substitute for lms_get_grades or lms_get_course_materials.

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 explicit fallback guidance: use this when no purpose-built tool exists. It stops short of naming a concrete alternative or warning about when not to use it (e.g. don't scrape grades this way), so it is clear context rather than full routing logic.

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, open-world behavior, and the description adds real substance on top: partial-failure semantics (the summary is still returned when a source errors, check `sources`), deterministic sort order (overdue unsubmitted first, then by time, then undated), and null-date placement. That is exactly the kind of beyond-annotation context an agent needs for a multi-source aggregator.

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?

Four sentences, front-loaded with what is included before moving to the return shape and the degraded-source caveat. No filler; the ordering of information matches how an agent needs to read it. Output-field naming overlaps slightly with the output schema but the sort rationale is not derivable from it.

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?

Covers the areas that matter for a fan-in aggregator: source coverage, sort semantics, null dates, and graceful degradation with per-source status. Since an output schema exists, restating `items`/`sources` field lists is somewhat redundant, but the explanation of degraded-mode behavior is the piece the schema could not carry.

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 both parameters are thoroughly documented in the schema, including the courses id-vs-name matching rule and the note that the filter does not apply to schedule/ELK sources. The description only echoes the `days` horizon ('за days дней вперёд') and adds nothing new about parameters, 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 precisely enumerates the aggregated resource: unsubmitted SmartLMS assignments/tests (including overdue with closed submission), ELK windows, active ELK tasks/requests, and upcoming exams within a day horizon. This is far more than a restatement of the title 'Дедлайны'. It does not explicitly name the close siblings (my_today, my_week, lms_list_assignments), so differentiation is inferable from scope 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?

The usage is implied by the enumerated scope and the `days` horizon, which distinguishes it from single-source tools, but the description never says when to prefer this over my_today, my_week, or lms_list_assignments. The only explicit guidance is about handling a failed source ('смотрите sources'), which is about reading output, not about tool choice.

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

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

Annotations already cover read-only, idempotent, open-world, non-destructive, so the description's added value is the graceful-degradation contract: if a source is unreachable the summary is still returned and per-source status lives in `sources` (ok/error/skipped, error text, warnings). That is a real behavioral trait beyond the annotations; it stops short of stating cost, rate limits, or freshness/caching of the aggregated data.

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

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

Front-loaded with the 'today' scope, then contents, then return shape and the failure caveat. The item field list (kind, when, title, course, place, overdue, unread, source, ...) and the sources description partly duplicate the output schema, which is the only slack in an otherwise dense paragraph.

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-argument aggregator spanning two external systems, the description covers contents, ordering guarantees, return envelope, and partial-failure handling. With an output schema present, no further return-value detail is required; nothing an agent needs to invoke 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?

Zero parameters, so the baseline is 4; no parameter semantics are needed or missing. The description correctly spends no space on inputs.

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?

Enumerates exactly what the tool aggregates for 'today': classes, deadlines (with a precise window — all overdue unsubmitted plus through end of tomorrow) from SmartLMS and ЕЛК, exams, unread mail/notifications, active requests and tasks. Scope is unambiguous and separable from my_week / my_deadlines by its 'today' window, though 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?

The framing 'Что у студента сегодня' plus the exact deadline window gives clear context for when this tool applies (daily briefing requests) rather than alternatives like my_week. It never states exclusions or explicitly routes to the sibling tools, so guidance remains inferential rather than directive.

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?

Goes well beyond the annotations by disclosing partial-failure semantics: if a source like ЕЛК fails, the summary is still returned and callers must inspect sources (ok/error/skipped, error text, warnings). Annotations already cover safety (readOnly, idempotent, non-destructive) and openWorldHint fits an aggregator hitting external systems, so this added degradation contract is the high-value content.

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-loads scope and horizon, then exclusion, then return shape — a sensible order with no filler sentences. It is somewhat dense, and enumerating item fields (kind, when, title, course, ...) duplicates the existing output schema, which is the only real 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?

For a zero-parameter aggregator, the definition covers scope, exclusions, error tolerance, and result ordering. An output schema exists, so the description need not detail return values further, yet it still flags the degraded-mode behavior that no schema field alone would convey.

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

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

The tool takes no parameters, so there is nothing parameter-wise to disambiguate; baseline 4 applies. The description instead spends its space on the output contract, which is appropriate here.

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 the concrete resource and horizon ("План на ближайшие 7 дней (сегодня + 6)") and enumerates the exact content classes it aggregates: расписание, дедлайны SmartLMS и ЕЛК, экзамены/зачёты, просроченные работы. It also explicitly excludes mail/notifications and points at the sibling my_today, so it is distinguishable 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 an explicit exclusion with a named alternative: "Без почты и уведомлений — для них my_today", which is a clear routing rule. It does not address overlap with the other close sibling, my_deadlines, which also appears to surface deadline data, so the when-to-use picture is clear but not fully complete.

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