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

No annotations are provided, so the description carries the full behavioral burden. For a mutation tool it discloses none of the relevant traits: whether an existing same-name/type record is overwritten, whether the change propagates/deletes anything, permission or auth requirements, 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?

Two short sentences, purpose front-loaded followed by supported types; every clause has a purpose, though the type enumeration is redundant with the schema enum.

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 no annotations, no output schema, and no description of return value or failure modes. The description omits success/error behavior and any prerequisite context, which is a substantial gap for an agent invoking a write operation.

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

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

Schema description coverage is 100%, so all six parameters including the record_type enum are already documented in the schema; the description's record-type list merely repeats the enum. Baseline 3 applies since the description adds no format or conditional semantics 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 (add) and resource (DNS resource record to a domain zone) and enumerates the supported record types. It clearly differs from get/update/delete siblings by name, though it doesn't explicitly contrast itself with regru_batch_update_dns or regru_update_domain_dns.

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 about choosing this over regru_batch_update_dns for multiple records, no prerequisites (e.g. domain must exist/be delegated), and no mention of conflict behavior with existing 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?

With no annotations at all, the description carries the full behavioral burden for a mutating DNS tool, and it says nothing about atomicity, partial-failure behavior, rollback, or required permissions. It does not reveal whether the batch is all-or-nothing, which is the single most important trait of a batch mutation. Only the mutation nature is conveyed.

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

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

A single front-loaded sentence with no filler, stating the batch scope and the supported action verbs immediately. It is efficient, though it is so short that brevity comes at the cost of the behavioral detail a batch mutation needs.

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

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

The schema is fully described and there is no output schema, so return values need not be explained. Still, for a batch write with no annotations, the description omits failure semantics, ordering, and size limits, leaving gaps an agent would want before calling it.

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

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

Schema description coverage is 100%, including nested item fields (action enum, record_type, content, subdomain, ttl, priority), so the schema already documents the inputs thoroughly. The description adds only the broad notion of 'actions' and no syntax, limits, or per-action detail beyond the schema; baseline 3 applies.

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

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

States a specific verb (batch update) and resource (DNS records) plus the supported operations (add/delete), which cleanly separates it from the single-record siblings regru_add_dns_record and regru_delete_dns_record. It never names those siblings explicitly, so the differentiation is implied rather than stated.

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

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

"in a single batch request" implies the tool is for multiple operations at once, which is enough for an agent to prefer it over single-record calls when batching. However, there is no explicit when-to-use/when-not guidance, no mention of ordering constraints, and no statement about whether mixing add and delete in one call is expected.

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

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

With no annotations, the description carries the full burden. It does disclose the return content (availability status plus pricing per domain) which is useful, but says nothing about batch size limits, rate limits, or lookup failures for malformed domains. Low-risk read semantics are implied only by the verb, not stated.

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, front-loaded sentences with no preamble. The second sentence largely restates the output already named in the first, making it mild redundancy rather than added 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?

For a two-parameter read-only lookup with no output schema, the definition is adequate: it says what is returned (availability and price) for each domain and the schema covers both inputs. Missing only operational detail such as batch limits or handling of invalid domain strings.

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

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

Schema description coverage is 100%, so the domains array and currency enum (RUR/USD/EUR) are already fully documented. The description's 'one or more domains' confirms batching but adds no format or currency behavior beyond the schema, so the baseline 3 applies.

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

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

Names a specific verb (check) and resource (domains) and states the two outputs (availability status, pricing), which separates it from the DNS-oriented siblings. It does not explicitly name or contrast regru_suggest_domains, so differentiation is inferable 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 when-to-use guidance, no prerequisite (e.g. run before regru_renew_service or a purchase flow), and no mention of the alternative regru_suggest_domains for finding names. Usage is only implied by the verb 'check'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool creates a folder but omits any mention of permissions, side effects, what happens with duplicate names, or the response format—significant gaps 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 description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple one-parameter tool and communicates the essential purpose immediately.

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

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

Given the low complexity (one required parameter, no nested objects) and no output schema, the description needs to cover only purpose and invocation context. It does that minimally, but with no annotations and no behavioral details, it remains just adequate 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?

The input schema describes the single parameter (folder_name) with 100% coverage, so the schema already carries the semantic load. The description adds no additional meaning beyond what the schema provides, making the baseline score of 3 appropriate.

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

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

The description gives a specific verb and resource ('Create a new folder') and adds the purpose ('to organize services'), so the tool's function is clear. It does not explicitly differentiate itself from sibling tools like regru_list_folders or regru_move_service_to_folder, but the core purpose is unambiguous.

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

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

The description offers no when-to-use guidance, no prerequisites, and no alternatives. It only states the action, leaving the agent to infer context from the sibling tool list and the generic phrase 'to organize services'.

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

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

