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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds no behavior beyond that—no auth requirements, rate limits, or freshness/staleness characteristics—and what it does list overlaps with the existing output schema.

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 short sentence with the key content categories front-loaded. No filler, no repetition, and nothing extraneous for a zero-argument tool.

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

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

With no parameters and an output schema present, the description need not explain return values, and the annotation set covers safety. Still, it offers nothing about the account context (whose account, what 'server' means, whether it reflects live or cached state), which for a monitoring/inventory tool leaves a small but real gap.

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

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

The tool takes zero parameters, so the baseline is 4. There are no arguments whose semantics could be misread, and the description does not need to explain any.

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 (account) and enumerates exactly what it surfaces: balance, tariff/plan, resources, and server. It is not a tautology and distinguishes itself from the many sibling tools that operate on domains, mail, MySQL, and backups by being the only account-wide informational read.

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 versus alternatives, nor any prerequisites or context. The description only names the content returned; an agent must infer that this is the 'any time you need account-level facts' 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=false, destructiveHint=false and openWorldHint=false, so the write nature is covered structurally. The description adds the useful side effect that files land in the account root directory, but says nothing about overwriting existing files, required permissions, or what happens when paths collide — a meaningful gap for a write 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 short sentences plus a compact Args block; the destination and action are front-loaded. Slight redundancy in restating parameter names that the schema already lists, but no wasted prose.

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

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

With an output schema present, return-value explanation is unnecessary, and the description supplies the action, the destination, both parameter meanings, and the backup_id default. The only missing element is overwrite behavior, which is minor given the explicit non-destructive annotation.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does document both parameters: paths as a list of paths to download and backup_id with the non-obvious semantic that null means the current backup. That default meaning is not derivable from the schema's bare 'default: null'.

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 concrete verb and resource ('Выгрузить файлы из бэкапа' – download files out of a backup) and adds the destination ('в корневую директорию аккаунта'), which is genuinely informative. However, it never distinguishes itself from the close siblings backup_restore_file and backup_files_list, so an agent could still pick the wrong one from the name alone.

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

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

There is no guidance on when to use this versus backup_restore_file, backup_files_list, or backup_download_mysql. The only contextual hint is the inline note that omitting backup_id means the current copy, which describes a default rather than a usage 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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, and the description is consistent with the non-read-only flag by stating that a dump is written to the account root directory. It adds the destination location beyond the annotations, but omits overwrite behavior, permissions needed, and file-naming/size behavior for a write-to-disk operation.

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 short and front-loaded with the core action, followed by a compact structured Args block. Every element earns its place, with no redundant restatement of the tool name.

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

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

An output schema exists, so return values need not be explained, and the destination directory is covered. However, for a tool that writes a dump to disk, the description leaves gaps around permissions, overwrite behavior, and how the resulting file is named or located.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does document both params: 'bases' as a list of database names and 'backup_id' as the backup ID with the default meaning 'current copy'. This compensates for the coverage gap adequately, though it adds no detail on name format or how a dump is scoped across multiple bases.

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 (выгрузить/download), resource (MySQL dump from a backup), and destination (account root directory), which lets an agent distinguish it from siblings like backup_download_file and backup_restore_mysql. It is clear but does not explicitly name those siblings to reinforce the distinction.

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 or when-not-to-use guidance and no mention of alternatives such as backup_download_file (files) or backup_restore_mysql (restore rather than dump). The only contextual hint is the parameter note about backup_id defaulting to the current copy, which is parameter-level, not tool-selection 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 declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the agent knows this is a safe read operation. The description adds the scoping behavior (default backup_id, path from root), which is useful. However, it does not disclose return format, pagination, or errors. With annotations covering the safety profile, 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?

The description is brief and front-loaded: one sentence states the purpose, followed by a concise Args section explaining the two parameters. It is well-structured and contains no filler, though the Russian line 'Содержимое файлового бэкапа' could be more specific about the list nature.

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 that annotations cover read-only safety, an output schema exists (so return values need not be described), and the description explains both parameters and their defaults, the definition is fairly complete for a simple listing tool. The main gap is lack of sibling differentiation from backup_files_list.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by explaining the meaning and default behavior of both parameters: backup_id (not specified = current copy) and path (empty = root). This adds significant value beyond the bare schema.

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

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

The tool name backup_file_list and description clearly indicate it lists the contents of a file backup (files and directories). This is a clear verb+resource, but the description does not distinguish it from the similar sibling backup_files_list, which appears to be an alternate/duplicate tool.

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

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

The description implies usage by explaining that backup_id defaults to the current backup and path defaults to the root. However, it does not explicitly say when to use this tool versus backup_files_list or other backup-related siblings. No when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile fully. The description contributes nothing beyond that - no note on scope, freshness of backups, or result volume - so it adds no behavioral value over the structured 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?

It is a single short sentence with no waste, which satisfies conciseness, but it is terse to the point of under-specification rather than being efficiently front-loaded with useful 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 an output schema present, the description needn't explain return values, and with zero params there is little else to cover. However, the existence of a confusingly similar sibling ('backup_file_list') means the definition should disambiguate scope and does not.

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 document; baseline 4 applies. Schema description coverage is 100% and the empty object schema is self-explanatory.

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 phrase 'Доступные файловые резервные копии' (available file backups) conveys the resource being returned, and the '_list' name implies enumeration, but it is a noun phrase rather than a verb+resource statement. Crucially, it does not distinguish this tool from the near-identical sibling 'backup_file_list', so an agent cannot tell the two apart from the text alone.

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 mention of alternatives, and no prerequisites. Given that a sibling named 'backup_file_list' exists, the absence of any routing guidance is a real gap.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral fact that the log records restore and download events specifically, but says nothing about ordering, retention, or scope of the entries.

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 short sentence with no filler, and the key noun (log of restore/download operations) is front-loaded. It is arguably too terse for the ambiguity it leaves, but nothing in it is wasted.

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

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

An output schema exists, so return values need not be explained, and there are no parameters to document. What remains missing is scope — whether the log covers file backups, MySQL backups, or both, and whether it is account-scoped — which matters given the parallel backup_files_* and backup_mysql_* sibling families.

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; the baseline for a parameterless tool applies. The description correctly implies a full unfiltered log rather than a targeted lookup.

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 — a log of backup restore and download operations — which distinguishes it from the action siblings (backup_restore_file, backup_download_file) and the inventory siblings (backup_files_list, backup_mysql_list). It is clear what the tool returns, though it does not say whether it spans both file and MySQL backups, which the sibling names suggest are separate domains.

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 of prerequisites (e.g. must a backup exist first, is it scoped to the current account), and no explicit routing away from the backup_* action tools. The agent must infer usage purely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds one behavioral detail beyond annotations: omitting backup_id defaults to the current backup. However, it does not describe authentication needs, rate limits, or any other behavioral traits.

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

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

The description is very short and front-loads the resource, followed by a compact Args block. Every part serves a purpose, though the 'Args:' formatting is slightly verbose for a single parameter. There is no wasted text.

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 the simple list operation, one parameter, and the presence of an output schema, the description covers the essential information: what is returned (databases inside a backup) and the parameter default. It omits explicit usage guidance relative to siblings, but that is the only notable gap for an otherwise complete definition.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter. It does by explaining that backup_id is the backup ID and that omitting it uses the current backup, adding meaning beyond the schema's type and default null. The explanation is complete for this simple 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?

The description states the resource clearly: 'Базы данных внутри резервной копии' (Databases inside a backup). This tells the agent what the tool returns, but it is a noun phrase lacking an explicit verb and does not differentiate from sibling tools like backup_mysql_list or backup_files_list, which might be confused with it.

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

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

The description only mentions a parameter default: 'backup_id: ID бэкапа (не указан = текущая копия)'. It provides no guidance on when to use this tool versus alternatives such as backup_mysql_list, backup_files_list, or backup_restore_mysql. There are no when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds no behavioral context beyond the resource — nothing about scope (all databases vs. a specific one), freshness of backups, or ordering.

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 short sentence with no padding and the resource front-loaded. It is efficient, though the absence of a verb makes it slightly less informative than it could be at the same length.

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

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

An output schema exists, so return values need not be explained. However, for a listing tool whose main risk is confusion with 'backup_mysql_db_list' and 'backup_file_list', the description should at least state what set of backups it returns — that gap is not filled by the schema or annotations.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing in the schema for the description to clarify or compensate for.

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 resource ('резервные копии баз MySQL' — MySQL database backups) but has no verb, essentially restating the tool name. It gives no way to tell it apart from the closely related sibling 'backup_mysql_db_list', which an agent could easily confuse with it.

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

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

There is no statement of when to use this tool, no prerequisites, and no mention of the overlapping 'backup_mysql_db_list' or companion tools like 'backup_restore_mysql'/'backup_download_mysql'. Usage must be inferred entirely from the name.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing behavioral beyond that: it never says existing files are overwritten, whether the operation is reversible, or whether it requires stopped services or elevated permissions — all material for a destructive restore.

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

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

Short and front-loaded: the action statement comes first, then a compact Args block. Nothing is padded, though the Args formatting is a docstring artifact rather than description prose.

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

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

An output schema exists, so return values need no explanation, and annotations carry the destructive/closed-world profile. What is missing is the operational context a destructive restore needs — overwrite behavior, path semantics, and reversibility — leaving the definition only minimally adequate.

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

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

Schema description coverage is 0%, so the description carries the burden. It does document both params and gives a valuable sourcing hint for backup_id, but 'paths' is only restated ('список путей для восстановления') with no clarification of path format (absolute vs. relative to a site root), which is critical for a restore operation.

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 ('Откатить файлы из резервной копии'), which is enough to separate it from backup_restore_mysql by resource type. It does not explicitly name the MySQL sibling or any other alternative, so sibling differentiation stays implicit.

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

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

Provides a useful prerequisite pointer — backup_id must be obtained via backup_files_list — which is genuine usage context. However, there is no when-to-use vs when-not guidance and no mention of the conditions under which restoring is appropriate or dangerous.

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 destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the agent knows this mutates and destroys data. The description adds that it is a 'rollback' (implying existing data is overwritten), but does not state irreversibility, required permissions, or what happens to pre-existing databases, so it only modestly exceeds 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?

Front-loaded with the core action in one sentence, followed by a tight Args block. No filler or redundancy; every line contributes.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description covers purpose and both parameters adequately; the only minor gap is behavioral detail on how existing data is affected by the rollback.

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

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

With 0% schema coverage, the description carries the burden and documents both required parameters: backup_id is explained and its source tool (backup_mysql_list) is named, and databases is defined as the list of database names to restore. It could add more (e.g., what happens when a database does not already exist), but it meaningfully compensates for the empty schema.

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

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

States a specific verb ('Откатить' = restore/rollback) and resource ('базу MySQL из резервной копии'), making clear it restores a MySQL database from a backup. This cleanly distinguishes it from the sibling backup_restore_file (files vs MySQL databases).

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, and the description helpfully routes the agent to backup_mysql_list for obtaining the backup_id, which is a useful pointer. However, it gives no explicit when-to-use/when-not guidance and does not warn that this is an overwriting operation versus alternatives.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds no behavioral context beyond creation (no duplicate handling, permissions, or side effects), but with annotations carrying the safety bar, a baseline 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?

The purpose is front-loaded in a single line, followed by a compact per-argument list. The docstring format is slightly verbose but each line maps to a required parameter and 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 an output schema present, return values need no explanation, and all six required parameters are documented. The remaining gap is the absence of when-to-use guidance relative to the cron_* siblings, but for a create-with-explicit-args tool the definition is largely 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?

Schema description coverage is 0%, so the description carries the full burden, and it does so well: it documents every one of the six parameters with valid ranges (0-59, 0-23, 1-31, 1-12, 0-7) and supported wildcard syntax ('*' or '*/N'). This is meaningfully more than the bare schema titles provide.

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 Russian description states a specific verb and resource ('Зарегистрировать новую cron-задачу' = register a new cron task), which is clearly distinct from siblings like cron_edit, cron_delete, and cron_toggle. It does not explicitly name those siblings, but the 'new/add' semantics differentiate it well enough for selection.

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

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

There is no guidance on when to use this tool versus cron_edit or cron_toggle, nor any mention of prerequisites or conditions. The agent is left to infer that this is the creation path from the name alone.

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

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

Annotations declare destructiveHint=true, readOnlyHint=false, openWorldHint=false, so the agent knows this is a destructive, non-read-only local action. The description adds only the Russian phrase 'remove the cron task' plus a basic arg explanation. It does not detail permissions, irreversibility, or side-effects beyond what annotations already convey.

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

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

The description is very short and front-loads the action. It includes arg information, though the formatting is terse and could be more structured.

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 an output schema, so return values need not be described. However, for a destructive action with one parameter at 0% schema coverage, the description should provide more context on what 'task_id' represents and confirm the destructive consequence.

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 schema description coverage is 0%, so the description should compensate. It provides only 'task_id: ID задачи', which gives a minimal Russian label but no additional format or source details beyond the property name in the schema.

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

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

The Russian phrase 'Убрать cron-задачу' states a specific verb and resource (remove a cron task). It clearly identifies the operation, though it doesn't explicitly differentiate itself from siblings like cron_edit or cron_toggle.

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

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

The description implies the tool is for deleting a cron job but offers no guidance on when to use it versus alternatives. With siblings such as cron_toggle and cron_edit, a user might need clarity on permanent deletion as opposed to toggling.

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=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the partial-update semantic (only changed fields are supplied, implying the rest are preserved), which is genuine behavioral context, but it says nothing about permissions, error handling, or what changes if a field is left out.

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 operation statement, followed by a compact Args block that earns its length given the zero schema coverage. No filler, though the Args list is somewhat mechanical rather than integrated prose.

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?

A mutation tool with 0% schema coverage and no output explanation needed (output schema exists). The parameter documentation compensates well, and partial-update semantics are stated; only auth requirements and failure behavior are absent, which are minor omissions.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely meets it: it documents all seven parameters with meaningful ranges and accepted syntax (minutes 0-59, hours 0-23, days 1-31, months 1-12, weekdays 0-7, plus '*'/'*/N' notation). task_id is described only minimally as "ID задачи", which keeps this from a 5.

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 opens with a specific verb+resource ("Изменить параметры cron-задачи" = modify cron-task parameters), which is unambiguous. It does not explicitly contrast with siblings like cron_add/cron_delete/cron_toggle, but the name and verb make the distinction clear enough in practice.

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?

"Указывайте только обновляемые поля" tells the agent this is a partial update and that unspecified fields should be omitted, which is useful invocation guidance. However, there is no when-to-use/when-not guidance and no explicit reference to alternative tools such as cron_add or cron_toggle.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the subject matter (the notification address for cron jobs) but no further behavioral context; with annotations doing the heavy lifting, 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 front-loaded sentence with zero filler, appropriately sized for a simple getter. It is terse to the point of being sparse, 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 0-parameter getter with an output schema, the description is nearly sufficient, but it omits any reference to the paired cron_set_email tool, which is the one piece of routing information an agent would benefit from here.

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 of 4 applies for a parameterless 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?

The description names the resource precisely — the notification email address used for cron task execution — so an agent understands what is retrieved. It is clear but does not differentiate itself from the sibling cron_set_email, which is the natural counterpart.

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 mention of alternatives such as cron_set_email, and no preconditions. The agent is left to infer that this is a read counterpart to the setter purely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no note about output size, account scoping limits, or ordering.

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 short sentence with no filler and the scope stated up front. It is terse rather than padded, though minimalism is acceptable for a zero-parameter read tool.

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

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