With no annotations provided, the description carries the full behavioral burden, yet it only states the action. It does not disclose whether deletion is irreversible, what happens if the record is not found, whether permissions or confirmations are required, or how multiple matching records are handled.

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

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

A single, front-loaded sentence with no wasted words. The action and resource are stated immediately.

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

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

For a destructive operation with no annotations and no output schema, the description is too thin. It omits safety context, error behavior, and any indication of what a successful deletion returns, leaving key agent decisions unsupported.

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

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

Schema description coverage is 100%, so all four parameters are documented in the schema. The description adds no parameter-level information, which is acceptable at baseline when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource ('Delete a DNS resource record from a domain zone'), making the operation immediately understandable. It does not explicitly differentiate itself from siblings like regru_add_dns_record or regru_update_domain_dns, 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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent is left to infer that deletion is appropriate only when a record should be removed.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether it requires authentication, whether it hits rate limits, or what the response format looks like. Only the basic action is conveyed.

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

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

A single, well-structured sentence that front-loads the action and resource with zero waste. Appropriate length for this simple tool.

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

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

For a simple one-parameter read tool, the description is minimally adequate. However, with no output schema and no annotations, it should at least indicate the return type (e.g., a monetary amount) and note that it is a read-only operation, which would improve completeness.

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

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

Schema description coverage is 100%, so the parameter 'currency' is already fully documented (including default and enum-like values). The description adds no additional meaning beyond that, making 3 the appropriate baseline per the rules.

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 ('Get') and resource ('account balance'), making the purpose immediately clear. However, it does not distinguish itself from siblings or clarify what 'account balance' means in the context of the other tools, 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?

The description implies usage (when you need balance info) but provides no explicit when-to-use or when-not-to-use guidance. No alternatives or prerequisites are mentioned, leaving the agent without routing context.

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

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

No annotations are provided, so the description carries the full behavioral burden. While 'Get' implies a read-only operation, the description does not disclose return format, pagination behavior, zone scoping semantics, or any permission requirements.

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, efficiently front-loaded sentence with no wasted words. It states the action and scope immediately.

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

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

For a simple one-parameter read tool the description is roughly adequate, but with no output schema and no annotations it does not explain the return shape, and it omits the sibling differentiation needed to choose between the several DNS-reading tools.

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

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

Schema description coverage is 100% for the single domain_name parameter, so the baseline is 3. The phrase 'for a domain zone' slightly clarifies that domain_name identifies the zone, but adds little 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?

The description states a specific verb ('Get') and resource ('all DNS resource records for a domain zone'), making the operation clear on its own. However, it fails to distinguish itself from the very similar sibling regru_get_domain_dns, leaving the agent unable to tell them apart without consulting schemas.

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

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

There is no indication of when to use this tool versus alternatives like regru_get_domain_dns or regru_get_domain_dns, and no prerequisites or exclusions are stated. 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?

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a non-mutating read, but there is no mention of permission requirements, whether the domain must be registered/served by the account, or what the response contains (e.g. a list of NS hostnames).

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

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

One short, front-loaded sentence with no filler. The only blemish is the inaccurate abbreviation 'NSS' for name servers, which could momentarily confuse an agent.

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

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

For a simple one-parameter read with no output schema and no annotations, the description is minimally adequate but omits the return shape (NS hostname list) and any prerequisite about the domain being managed in the account. The absence of an output schema makes documenting the return value more valuable 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?

Schema description coverage is 100% for the single domain_name parameter, so the schema already documents the input; the description adds no format or naming details. Baseline 3 applies when the schema does the heavy lifting.

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 ('Get') and resource ('DNS name servers for a domain'), so the agent knows exactly what is retrieved. It does not distinguish itself from the nearby sibling regru_get_dns_records, which plausibly returns the same or overlapping data, so sibling differentiation is missing.

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

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

No statement of when to use this tool versus regru_get_dns_records or regru_update_domain_dns. The agent must infer from the name alone whether this is the NS-only lookup or a superset.

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

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

No annotations are provided, so the description carries the full burden. It says nothing about what 'detailed information' includes, whether either lookup key is required, whether the call is read-only, or any error behavior when neither identifier is given.

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

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

A single, well-formed sentence with the key lookup semantics front-loaded. Every word earns its place.

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

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

For a simple two-parameter read tool with full schema coverage, the description is minimally viable. Without annotations or an output schema, it should say more about what 'detailed information' returns and that neither parameter is required.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds the useful constraint that domain_name is an alternative to service_id, but no syntax or format details beyond that. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (get) and resource (service info), and clarifies the two lookup keys (service ID or domain name). It is distinguishable from siblings like regru_list_services (listing) and regru_renew_service (mutation), though it doesn't explicitly name an alternative.

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 'by service ID or domain name' clause implies usage context (lookup by identifier), but there is no explicit when-to-use vs alternatives guidance or exclusions. Adequate but with clear gaps.

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

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