An output schema exists, so return values need not be described, and there are no parameters to document. However, the description omits any routing hint to the closely related cron_* siblings, which is the main remaining gap for a simple listing 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 the baseline is 4 and there is nothing for the description to compensate for. It correctly implies the listing is implicitly scoped to 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?

The description identifies the resource (all cron jobs belonging to the account), but it lacks an explicit verb and largely restates the tool name cron_list. With 0 parameters there is nothing more to state, yet it does not differentiate itself from siblings such as cron_get_email, which also concerns cron 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?

There is no guidance on when to call this instead of the other cron_* tools (cron_get_email, cron_add, cron_edit, cron_toggle). The agent must infer that this is the enumeration entry point purely from the name.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, covering the safety profile. The description adds the disable-via-empty-string semantics, which is genuine behavioral context, but omits auth requirements or what changes to existing config occur.

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

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

Short and front-loaded, with the core action and the disable behavior stated first. The Args block restates the parameter but stays efficient; no wasted sentences.

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

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

An output schema exists, so return values need no explanation. For a single-parameter setter, purpose, parameter meaning, and the special empty-string case are all covered, leaving only minor gaps like permissions.

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

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

Schema coverage is 0% and the schema only names the field 'Email', so the description must carry the load. It does: it defines the parameter as an email address and explains that an empty string disables notifications, adding real meaning beyond the schema.

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

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

States a specific verb and resource: setting the report email for cron jobs, with the read counterpart cron_get_email nearby. It is clear what the tool does, though it doesn't explicitly contrast itself against siblings like cron_get_email or cron_edit.

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 through the empty-string behavior, which tells the agent one valid interaction pattern, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives. Adequate but leaves context to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, so the mutation/non-destructive profile is covered. The description adds the concrete semantics of the toggle (1=disable/hide, 0=enable), which is genuinely useful. It does not state that the operation is reversible or whether it requires elevated permissions, so a 3 fits.

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 action statement followed by a compact args block; no filler sentences. The docstring-style formatting is slightly verbose but every line 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?

An output schema exists, so return values need not be explained. For a two-parameter mutation, the description covers the action, the parameter origins, and value semantics. The only gap is the subtle conflation of 'disabled' with 'hidden', which could confuse an agent about side effects.

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

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

Schema coverage is 0%, so the description must carry the parameter burden, and it does: task_id is documented as coming from cron_list and is_hidden is given explicit value semantics (1=off/hide, 0=on). This meaningfully exceeds the bare 'integer' schema entries.

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 opening line gives a specific verb+resource pair: toggling the active state of a cron task. It clearly distinguishes the tool from cron_list, cron_add, cron_delete, and cron_edit by naming the distinct action (activity toggle). It stops short of a 5 because it does not contrast itself with cron_edit, which could plausibly also change task state.

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

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

The description implies when to use it (after obtaining a task_id from cron_list), which is a useful prerequisite hint. However, it gives no explicit when-not guidance or alternative — e.g. whether changing other fields should go through cron_edit instead.

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?

Beyond the readOnly/destructive annotations, it discloses substantive behavior: fallback to the parent zone on METHOD_FAILED, the invisible shared-hosting catch-all, and that the `effective` field is fetched by direct UDP query bypassing the resolver cache. One caveat: that explicit external UDP querying sits awkwardly against openWorldHint=false, which slightly tempers confidence.

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 purpose is front-loaded, followed by behavioral caveats and then a labeled Args block. It is lengthy for a two-parameter tool, but each sentence (fallback logic, catch-all trap, effective field) adds real interpretive value rather than filler.

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

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

For a read-only, two-parameter tool with an output schema and safety annotations already covering the risk profile, the description supplies the missing interpretive layer: how to read absence-of-record, where subdomain data lives, and what `effective` means. An agent can call and interpret it correctly without external clarification.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: fqdn is documented with valid forms (site.ru or sub.site.ru) and check_effective is explained as 'ask the authoritative NS (default yes)'. This fully compensates for the empty schema descriptions, though the per-parameter notes remain terse.

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 opening sentence names a concrete verb+resource: it returns the FQDN's DNS records plus the authoritative NS response. It is clearly distinguishable from the dns_set_* / dns_patch_record siblings, which are writes. However, it never explicitly contrasts with dns_verify, the other read-style DNS sibling, so it stops short of full sibling differentiation.

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

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

The description implies usage (inspecting a name's records) and gives scenario guidance for edge cases (METHOD_FAILED fallback, DKIM at parent level, catch-all). It does not state when to prefer this over dns_verify or when to run it before a dns_set_* mutation, so usage is only implied rather than explicitly routed.

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

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

Annotations declare destructiveHint=true and non-readOnly, and the description adds real context beyond that: it explains the merge pipeline, that other record types are untouched, and documents the force flag as 'continue despite CAA/SRV presence'. It doesn't spell out auth or rate-limit behavior, but for a destructive mutation the disclosed mechanics are substantial.

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 and internal pipeline, then structured bullets and examples. Efficient given the complexity, though the three examples are a bit redundant with the bullets.

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

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

The JSON-array formats, match/precedence semantics, force flag and multi-value use cases are all covered, which is what an agent needs to call this tool correctly. Output schema exists, so the description needn't explain return values.

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

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

Schema coverage is 0%, so the description must carry the burden — and it does. Each of add/remove/replace is documented with format (JSON array), matching rules (match by fields except ttl), and precedence, plus fqdn/type/force defined, with worked examples. This fully compensates for the empty schema.

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

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

The description states a precise verb+resource+scope: partial modification of records of a single type, with the internal pipeline getData → merge → changeRecords. It distinguishes itself from siblings like dns_set_a/dns_set_txt/dns_set_records by framing this as a partial (add/remove/replace) operation rather than a full overwrite.

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 concrete usage conditions ('Удобно для многозначных TXT и нескольких MX') and semantics for add/remove/replace including the preemption rule (if replace is set, add and remove are ignored). It doesn't explicitly compare against sibling tools like dns_set_a or dns_set_records, so a 4 rather than 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?

Adds substantial behavioral detail beyond the annotations: the getData → merge → changeRecords flow, preservation of other record types, replacement of prior A records, TTL being managed/ignored by Beget, and the destructive CAA/SRV deletion under force=True. This fully discloses side effects and matches the destructiveHint=true annotation.

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

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

The description is front-loaded with purpose, then adds safety notes, TTL caveats, the CAA/SRV warning, and an Args section. Every sentence adds necessary information for a destructive DNS mutation with undocumented schema parameters.

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 an output schema exists, the description need not explain return values, and it covers the mutation behavior, parameter semantics, and error conditions thoroughly. An agent has everything required to invoke the tool correctly and safely.

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

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

Schema description coverage is 0%, so the description must carry the full semantic burden, and it does: fqdn is the domain name, address is an IPv4 address with example, ttl may be ignored and defaults to 600, and force continues despite CAA/SRV deletion. All four parameters receive meaningful clarification.

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: setting an A record (IPv4) for an FQDN. This clearly distinguishes it from sibling DNS tools such as dns_set_cname, dns_set_txt, and dns_set_mx without needing to name 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?

Provides clear context for when the tool is usable and when a risky override is required, including the CAA/SRV error condition and the force=True escape hatch. It does not explicitly compare against alternative tools like dns_set_records or dns_patch_record, so it falls short of full alternative routing guidance.

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

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true). It discloses that records are safely merged, that setting a CNAME makes the zone set_type exclusive and breaks A/MX/TXT, and that force is needed when CAA/SRV exist — exactly the destructive side effects an agent must know before calling.

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 purpose, then the critical warning, then Args — a sensible ordering. The prose is dense and non-redundant, though the Args block is somewhat verbose relative to a 4-parameter 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 mutation tool with an output schema present, the description supplies everything needed: purpose, exclusivity warning, merge behavior, and per-parameter meaning including the force precondition. Return values are correctly left to the output schema.

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

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