No annotations are provided, so the description carries the full disclosure burden. It conveys only scope ('all ... in the account') and nothing about read-only safety, pagination, result caps, or authentication requirements for a billing-related 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?

One tight sentence with no filler, and the resource is stated immediately. It is appropriately sized for a parameterless list tool, though it is so short that nothing is front-loaded against anything else.

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

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

For a zero-parameter, no-output-schema tool this is minimally adequate: the agent knows what it gets. It falls short of complete by omitting whether the list is paginated, sorted, or bounded, which matters for a 'get all' call on bills.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the account-wide scope, which it already implies.

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

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

The description states a specific verb ('Get') and resource ('all unpaid bills in the account'), so the agent knows exactly what it retrieves. It does not differentiate itself from the nearest sibling (regru_get_balance), which also touches billing, but the resource itself is unambiguous.

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

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

There is no statement of when to use this tool versus regru_get_balance or any other sibling, and no prerequisites or exclusions. Usage is only weakly implied by the word 'unpaid'.

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

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

No annotations are provided, so the description carries the behavioral burden. 'List' strongly implies a safe, read-only enumeration and the zero-parameter schema means there is little mutation risk, but the description never states permissions required, whether folders are nested/hierarchical, or anything about the response shape.

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

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

A single efficient sentence with the resource stated up front and no filler. Nothing could be trimmed without losing meaning.

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 trivial zero-parameter read tool with no output schema, the description conveys enough to call it correctly: what is listed and what folders represent. Only minor gaps remain, such as whether the listing is flat or nested.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies 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?

States a specific verb and resource ('List all folders in the account') and adds scope ('used to organize services'). It is distinguishable from sibling mutations like regru_create_folder and regru_move_service_to_folder, but it does not explicitly contrast itself with them.

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

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

No when-to-use guidance is given. There is no mention of alternatives (regru_create_folder for creation, regru_move_service_to_folder for organizing) or of any precondition such as needing folders to already exist. The agent 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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only operation, but the description says nothing about pagination, result size limits, authentication requirements, or the shape of the returned service 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?

Two sentences, zero waste, and the core action is front-loaded before the optional filter detail. Nothing in the text is redundant given its short 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?

For a simple single-parameter read tool this is close to adequate, but with no annotations and no output schema the description should at least sketch the return content (what a 'service' entry contains) or note pagination behavior. As written, gaps remain that an agent cannot fill from structured fields.

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

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

Schema description coverage is 100% and the single optional parameter is already documented in the schema, so the baseline is 3. The description's parenthetical examples ('domain', 'hosting') echo the schema's own examples rather than adding new meaning.

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

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

States a specific verb and resource ('List all services in the account') and defines the scope as the whole account. It does not differentiate itself from siblings such as regru_get_service_info or regru_list_folders, so an agent must infer the boundary between listing services and inspecting a single service.

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 word 'Optionally' signals that the filter is not required, which gives implied usage. However, there is no guidance on when to use this versus regru_get_service_info, no prerequisites, and no exclusions, so the agent must reason about alternatives on its own.

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

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

No annotations are provided, so the description carries full behavioral burden. It says nothing about permission requirements, whether enabling/disabling is reversible or takes time to propagate, what happens if the domain lacks DNSSEC support, or any side effects. For a mutation tool this is a significant gap.

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

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

A single front-loaded sentence with no wasted words. It immediately states the resource and the available actions.

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 tool is low-complexity with only two parameters and no output schema, so the description need not explain return values. However, given the absence of annotations and the state-changing nature of two actions, it should provide more context about effects and prerequisites.

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

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

Schema coverage is 100% and the action enum is fully described in the schema itself. The description merely restates the actions and adds no format, syntax, or semantic detail beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description states a specific verb (manage), resource (DNSSEC), and scope (for a domain), then enumerates the three actions. It clearly distinguishes the tool from all DNS-record siblings, which do not touch DNSSEC.

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 three actions imply usage (check status, enable, disable), but the description gives no explicit context about when this tool should be chosen over the sibling DNS tools, nor any prerequisites or when-not conditions. Usage 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the move is reversible, whether the service is removed from its prior folder, what permissions are required, or what happens if the target folder_id does not exist.

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

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

A single efficient sentence with the action and target front-loaded. Nothing is wasted, though it is arguably too terse to earn a full 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?

This is a mutation tool with no annotations and no output schema, yet the description omits any effect description, failure modes, or return information an agent would need. Given the complexity and absence of structured support, it should say considerably more.

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

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