Schema coverage is 0%, so the Args block carries the full burden and documents all four parameters: fqdn (subdomain form), cname (trailing-dot handling), ttl (delegated to dns_set_a), and force (CAA/SRV continuation). TTL being deflected to another tool leaves one semantic partially unstated, preventing a 5.

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 ('Задать CNAME-запись для поддомена'), which unambiguously separates it from the sibling record-setters (dns_set_a, dns_set_txt, dns_set_mx, dns_patch_record) by record type. An agent can select it without opening any schema.

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

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

Gives explicit when-not guidance: 'Используйте CNAME только на поддоменах, где у вас нет других записей', plus the exclusivity caveat that A/MX/TXT stop working. It references dns_set_a for TTL semantics, but does not name an alternative tool or fallback path if the subdomain already has records.

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

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

The annotations declare destructiveHint=true, and the description earns credit by spelling out exactly what is destroyed ('replaces all MX records with one') and what survives ('other record types in the zone are preserved'). It also discloses implicit normalization ('trailing dot removed automatically') and the force-override condition (CAA/SRV), adding real behavior beyond the 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?

Front-loaded with the core action and its side effect, then the alternative, then a compact Args block. Every line adds information; no filler.

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

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

For a 5-parameter destructive DNS mutation with an output schema present, the description covers purpose, destruction semantics, alternative, and all parameters. Residual gaps are minor: it does not clarify whether preference must be unique or what exactly happens when force is false and CAA/SRV exist.

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

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

With schema description coverage at 0%, the description must carry all five parameters and largely does: fqdn (domain), exchange (with trailing-dot note), preference (lower = higher priority), ttl (TTL seconds, deferred to dns_set_a), and force (continue when CAA/SRV present). The ttl entry deferring to another tool and the terse force explanation leave minor ambiguity.

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 ('Задать MX-запись / set MX record') plus the exact effect ('Заменяет все MX-записи одной') and what is preserved. It also names the sibling dns_set_records as the tool not to use for multiple MX, so an agent can tell them apart 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?

Explicitly routes the agent to dns_set_records 'для нескольких MX за один вызов', which is a concrete alternative and selection condition. It does not state when-not-to-use (e.g., non-MX zones) or prerequisites like required domain ownership, leaving those to inference.

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

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

Annotations already flag destructiveHint=true, but the description adds the exact destruction semantics that annotations cannot express: default merge preserves types not passed, replace_all deletes ALL non-passed records, and force deletes CAA/SRV records. This is precisely the extra context an agent needs before an irreversible write.

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 safety-relevant default is front-loaded, and the Args block is scannable. There is minor redundancy (replace_all and its merge default are stated in both the body and the Args list), but the example JSON earns its space.

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

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

With an output schema present, return values need no explanation, and all four params plus the destructive modes are covered. The one subtle ambiguity is whether types that ARE passed are fully replaced at the record level or merged record-by-record under the default mode.

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

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

Schema coverage is 0%, so the description carries the full burden, and it does: it documents fqdn, records (with a concrete JSON example showing address/exchange/preference shapes), replace_all's default and meaning, and force's effect. No parameter is left unexplained.

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 (set several DNS record types in one call) and implies the batching advantage over the single-type siblings (dns_set_a, dns_set_mx, etc.). It never names those siblings explicitly, so the differentiation is left to inference 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?

It clearly explains the two operating modes (default safe merge vs replace_all full replacement) and when the destructive path applies, which is real usage guidance. However it gives no explicit routing versus the sibling tools that set one record type at a time, nor any prerequisite/permission 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 destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds real value beyond them by specifying the destruction scope (all TXT records replaced, not appended) and what is preserved (A/MX/CNAME/NS), plus the force behavior around CAA/SRV. It does not discuss permissions or rate limits, 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?

Front-loaded with the operation and its replacement semantics, then the alternative, then a compact Args block. Every sentence earns its place; the ttl cross-reference is the one slightly wasteful note.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. Given a destructive DNS mutation, the description supplies the needed context (destructive scope, preserved record types, the append alternative, force semantics), leaving only minor gaps like permissions.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: it documents all four args with meaning, including an example value for txtdata and an explanation of force (proceed when CAA/SRV present). The only weakness is ttl, which defers to 'см. dns_set_a' rather than defining the value inline.

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 (set a TXT record) and immediately clarifies the core semantic: it replaces all TXT records with one. The use cases (SPF, verification, DKIM) are named, and it is clearly distinguishable from dns_patch_record, which it explicitly contrasts with.

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: use dns_patch_record with add=... when appending to existing TXT records (e.g. verification + SPF) rather than this replacement tool. This is a named alternative plus the condition that selects it, so nothing is left to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds real behavior the annotations cannot convey: direct UDP polling of authoritative servers, bypassing any resolver cache, looping until expect matches or a deadline fires, and the propagation-window consequence for certbot. It does not discuss query volume/rate limits or the failure/timeout result shape, so it is strong but not exhaustive.

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 routing rationale, mechanism, and parameter notes in that order; no sentence is pure padding. The closing nslookup/Resolve-DnsName tip is aimed more at a human operator and slightly dilutes the agent-facing payload, keeping this just under a 5.

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

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

An output schema exists, so return values need not be re-explained; the description instead supplies everything an agent needs to call it correctly — mechanism (authoritative UDP, cache-bypassing), blocking/polling semantics, timeout behavior, empty-expect single-shot mode, and the operational reason to verify at all. Complete for this tool's complexity.

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

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

Schema description coverage is 0% (titles only), so the description must compensate and does: fqdn, expect (semantics spelled out — IP for A, name for CNAME/MX; empty means return the current single-shot answer without waiting), type (enumerates A, AAAA, CNAME, MX, TXT, NS), and timeout (seconds to wait for a match, default 120). All four parameters gain meaning absent from the schema.

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

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

The opening line gives a concrete verb+resource+scope: confirm from the zone's authoritative NS whether the value is actually served to the world. It is immediately distinguishable from dns_get (reads the panel's own source) and dns_set_* (writes to the panel), so an agent can route correctly 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?

Explicitly states when this must be used instead of trusting dns_get: 'success from dns_set_* means accepted by the panel, and dns_get confirms exactly that — it reads the same source where it wrote.' It further names the concrete failure mode (running certbot during propagation burns a Let's Encrypt attempt) and even prescribes the manual alternative (nslookup, not Resolve-DnsName -Server).

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful 'no purchase / virtual domain' context but does not disclose prerequisites (e.g., whether the domain must not already exist) or any auth/side-effect details.

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 one-line purpose followed by a compact Args block; every line earns its place with no redundancy. Appropriately sized for a two-parameter 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?

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. Still, a mutation tool benefits from stating preconditions or effects of registration, which 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 0%, so the description carries the burden, and it does well: hostname is illustrated with 'example.com' and zone_id is explained with a concrete default ('1 = .ru') plus a pointer to domain_zones for the full list. This compensates meaningfully for the empty schema.

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

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

States a specific verb ('register'/'зарегистрировать') and resource ('virtual domain'), and the parenthetical 'without purchase' scopes it away from a purchase flow. An agent can distinguish it from siblings like domain_delete, domain_list, or domain_check_to_register 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?

Usage is implied by the verb and the 'without purchase' qualifier, and it helpfully points to the domain_zones sibling for retrieving a zone_id. However, it gives no explicit when-to-use/when-not guidance and does not state alternatives for the registration action itself.

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=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether existing directives are overwritten or merged, whether the change is immediately applied, or what permissions are required for this mutation.

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 one-line purpose is front-loaded and the args list is tight with no filler. Structure is clean, though the example is inline and could be marginally more compact.

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

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

An output schema exists, so return values need not be explained, and both parameters are covered. However, for a mutation tool with no usage guidance and no disclosure of overwrite semantics, the definition is adequate but leaves real gaps an agent would want filled.

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

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

Schema coverage is 0%, so the description carries the burden and does so well: full_fqdn is defined as the full domain name and directives is defined as a JSON array with a concrete example object. The example is especially valuable because the schema types directives as a plain string. It does not enumerate allowed directive names or value formats.

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: 'Set PHP directives for domain'. The verb 'set/задать' is distinct from the read sibling domain_get_directives and the delete sibling domain_remove_directives, so the agent can differentiate by operation. It does not explicitly name those siblings, so it falls 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 guidance on when to use this versus the closely related domain_get_directives and domain_remove_directives, nor any prerequisites (does the domain already need to exist, does it merge or replace). Usage must be inferred entirely from the name.

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

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

Annotations only declare it is a non-read-only, non-destructive mutation; the description adds substantial hidden behavior: Beget auto-creates A/MX/TXT(SPF) records, the name resolves to shared hosting before any user A-record, and MX/SPF silently survive dns_set_a. This is exactly the kind of side-effect disclosure an agent cannot get from 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?

Front-loads the purpose, then the input constraint, then the critical side-effect warning — a logical progression. The warning paragraph is long but every clause carries load-bearing information about records that would otherwise surprise the caller.

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 mutation tool, the safety profile is covered by annotations, the output schema covers return values (and the description even flags the records field), and both parameters are fully explained. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it specifies that subdomain is a prefix only (blog, not blog.site.ru), that the value will be rejected otherwise, and that domain_id carries the parent with a pointer to domain_list. Both parameters gain meaning beyond their bare schema titles.

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 (create a subdomain) and scopes it precisely: the subdomain must be a bare prefix, not an FQDN. It distinguishes itself from domain_add (creates domains) and domain_subdomains (lists them) by naming the parent-vs-child relationship.

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?

Requires an existing parent and points to domain_list for resolving domain_id, giving clear usage context. It stops short of naming alternatives or exclusions, but there is no competing sibling that creates subdomains, so the guidance is nearly complete.

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=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered, but the description adds nothing further: it never says what the change affects, whether the site is restarted, what permissions are needed, or whether the change is reversible. Given the lower bar set by annotations, this is still a notable gap for a mutation 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?

The purpose sentence is front-loaded and the two argument lines are tight and example-driven, with no filler. The Args block is slightly boilerplate-heavy but earns its place given the 0% schema coverage.

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

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

An output schema exists, so return values need not be explained, and both parameters are documented. What is missing for a domain-mutating tool is permissions/eligibility context and how it differs from domain_php_version, leaving it 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?

Schema description coverage is 0%, so the description carries the burden, and it does so for both required parameters: full_fqdn is explained with a concrete example ('site.ru') and php_version with accepted formats ('8.1, 8.2, 8.3'). It stops short of stating whether the version must be pre-installed or whether the value is validated, but the format guidance is real added 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?

The description states a concrete verb and resource ('Переключить версию PHP для домена'), which is unambiguous on its own. It does not, however, distinguish this mutating tool from the sibling domain_php_version or explain how the two relate.

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

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

There is no when-to-use guidance, no prerequisites (e.g. that the domain must already be added), and no reference to alternatives such as domain_php_version. The agent must infer the usage context entirely.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the no-side-effect profile is covered by structured data. The description adds only that this is an availability check for purchase, and is consistent with the annotations (no contradiction), but says nothing about whether zone_id must come from domain_zones or how the result should be interpreted before registering.

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 of purpose followed by a compact Args list; nothing is padded. It is appropriately sized for a three-parameter tool, though the Args block is the only content beyond the first line.

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

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

An output schema exists, so return values need no explanation, and the parameters are documented. However, for a check that gates a purchase, the description omits the relationship to domain_add/domain_zones and any note on what a positive vs. negative result implies. Adequate but with clear 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?

Schema description coverage is 0%, so the description carries the full burden — and it does: it explains hostname as the domain name (with an example), zone_id as the domain zone ID, and period as the registration period in years with a default of 1. This meaningfully compensates for the bare schema, though it does not clarify where zone_id values come from.

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: checking whether a domain is available for purchase/registration. That is distinguishable from write-oriented siblings like domain_add and read-oriented domain_list. It does not explicitly name or contrast with any sibling, so it stops short of a 5.

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

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

The intent (pre-purchase availability check) implies its usage, but the description never states when to call this instead of domain_add, domain_list, or domain_zones, nor that it should precede a registration call. 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 declare destructiveHint=true, readOnlyHint=false, openWorldHint=false, so the safety profile is covered structurally. The description adds only the scope phrase 'из аккаунта' and says nothing about irreversible consequences (removal of associated sites, mail, DNS records) or whether confirmation is required – the context an agent most needs for a destructive call.

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 sentence is front-loaded and terse, which is good, but the 'Args:' block adds nothing that the schema does not already show. It is short without being wasteful, but also without earning its structure.

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

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

An output schema exists, so return values need not be explained. Still, for a destructive, non-readOnly operation on an account domain, the definition omits idempotency, side effects, and any recovery guidance, leaving the definition under-specified for its risk level.

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% for the single parameter, so the description carries the burden. 'domain_id: ID домена' merely restates the parameter name; it does not say whether this is a domain name string vs. numeric ID, nor how the ID is obtained (via domain_list). This leaves real ambiguity for a required identifier.

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 ('Убрать домен из аккаунта' – remove domain from account), which is clear on its own. However it gives no differentiation from close siblings such as domain_delete_subdomain or site_unlink_domain, so an agent must infer the distinction from the names alone.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., domain_delete_subdomain for subdomains vs. this tool for a top-level domain). The agent is left to infer scope purely from the tool name.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds nothing beyond that — no warnings about data loss, no mention of irreversible consequences, no side effects. With annotations covering the safety profile, a 2 reflects minimal added value.

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 extremely short (one verb phrase plus an Args section). It is not verbose, but the Args section merely repeats the parameter name in Russian, which borders on tautology. The structure is minimal but not wasteful.

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 a destructive operation with one required parameter at 0% schema coverage, and an output schema present, the description should at least explain how to obtain subdomain_id, whether deletion cascades to related resources (e.g., DNS records, sites), and any prerequisites. It provides none of this, leaving significant gaps for an agent to call the 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 0%, so the description must compensate. It only says 'subdomain_id: ID поддомена', which restates the parameter name without adding format, source, or how to obtain the ID. This is inadequate for a required parameter with zero schema documentation.

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

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

The description states a clear verb and resource in Russian: 'Убрать поддомен' (remove a subdomain). This is specific and distinguishable from siblings like domain_delete (removes a whole domain) and domain_add_subdomain. However, it doesn't explicitly name the alternative or scope in English, and the tool name itself already conveys this.

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

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

There is no guidance on when to use this tool versus alternatives such as domain_delete or domain_remove_directives. The description does not state prerequisites, such as whether the subdomain must be empty or have no active sites.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing behavioral — no indication of what the directives payload looks like, whether it can be empty, or any account/permission context — so it contributes no value beyond the 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?

Two short lines with zero padding, and the resource statement is front-loaded. The Args block is mildly boilerplate but carries the only parameter format hint available, so it 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?

An output schema exists, so return values need not be explained, and this is a simple single-parameter read tool. Still, with zero schema coverage and no usage guidance, the definition is only minimally viable — an agent could call it but has no picture of expected output shape or failure conditions.

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% (the single property has only a title, no description), so the description must compensate. It does partly: it labels full_fqdn as the full domain name and supplies a concrete example (site.ru), which is genuinely useful formatting guidance. It still omits any mention that the FQDN must already exist in the account, so this is only a partial compensation.

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 resource precisely (custom PHP directives of a domain), which distinguishes it from siblings like domain_add_directives and domain_remove_directives, but it contains no verb at all — it is essentially a noun phrase restating the tool name. An agent can infer retrieval from the name, not the text.

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 mention of prerequisites, and no reference to the closely related siblings domain_add_directives/domain_remove_directives. The agent is left to infer that this is the read counterpart based solely on the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no note on whether results are paginated, cached, or include suspended domains. With annotations carrying the load, the description's lack of any extra behavioral context keeps this low.

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 short sentence with no wasted words, delivering the core scope up front. It is terse to the point of being minimal, but nothing is padded or 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?