Schema description coverage is 100% and both parameters (service_id, folder_id) are documented in the schema, so the baseline is 3. The description adds no meaning beyond what the schema already conveys about these two numeric IDs.

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 ('Move a service') plus a target ('to a specific folder'), which is unambiguous. It does not explicitly name a sibling alternative, but no sibling performs a move, so differentiation is implicit rather than stated.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as create_folder or list_folders. An agent gets no signal about the conditions under which moving is appropriate versus creating a new folder.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that this is a billing operation that incurs cost, which is meaningful context beyond the name, but it omits permissions required, reversibility, and consequences of failure or insufficient funds.

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

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

Two short sentences, front-loaded with the action and followed by a useful cost caveat. Slightly redundant given the period parameter already exists, but there is essentially no waste.

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 billing mutation with no annotations and no output schema, the description gives the essential purpose and a cost warning but leaves gaps around authorization, idempotency, and what happens when funds are insufficient (only implied by the ok_if_no_money parameter). Adequate but not 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 100%, so all three parameters (service_id, period, ok_if_no_money) are already documented in the schema. The description adds nothing beyond the schema's own parameter documentation, making the baseline 3 appropriate.

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

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

The description states a specific verb (Renew) and resource (a service), and clarifies scope with examples (domain, hosting, etc.). It is clear what the tool does, but it does not distinguish itself from the sibling regru_set_autorenew, which an agent could easily confuse with an on-demand renewal.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of the autorenew alternative. The reader must infer that this is for manually extending a service term, with nothing routing them away from regru_set_autorenew.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: it does not say whether the call is idempotent, whether it requires ownership/permissions, whether the change is reversible, or what happens if the service is already expired. For a mutation tool this is a significant gap.

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

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

A single front-loaded sentence with no filler, so the action is immediately clear. It is arguably too terse to be 'appropriately sized' for a state-changing tool, keeping it out of the top band.

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 tool is simple (2 required params, full schema coverage, no output schema), so little is strictly needed. Still, a mutation with zero annotations leaves behavior, auth, and reversibility unexplained, which is a clear but modest 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 100%, so both service_id and flag are already documented, including the true/false meaning of flag. The description adds no syntax, format, or edge-case detail beyond the schema, which is the baseline-3 case.

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

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

The description names a concrete verb pair (enable/disable) and a specific resource (automatic renewal for a service), which is unambiguous. It does not, however, differentiate itself from the sibling regru_renew_service, 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 guidance on when to toggle auto-renewal versus using regru_renew_service, no prerequisites, and no stated conditions. 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?

With no annotations and no output schema, the description carries the full burden, but only says it returns 'available similar domains' – no detail on how many results, whether availability is freshly checked, pricing, or rate limits. The one behavioral claim (availability) is unverifiable and undetailed.

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 economical sentences with the action front-loaded and the return value second. No filler, though the second sentence is nearly redundant with the first.

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

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

For a simple one-parameter lookup tool the description is minimally adequate – it covers input source and return shape. It is thin on the behavioral side (result count, whether availability is real-time) and omits any routing to sibling tools.

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

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

There is a single parameter with 100% schema description coverage, so the schema already explains 'word' as the keyword. The description adds nothing beyond that; baseline 3 applies.

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

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

States a specific verb (Get/suggest) and resource (domain name suggestions) plus the input basis (keyword), which is enough to separate it from regru_check_domains. It stops short of explicitly naming how it differs from the check/registration siblings.

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

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

No when-to-use guidance and no alternatives named, even though regru_check_domains sits right next to it and answers an easily confused question (availability vs ideation). The agent must infer that this is for brainstorming rather than verifying.

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

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

With no annotations, the description carries the full burden. It does disclose the effect — replacing authoritative name servers — which is meaningful for a mutation, but says nothing about permissions, whether it replaces or appends the list, propagation delay, reversibility, or failure behavior.

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

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

Two short, front-loaded sentences with no wasted preamble. The second sentence largely restates the first ('Update name servers' vs 'Changes the authoritative name servers'), so it is slightly redundant rather than perfectly lean.

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

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

For a two-parameter mutation tool with no output schema, the definition covers the action but omits the operational context an agent needs to call it safely (propagation side effects, whether existing NS are replaced). 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 100% for both parameters (nss array with an example, domain_name), so the baseline is 3. The description adds no syntax, ordering, or minimum-NS requirements beyond what the schema already provides.

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 ('Update') and resource ('DNS name servers / NSS for a domain'), and the second sentence clarifies it targets the authoritative name servers rather than individual DNS records. This implicitly separates it from sibling record-level tools like regru_add_dns_record, but it never names an alternative explicitly.

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

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

No guidance on when to use this vs. regru_get_domain_dns, regru_add_dns_record, or regru_batch_update_dns. No prerequisites (domain ownership, existing NS state) and no exclusions are stated, so the agent must infer routing 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.