An output schema exists, so return-value details are not the description's responsibility, and a no-parameter read-only list is intrinsically simple. Still, the complete absence of usage context or sibling differentiation leaves a gap for a tool sitting among many similarly named domain operations.

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 clarify and the baseline is 4. Schema coverage is 100% on an empty object, which matches the description's implication that no filtering input is accepted.

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 the resource ('all domains') and the scope ('linked to the account'), so an agent knows this returns the account's domain list without any parameters. However, it does not distinguish itself from close siblings such as domain_zones, domain_subdomains, or domain_check_to_register, which an agent could easily confuse with a plain domain listing.

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 mention of alternatives, and no indication of when this is preferable to domain_zones or domain_subdomains. The agent must infer usage entirely from the name and from sibling naming.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond the purpose, such as authentication requirements, rate limits, or error behavior.

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

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

The description is two lines, front-loading the purpose and then listing the single argument with its meaning. Every word is necessary.

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

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

For a simple read-only tool with an output schema and complete safety annotations, the description covers purpose and parameter meaning. The missing usage guidance versus siblings is a minor gap but not critical for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It provides the parameter name full_fqdn, its meaning 'Полное имя домена', and an example 'site.ru', giving adequate semantics for the single required 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?

The description states it returns the current PHP version for a domain, a specific read operation. It implicitly distinguishes itself from the sibling domain_change_php, which mutates the PHP version, though it does not name the sibling 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?

No guidance on when to use this tool versus alternatives like domain_change_php. The description only states what it does, leaving the agent to infer that this is for checking, not changing, the PHP version.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing behavioral beyond that: it does not say whether removal is immediate or reversible, whether the directives must already exist, or whether a restart/reload is needed for the change to take effect.

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 purpose sentence is front-loaded and the Args block is compact and directly useful for constructing the call. Slightly boilerplate docstring formatting, but no wasted prose.

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

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

An output schema exists so return values need no explanation, and both parameters are documented. However, for a destructive two-parameter mutation tool there is no guidance on prerequisites, permission requirements, or the effect on the domain after removal, leaving the definition minimally viable rather than 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?

Schema description coverage is 0%, and the description meaningfully compensates: full_fqdn is described as the full domain name, and directives is clarified as a JSON array despite the schema typing it as a plain string, complete with the example [{"name": "max_execution_time", "value": "60"}]. This resolves genuine ambiguity the schema alone would create.

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: removing PHP directives from a domain. The verb 'remove' (Снять) naturally contrasts with the sibling tools domain_add_directives and domain_get_directives, so an agent can route correctly, though the description never names those alternatives 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?

There is no when-to-use or when-not-to-use guidance, and no mention of the closely related domain_add_directives / domain_get_directives siblings. Only the operation itself is implied; the agent must infer that this tool is for deleting previously set directives.

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 and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: an entire class of records (auto-created www-aliases) is silently excluded from this list and also absent from dns/getData — a gotcha an agent would otherwise misread as 'no such subdomain exists'.

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

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

Purpose is front-loaded in one line, followed by the caveat and the fallback route. Every sentence carries information, though the parenthetical example (www.sub.site.ru → sub.site.ru) is slightly verbose.

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

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

An output schema exists, so return values need no explanation. For a no-parameter read tool, the description supplies the one non-obvious fact (www-alias exclusion plus the dns_get fallback) that an agent cannot derive from schema or annotations.

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 of 4 applies. There are no argument semantics to clarify, and the description correctly spends its budget on behavior instead of invented parameters.

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

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

The first sentence names a specific resource and scope — all subdomains of the account — which implicitly separates it from domain_list (top-level domains) and domain_zones. It does not explicitly name a sibling, so it falls just 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?

It gives a concrete usage boundary: www-aliases are NOT returned here, and records for such names must be fetched via dns_get. That is explicit routing for an edge case, though it offers no general 'use this when…' framing versus other listing tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds only example suffixes, with no note on whether the list is static or account-dependent, no pagination or auth context.

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 short sentence, front-loaded with the key noun, with no wasted wording. It is a fragment rather than a sentence, which slightly weakens structure but keeps it maximally terse.

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

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

For a no-parameter read-only tool with an output schema, the definition is minimally viable, but it omits whether the returned zones are a fixed reference set and how they relate to sibling domain tools, leaving an agent with just enough to call 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?

The tool takes zero parameters, so the baseline is 4; the schema fully covers the (empty) argument set and the description has no parameter semantics to compensate for.

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 (available domain zones) with concrete examples (.ru, .com), which distinguishes it reasonably from siblings like domain_list (the user's own domains) or domain_check_to_register. It lacks an explicit verb, but the intent of a reference lookup 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?

There is no statement of when to call this tool, when not to, or which sibling to prefer for related tasks (e.g. domain_list, domain_check_to_register). The agent must infer usage entirely from the name.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent already knows this is a bounded write with no destructive side effects. The description adds the notable detail that the resulting login is derived from a suffix (i.e., a prefix is appended), but it does not disclose whether the password is returned, whether the account is immediately active, or what the response contains.

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 action, followed by a compact three-line argument list with no filler. The 'password: Пароль FTP' line is near-tautological with the parameter name, but overall the structure is efficient.

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 three-parameter create tool with an output schema (return values need not be explained), the description covers the essentials but omits how the login is actually formed, whether the domain must pre-exist, and any failure/duplicate behavior. Adequate but with clear 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?

Schema description coverage is 0% and property titles are bare ('Suffix', 'Homedir', 'Password'), so the description carries the full burden. It labels each parameter and, crucially, gives a concrete homedir example ('site.ru/public_html'), which meaningfully clarifies format beyond the schema.

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

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

States a specific verb and resource: 'Добавить FTP-аккаунт' (add an FTP account), which distinguishes it from siblings ftp_list, ftp_delete, and ftp_change_password. The follow-up 'Итоговый логин: login_suffix' hints at the login-composition behavior, though it names a parameter (login_suffix) that does not exist in the schema, introducing mild confusion.

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

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

There is no guidance on when to use this tool versus the FTP siblings, no prerequisites (e.g., the domain must exist first), and no mention of what happens if an account already exists. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the agent knows this is a non-destructive write scoped to the account. The description adds nothing beyond that: it does not say whether existing FTP sessions are invalidated, whether the change is immediately effective, or what happens on failure.

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

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

Very short and front-loaded: the purpose is the first phrase, followed by a compact Args block. Nothing is wasted, though the boilerplate 'Args:' formatting adds little for an already self-evident parameter list.

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

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

An output schema exists, so return values need not be described, and the operation is low-complexity with only two required params. Still, for a credential-mutating tool with 0% schema coverage, the description omits the meaning/preconditions of 'suffix' beyond a restatement and any note about effect on active sessions or required permissions.

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

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

Schema description coverage is 0%, so the description carries the full param burden; it partially compensates by clarifying that 'suffix' means the FTP login suffix and 'password' is the new password. That resolves the main ambiguity, but there is no format, length, or character-set guidance and no explanation of how to obtain the correct suffix.

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 ('Сменить пароль FTP-аккаунта' – change FTP account password), which is unambiguous and unique among the siblings (ftp_add, ftp_delete, ftp_list all do different things). It does not, however, explicitly contrast itself with those siblings or point to related tools.

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

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

There is no indication of when to use this tool versus alternatives, nor any prerequisite such as 'the FTP account must already exist' or 'use ftp_add first to create one'. The name/description implies the intent, but usage is left entirely to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write. The description only restates that by saying 'убрать аккаунт' and adds nothing about whether hosted files are also removed, whether the action is reversible, or what permissions are required — no value beyond the 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?

Front-loaded with the action and resource, followed by a compact Args block; there is no filler. It is perhaps over-terse for a destructive operation, 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. Still, for a destructive single-parameter mutation with 0% schema coverage, the definition omits the account identifier format and the blast radius of the deletion, leaving the agent under-informed.

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

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

Schema description coverage is 0%, so the description must carry the parameter load. 'Суффикс логина FTP' does explain what the bare 'suffix' field means, which is genuine compensation, but it is thin — it does not clarify the suffix relative to the full account name or give an example format.

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 ('Убрать FTP-аккаунт' / remove an FTP account), which is unambiguous and clearly distinguishable from siblings like ftp_add, ftp_list and ftp_change_password. It does not, however, explicitly contrast itself with any sibling, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The agent must infer from the name alone that this is the teardown counterpart to ftp_add.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — no scope note (e.g., which hosting/account context), no pagination or rate-limit remark. It is not contradictory, but it contributes zero behavioral context.

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 short clause with no filler, front-loaded and easy to parse. It is terse to the point of under-specification, but nothing in it 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 an output schema present, return values need not be explained, and with zero parameters the schema side is trivially complete. Still, for a listing tool the description omits any scope or usage context, leaving the definition at minimum viability.

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; the baseline for a parameterless tool is 4. The description correctly implies an unfiltered full listing rather than a lookup by name.

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 fragment 'Все FTP-аккаунты на хостинге' names the resource (FTP accounts) and implies a full listing, so an agent can infer it returns the account list. However, it contains no verb and no explicit statement that it lists rather than manages accounts; the 'list' semantics come mostly from the tool name, not the description.

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 prerequisite note, and no reference to sibling tools such as ftp_add, ftp_delete, or ftp_change_password. The agent must infer from the name alone that this is the read path and the others are the mutating paths.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond what annotations provide — it doesn't mention permission requirements, reversibility, or side effects. A 3 is appropriate given the annotations carry the safety burden but the description adds little.

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

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

The description is front-loaded with the core action and then lists parameters concisely. Every sentence earns its place, though the Args section is somewhat redundant with the schema property names.

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, the description needn't explain return values. Given the annotations cover safety and the description documents all parameters, it is reasonably complete for a simple mutation tool. It could still mention when to use it versus mail_change_settings.

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

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

Schema description coverage is 0%, so the description must compensate. It documents all three parameters (domain, mailbox, password) with clarifying detail — for example, explaining that mailbox is the part before '@' and giving a domain example. This meaningfully fills the gap left by the bare schema, though it could be more precise about password requirements.

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 ('Сменить пароль почтового ящика' — change mailbox password), which is clear and distinct from siblings like mail_change_settings or mysql_change_password. It lacks explicit sibling differentiation, so it falls short of 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 guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, nor how it differs from mail_change_settings, leaving usage context entirely to inference.

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

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

Annotations already declare this is a non-read-only, non-destructive, closed-world mutation. The description usefully adds the '-1 = do not change' convention for the defaults, which tells the agent that omitted optional fields leave settings untouched. It does not describe permissions, reversibility, or side effects beyond that.

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

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

Front-loaded with the purpose, then a compact per-argument list with no wasted filler. The args block is somewhat duplicative of the named schema fields, but necessary since schema coverage is 0%.

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

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

An output schema exists, so return values need not be described. All five parameters are addressed and the required domain/mailbox pair is identifiable, leaving only sibling routing as a gap.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden, and it does so well: it maps spam_filter_status (1/0/-1), spam_filter (-1 = no change), and forward_mail_status (no_forward/forward/forward_and_delete) to concrete meanings. domain and mailbox are only trivially glossed, keeping it from a 5.

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 opening states a clear verb+resource: modifying mailbox settings, specifically the spam filter and forwarding. It does not, however, distinguish this tool from siblings such as mail_forward_add, mail_forward_delete, or mail_set_domain_mail, which overlap in scope.

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

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

There is no guidance on when to use this tool versus the dedicated forwarding tools (mail_forward_add/delete) that are siblings, nor any prerequisites or exclusions. The agent must infer context entirely.

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 state readOnlyHint=false, destructiveHint=false, openWorldHint=false, which is roughly consistent with a reversible config change. However, the description adds nothing beyond the verb: it does not say whether existing forwarded mail is affected, whether the change is immediate, or what confirmation is returned.

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 one-sentence purpose is front-loaded and free of padding; the Args block is boilerplate but brief. Slightly larger than the idea requires but not wasteful.

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 mutation tool with a single undocumented parameter and no useful annotation detail, the description leaves real gaps: no effect on existing catch-all mail, no permissions note, no mention of the inverse operation. An output schema exists, so return values need not be explained, but input behavior still is.

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 only parameter is a bare string titled 'Domain'. The description's 'domain: Домен' merely restates the parameter name and adds no format, FQDN, or validation guidance.

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: disabling catch-all for a domain. It is distinguishable from the counterpart mail_set_domain_mail, though it does not name that sibling 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?

There is no indication of when to use this versus mail_set_domain_mail or mail_change_settings, and no prerequisites or warnings are given. Usage must be inferred from the name alone.

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

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

Annotations already establish readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is carried structurally. The description adds nothing beyond that: it never says what happens if the mailbox already exists, whether quotas or provider-specific limits apply, or that the password cannot be retrieved afterward.

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

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

Very short and front-loaded: the purpose is stated before the Args block, and each parameter line is one sentence. No wasted prose, though the Args section is somewhat boilerplate for parameters whose names are already self-describing.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. What is missing is creation-specific behavior such as duplicate-mailbox handling and quota limits, which matters for a mutating mailbox-provisioning tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: it clarifies that mailbox is only the local part before "@" and gives a domain example (site.ru). However, password carries no format or strength requirements, and the domain/mailbox relationship (must the domain already exist?) is left unexplained.

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?

Concrete verb+resource ("Добавить почтовый ящик" / add a mailbox) is immediately clear and distinguishes the tool from mail_delete, mail_change_password, and mail_change_settings in the sibling set. It stops short of explicitly naming which sibling to prefer for related operations, so it lands at 4 rather than 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives even though several mail_* siblings exist. The agent must infer the entire usage context from the tool name alone.

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 destructiveHint=true, readOnlyHint=false, and openWorldHint=false, which matches the 'remove' wording. Beyond that the description adds nothing: it does not say whether deletion is irreversible, whether mail data/aliases are purged, or what confirmation is required for a destructive operation.

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

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

Very short and front-loaded, which is appropriate, but the Args block essentially duplicates the schema property titles and the whole thing is terse to the point of 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a destructive delete with both parameters undocumented in the schema, the description leaves out any consequence or permission context an agent would want.

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

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

Schema description coverage is 0%, so the description carries the parameter burden. It clarifies that 'mailbox' is the part before the @, which is genuinely useful, but 'domain' is only labeled 'Домен', adding no real meaning over the schema title. Partial compensation 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?

The single phrase 'Убрать почтовый ящик' names a specific verb (remove) and resource (mailbox), so an agent knows exactly what operation it performs. It does not explicitly distinguish itself from siblings like mail_change_password, but the destructive remove semantics against mail_create/mail_list is clear enough.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., mail_clear_domain_mail) and no mention of prerequisites such as the mailbox existing or the deletion being permanent. The description only restates the operation.

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

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

Annotations declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, so the safety profile is structured. The description adds no extra behavioral context such as idempotency, limits on number of forwards, or whether enabling a forward affects mail delivery. With annotations covering the safety basics, this is adequate but not rich.

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

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

The main sentence is front-loaded and concise; the Args block is a minimal restatement of parameters. No wasted prose, though the Args section adds little value.

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

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

An output schema exists, so return values need not be explained. But for a mutation tool with no usage guidelines and thin parameter semantics, the description leaves the agent without enough context about side effects (e.g., overwriting existing forwards, effect on mail routing). Adequate but with clear 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?

Schema description coverage is 0% and the description only repeats the parameter names with short labels (Домен, Имя ящика, Email для пересылки). It does not clarify formats (e.g., whether domain includes scheme, whether forward_mailbox can be external). For a 3-param tool with zero schema coverage, the description should compensate, and it barely does.

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?

Description states a specific action ('Включить пересылку' = enable forwarding) on a specific resource (an email address), so the verb+resource are clear. It is not tautological. However, it does not distinguish itself from siblings like mail_forward_delete and mail_forward_list beyond the obvious 'add' semantics.

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

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

No guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., whether the mailbox must already exist, or whether duplicate forwards are allowed). The reader must infer usage from the name alone.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered by structured fields. The description adds that a single forward entry is being removed (not the mailbox itself), which is useful, but it says nothing about idempotency, required permissions, or behavior when the address is not present. No contradiction with annotations, though destructiveHint=false versus a removal operation is worth noting.

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 single-sentence purpose followed by parameter notes; nothing is wasted. The Args block is somewhat redundant with the schema, but it is short.

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

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

With an output schema present, return values need not be explained, and the annotation set covers the safety profile. What is missing for a three-parameter mutation tool is any statement of preconditions (a forward must already exist), error behavior, or scope of the change — leaving the definition minimally viable rather than 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?

Schema description coverage is 0%, so the description must compensate, and it does so only partially: domain and mailbox glosses merely restate the schema titles ('Domain', 'Mailbox'), while 'Email для удаления из пересылки' does clarify what forward_mailbox means. The format of forward_mailbox (full email vs local part) remains unspecified.

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 — removing a forward for a given mailbox address — so an agent can distinguish it from mail_forward_add and mail_forward_list. It does not, however, name those siblings explicitly, so the differentiation is inferred from tool names rather than stated.

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

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

There is no guidance on when to use this versus mail_forward_add, mail_forward_list, or mail_change_settings. The agent must infer that this is the removal counterpart to mail_forward_add purely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. However, the description adds no behavioral context of its own: no mention of permissions, pagination, empty-result behavior, or what constitutes an entry beyond what the annotations already say.

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 short and front-loads the purpose before the Args block, with zero filler. It is terse rather than padded, though the brevity 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?

An output schema exists, so return values need not be described, and annotations cover the read-only safety profile. For a two-parameter read tool that is minimally adequate, but with 0% parameter coverage and no format guidance, the description leaves real gaps an agent must guess at.

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

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

Schema description coverage is 0%, so the description carries the full burden for the two parameters. It only restates 'domain: Домен' and 'mailbox: Имя ящика', giving no expected format (e.g. whether domain includes a scheme, whether mailbox is a local part or a full address, or whether an alias is accepted), so it fails to compensate for the 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 phrase 'Адреса пересылки для ящика' (forwarding addresses for a mailbox) clearly names the resource being retrieved, and the name mail_forward_list supplies the list verb. It is unambiguous on its own, but it does not differentiate itself from sibling tools such as mail_forward_add/mail_forward_delete or explain the scope of the listing.

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 versus mail_forward_add, mail_forward_delete, or mail_forward_list's relation to mail_change_settings. The agent must infer usage purely from the tool name, and no prerequisites or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the description doesn't need to establish safety. The description adds the domain-scoping constraint, which is useful context, but doesn't cover return format, pagination, or behavior when the domain has no mailboxes. With annotations carrying the safety profile, this is adequate but not rich.

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

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

Very short and front-loaded, with the resource and domain scope stated before the parameter note. No wasted sentences, though the description is arguably under-specified rather than concise in a positive way.

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 an output schema, the essentials (resource, required domain parameter with example) are present. Still missing which mailbox attributes are returned or how results are ordered, but the output schema likely covers return values.

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 only the description documents the single parameter, including a concrete format example ('сайт.ru'), which compensates for the missing schema description. There's only one parameter, so there's limited additional semantic depth to provide.

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 the resource ('почтовые ящики', mailbox list) and a domain scope, which roughly implies a listing operation. However, it uses a noun phrase without an explicit verb like 'list', and doesn't distinguish itself from siblings such as mail_create or mail_delete in the mail_* family. Purpose is inferable but weakly specific.

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

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

There is no guidance on when to use this tool versus related mail tools (mail_create, mail_delete, mail_forward_list) or domain tools. An agent must infer usage from the name alone, with no conditions or exclusions provided.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this is a non-destructive write. The description adds little beyond that: it doesn't say whether it overwrites an existing catch-all, what happens on failure, or that it requires the domain to exist. Minimal behavioral context for a mutation 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?

The one-line purpose is front-loaded and efficient, but the Args block merely repeats parameter names, adding length without value. Adequate but not tight.

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

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

An output schema exists, so return values need not be explained. However, for a two-parameter mutation with 0% schema coverage and minimal annotations, the description is too thin: it doesn't explain parameter meaning, side effects, or prerequisites. Gaps remain an agent would need 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 description coverage is 0%, so both parameters are undocumented in the schema. The description only restates the parameter names in Russian ('domain: Домен', 'domain_mailbox: Имя ящика...') without adding format, constraints, or examples. This does not compensate for the 0% 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?

States a specific verb+resource: setting a catch-all mailbox for a domain. The Russian description ('Назначить catch-all ящик для домена') clearly identifies the operation and distinguishes it from siblings like mail_create or mail_clear_domain_mail. Not a perfect 5 because it assumes the agent understands 'catch-all' semantics.

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 guidance or alternatives named. The agent must infer this is the right tool versus mail_clear_domain_mail (to remove) or mail_create (to make a specific mailbox). No conditions, prerequisites, or exclusions are stated.

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

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

Annotations declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false. The description adds substantial value beyond annotations: it specifies exactly which records are set (MX and TXT SPF with exact values), what is preserved (other TXT records are kept), what is not touched (A records, NS, other TXT), and the special requirement that CAA/SRV records necessitate force=True. This goes well beyond the binary annotation flags, though it doesn't discuss permissions or rate 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 description is a single, well-structured block that front-loads the core action (setting MX and SPF) followed by details on values, preservation, and side effects. It is reasonably sized for a DNS mutation tool, though the DKIM note is somewhat tangential since it describes a manual step not performed by this 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 that an output schema exists, the description need not explain return values. It adequately covers what the tool does, which records are modified, what is preserved, and the force parameter's purpose. It lacks explicit usage guidelines and full parameter semantics, but for a destructive DNS operation with clear annotations, it provides enough context to invoke 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 0%, meaning the parameters fqdn and force have no formal descriptions. The description does mention fqdn (domain name) and force (continue when CAA/SRV exist), which adds meaning beyond the bare schema titles. However, the description only partially compensates for the zero coverage — it doesn't explain the fqdn format or edge cases for force. The provided info is useful but insufficient for full parameter understanding.

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 and verb: it sets MX and SPF records for Mail.ru for business in one call. It clearly contrasts with siblings like dns_set_mx or dns_set_txt by being a bundled setup, and the sibling mail_setup_yandex suggests a parallel purpose, but the description does not explicitly differentiate itself from all other DNS/mail setup tools. The inclusion of exact MX and SPF values makes the tool's unique bundling 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?

Usage context is implied (for setting up Mail.ru business email), but there is no explicit when-to-use or when-not-to-use guidance. The tool doesn't state prerequisites like domain ownership verification or that it should be used instead of individual dns_set_mx and dns_set_txt calls. It also doesn't mention alternatives such as mail_set_domain_mail or mail_setup_yandex.

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 destructiveHint/readOnlyHint annotations by disclosing exactly what is replaced (MX, SPF), what is preserved (other TXT, A, NS), and the destructive consequence of force with CAA/SRV. This is the kind of irreversibility detail annotations cannot express.

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 the one-line purpose, then structures the record details, DKIM note, and safety warning as distinct blocks. Slightly verbose in the DKIM section, but every block carries actionable information.

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