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

Annotations already declare that this is a non-read-only, open-world, idempotent, non-destructive operation. The description adds useful timing context ('propagation can take up to a few hours'), but does not explain duplicate-record handling, required account permissions, or immediate effects beyond 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 sentences that front-load the action and then add the key timing caveat. Every sentence earns its place with no redundant or vague phrasing.

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 and annotations cover the safety profile, so the description need not explain return values or mutation semantics. It adds propagation timing, but does not address record conflicts or account prerequisites, leaving a minor gap for a mutation 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 80%, so the schema already documents most parameters such as name, value, domain, and ttl. The description adds no parameter syntax, constraints, or examples beyond what the schema provides, making the baseline 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?

States a specific verb ('Add') and resource ('a record to a domain's DNS zone'). It clearly distinguishes the action from sibling tools such as update_dns_record, delete_dns_record, get_dns_zone, and check_dns_propagation without requiring schema inspection.

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 guidance on when to use this tool versus update_dns_record or delete_dns_record, and no conditions or alternatives are named. Usage is only implied by the word '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 cover the safety profile (readOnly, openWorld), and the description adds genuinely useful behavior: it discloses that public resolvers may serve stale answers until TTL expiry and that the response reports how long a stale answer can last. It does not detail auth or rate limits, but for a read-only diagnostic this is solid additional 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?

Two tightly written sentences with the core comparison front-loaded and the TTL caveat following. Every clause earns its place with no redundancy.

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

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

Given an output schema exists (so return values need not be explained), the description covers what is compared, why results may disagree, and the TTL interpretation. An agent has everything needed to call and interpret 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 100%, so all three parameters (name, type, expected) are already documented with a helpful example ('_dmarc.example.fr') and a default. The description only indirectly references 'expected' via the phrase 'what is saved in the LWS zone', adding nothing 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?

States a specific verb+resource ('check whether a DNS change is live') and enumerates exactly what it compares: the LWS zone, the domain's nameservers, and three named public resolvers. This is precise enough to distinguish it from the sibling read tool get_dns_zone.

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

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

The framing 'check whether a DNS change is live' clearly implies the post-change verification use case, and the TTL note signals it is meant to explain temporary resolver disagreement. It does not explicitly name alternatives (e.g. get_dns_zone for reading the saved zone), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile (a safe, non-mutating external lookup) is covered. The parenthetical '(data is true when available)' adds a small interpretation hint, but since an output schema exists it largely restates the return contract rather than revealing traits annotations don't cover, such as latency, caching, 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?

A single tight sentence with the action front-loaded and no filler. It is appropriately sized for a one-parameter lookup, though the trailing parenthetical is slightly redundant with the output schema.

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

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

For a simple one-parameter read tool whose annotations convey the safety profile and which ships an output schema, the description covers the essentials. The only real gap is absent usage/routing guidance, which is minor at this complexity 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 100% and the single 'domain' parameter is fully documented in the schema with an example and a validation pattern. The description adds no syntax, TLD, or formatting detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb ('Check') plus resource ('domain name') and the exact outcome ('free to register'), so an agent immediately knows this is an availability lookup rather than a registry read like get_domain. It does not explicitly name a sibling, but the purpose is unambiguous on its own.

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, when-not-to-use, or alternative guidance. The description never mentions how this differs from get_domain or when a caller should choose it over the domain-listing tools. The intended use is only implied by the verb.

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, idempotent, open-world write, so the safety profile is covered. The description adds only the account-scoping semantic; it says nothing about duplicate-email behavior, whether the contact becomes immediately selectable as an owner, or that the password provisions a customer area — relevant for a mutation with these 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?

A single efficient sentence, front-loaded with the action and followed by the useful ownership context. No filler, though the brevity is partly under-specification rather than tight editing.

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, but for a 9-required-parameter mutation at 40% schema coverage the description is too thin: no required-field guidance, no password/customer-area context, no indication of what happens on duplicate or conflicting data.

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 10 parameters, 9 required, and only 40% schema description coverage, the description carries a compensation burden it does not meet — it mentions no fields at all. Required identity fields (firstname, lastname, address, postal, city) and the password semantics are left entirely to 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 gives a specific verb+resource ('Create a contact') and adds meaningful scope: the contact is account-managed and usable as owner of domains and hostings. It clearly distinguishes the create action from siblings like get_contact, update_contact, and list_contacts, though it never names them explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., when to reuse an existing contact via list_contacts/get_contact instead of creating a new one). The phrase 'usable as owner of domains and hostings' hints at downstream context but does not tell the agent when this tool is the right call.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true). The description adds only the scoping notion of redirecting a 'whole domain,' and says nothing about the effect on existing redirects, idempotent behavior, or permission needs beyond what annotations provide.

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 waste that immediately conveys the operation and scope. Nothing is padded or buried.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. But for a mutation tool with a 301/302 distinction, the description is thin on behavioral context (idempotency semantics, effect on pre-existing redirects). 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%, with url, domain, and the 301/302 type enum all documented in the schema itself. The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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

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

It states a specific verb and resource (create a redirect for a domain) in a single clear phrase, so an agent knows exactly what the tool does. It does not, however, name or differentiate itself from the sibling delete_domain_redirect or explain the redirect scope relative to other domain 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?

The description offers no when-to-use context, no prerequisites, and no mention of the sibling delete_domain_redirect as the inverse operation. An agent gets the action but no guidance on when this tool is the right choice 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 destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds real value beyond them by disclosing the concrete blast radius ('a wrong record can take a site or mail down') and the verification step to mitigate it.

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 with zero waste. The core action is front-loaded, and the safety warning follows immediately as justification for the prerequisite.

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 annotations covering destructiveness, a full output schema present, and 100% parameter documentation, the description only needs to add procedural and risk context — which it does. Minor gap: no note on irreversibility or confirmation behavior, but nothing critical is missing.

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

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

Schema description coverage is 100%, so both `id` and `domain` are already documented in the schema. The description reinforces the provenance of `id` (obtained via get_dns_zone) but adds no format or constraint detail beyond the schema, 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?

States a specific verb and resource ('Delete a DNS record'), which cleanly separates it from sibling write tools like add_dns_record and update_dns_record. An agent can identify the operation without opening the schema.

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

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

Explicitly gives a prerequisite workflow ('Check the id with get_dns_zone first'), naming the sibling tool to use for verification, plus a concrete reason. It lacks an explicit when-not-to-use or fallback (e.g., update vs delete), so it falls just short of a 5.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: idempotency ('succeeds even if there was none'), which an agent would otherwise have to discover empirically.

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 waste; every clause earns its place by conveying the action and the idempotency guarantee.

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. The idempotency note fills the main behavioral gap; permissions requirements are not mentioned but are minor for a single-param delete.

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 domain parameter already has a format description and regex pattern in the schema. The description adds nothing about the domain parameter, 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?

States a specific verb (Remove) and resource (a domain's redirection), clearly distinguishing it from the sibling create_domain_redirect. No ambiguity about the operation.

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

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

The parenthetical idempotency note implies safe repeated use, but there is no explicit when-to-use guidance or referenced alternatives. Usage context is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: the account is prepaid and the value is denominated in EUR. It does not mention freshness of the balance, whether it can go negative, or auth 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 front-loaded sentence with no filler; the resource and its unit are stated immediately and nothing is repeated.

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

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

With an output schema present and annotations covering read-only/open-world behavior, the description only needs to frame the resource, which it does. Minor gaps remain (what the balance reflects, e.g. pending charges or negative states) but nothing blocking.

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. No parameter semantics are needed or missing.

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?

Precise verb+resource: 'Get' the 'remaining balance of the prepaid account', qualified by the unit 'in EUR'. No sibling tool covers account balance, so the resource is unambiguous without needing 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?

No explicit when-to-use or prerequisite guidance is given, but the usage is self-evident from the purpose (check available funds, e.g. before request_transfer_authcode) and there are no competing siblings to route between. Implied usage only.

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 and openWorldHint=true, so the safety profile is covered without description help. The description adds a small amount of context by scoping what data the contact record contains, but says nothing about missing/invalid IDs, permissions, or errors, so it is adequate rather than 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?

One tight sentence, front-loaded with the verb and resource, and the parenthetical list of fields is compact. 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 the description need not explain return values, and annotations carry the safety profile. For a single-parameter read tool the definition is nearly sufficient; only failure/edge-case behavior (nonexistent ID, permission needs) is unaddressed.

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

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

Schema coverage is 100% with a single, fully documented `contact` parameter (ID, minimum 1, pointer to list_contacts). The description adds no syntax or format detail beyond the schema, so the baseline 3 for high coverage 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?

Specific verb (Get) plus resource (contact) with the returned fields enumerated, so the agent immediately knows this is a single-record lookup rather than the list variant. It does not name or contrast itself with list_contacts, which is the closest sibling, so it falls short of full 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 gives no when-to-use guidance, no prerequisites, and no reference to alternatives such as list_contacts. The only routing hint ("see list_contacts") lives in the schema's parameter description, not in the tool description 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=true and openWorldHint=true, so safety is covered. The description adds only the field list; it says nothing about filtering behavior, pagination, or that name/type act as optional filters — the schema carries that. Little beyond 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 tight sentences, front-loaded with the core action and closing with the practical next step. 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?

An output schema exists so return-value explanation is unneeded, and annotations cover the read-only profile. However, with three parameters that act as filters, the description omits how filtering works, leaving the agent to rely entirely on schema descriptions.

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 each parameter is documented in the schema (name filter, type filter, domain pattern). The description adds no syntax or semantic detail beyond it, so baseline 3 applies.

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

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

States a clear verb (List) and resource (DNS records of a domain), and enumerates returned fields. Distinguishes itself from add/update/delete_dns_record siblings by being the read operation, though it doesn't explicitly name 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?

Gives a concrete usage path: read here, then use the returned ids to update or delete records. This implicitly positions it as the precursor to the mutation siblings, but does not state when to use this vs check_dns_propagation or filter 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 and openWorldHint=true, so the safety profile is covered. The description adds the concrete return payload and names the status flags, but says nothing about auth requirements, whether the domain must belong to the account (that detail sits in the schema), 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?

A single front-loaded sentence with no filler; the resource and the payload are both stated immediately and nothing repeats structured fields.

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 documented, and the description nonetheless signals what the response contains. For a one-parameter read tool, nothing essential to calling 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?

Only one parameter, and schema description coverage is 100% — the schema already explains the domain format with a pattern and an example. The description contributes no additional parameter meaning, 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?

States a specific verb (Get) plus resource (domain) and enumerates what it returns: owner, nameservers, and status flags such as redemption, hold, and transfer lock. That is enough for an agent to distinguish it from get_dns_zone or list_contacts, though it never names a 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?

Usage is implied by the enumerated contents — you call it to inspect registration-level data for a domain. There is no explicit when-to-use, no exclusions, and no pointer to the alternative tools that return DNS records or contact details.

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 and openWorldHint=true, so the safety profile is covered. The description adds the field list returned, which is useful context, but says nothing about auth requirements, failure modes, or lookups for nonexistent hostings.

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

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

A single front-loaded sentence that enumerates exactly what is retrieved with zero filler. Nothing to trim.

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

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

An output schema exists, so return values needn't be explained, and the read-only annotations cover safety. For a simple one-parameter read tool the description is essentially sufficient, though usage context is absent.

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

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

Schema coverage is 100% with the single 'hosting' parameter fully documented ('Domain name the hosting is attached to'). The description adds no format or syntax detail beyond that, so baseline 3 applies.

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

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

States a specific verb+resource ('Get a hosting') and enumerates the fields returned (package, dates, nameservers, auto-renewal), making it identifiable against siblings like get_domain or list_hostings. It does not explicitly name a sibling it differs from, 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?

Provides no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_hostings. The agent must infer that this retrieves detail for a single named hosting.

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 and openWorldHint=true, so the safety and external-reach profile is covered. The description adds no behavioral detail beyond that — no mention of pagination, result limits, time-range coverage, or account scoping. With annotations carrying the load, a 3 is appropriate, but nothing extra is contributed.

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 padding. The only wasted phrase is 'made through the API', which adds no discriminating information, but overall the entry is 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?

With zero parameters and an output schema present, the description does not need to explain return values, and it correctly covers the tool's purpose. It stops short of noting scope or pagination behavior, which is a minor gap for such a simple list tool.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly implies a no-argument, list-everything call.

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 (List) and a concrete resource (purchases, renewals, other transactions), so an agent knows this returns transaction history. It does not differentiate itself from siblings such as get_account_balance or list_requests, and the trailing 'made through the API' is filler rather than a scope qualifier.

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 context, no prerequisites, and never names an alternative among the 25 sibling tools. An agent has no guidance on when purchase history is the right call versus get_account_balance or list_requests.

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 and openWorldHint=true, so the safety profile is covered. The description adds that it surfaces expiry status, but doesn't mention rate limits, caching, or whether the price is live/authoritative. Adequate but not rich beyond 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 tightly-packed sentences: the first states the payload, the second the sequencing. Zero filler, front-loaded with the core purpose.

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

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

For a single-param read tool with an output schema, the description covers purpose, returned fields, and workflow placement. Minor gap: no note on failure cases (e.g., unknown domain) or price currency/freshness.

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

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

Schema coverage is 100% and the single 'hosting' param is fully documented in the schema as 'Domain name the hosting is attached to.' The description adds no syntax or format detail beyond this, so baseline 3 applies.

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

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

States specific verb (get) and resource (renewal price) plus names the exact sub-components returned (hosting, domain, options) and expiry status. Clearly distinguishable from siblings like list_hosting_prices or get_hosting, which don't scope to renewal pricing.

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 says 'Check it before renew_hosting,' giving both the trigger condition and the sequencing relative to a related action. This is actionable when-to-use guidance tied to a concrete workflow.

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 and openWorldHint=true, so the safety profile is covered. The description adds one useful piece of behavioral context, 'keyed by contact ID,' but says nothing about pagination, result volume, or account scoping 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?

A single front-loaded sentence with no filler or redundancy. Every clause earns its place.

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

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

With no parameters, an output schema present, and annotations covering the safety profile, the description carries little burden. It is adequate, though a one-line note on pagination or result size would fully close the 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 is nothing for the description to disambiguate, and the schema coverage is 100% regardless.

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 (List) and resource (contacts) with a clear scope qualifier ('managed by the account'). It is distinguishable from get_contact/create_contact/update_contact by implication, but it never names or contrasts a 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 when-to-use guidance, no prerequisites, and no pointer to the alternatives (get_contact for a single contact, create_contact/update_contact for mutations). Usage is only implied by the word 'List'.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful scoping detail ('every' package, prices denominated in EUR), but says nothing about ordering, pagination, or freshness of prices, which would be genuinely additive 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?

A single front-loaded sentence that names the resource, the scope, and the currency with no wasted words. Nothing is buried and nothing could be cut without losing 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 zero-parameter, read-only listing tool with an output schema, the description covers the essentials: what is listed and in what currency. Return-value details are correctly left to the output schema; only ordering and freshness of pricing are unaddressed.

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 per the rubric the baseline is 4; there are no parameter semantics the description could clarify. The currency note is a useful but small extra.

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 (list), resource (hosting packages), and payload (monthly price in EUR), so an agent immediately knows what it returns. It does not name or distinguish itself from nearby siblings such as list_hostings or get_renewal_prices, which is the only thing keeping it from 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 explicit statement of when to call this versus list_hostings or get_renewal_prices, nor any exclusions or prerequisites. At best, 'every hosting package' implies a bulk enumeration, but that is inference rather than 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that expiry dates, nameservers and auto-renewal are returned, but says nothing about pagination, auth requirements, or completeness guarantees; with an output schema present, 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?

A single front-loaded sentence that states the action, scope and returned data with no wasted words. Nothing is redundant or buried.

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

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

For a zero-parameter listing tool with annotations and an output schema, the description covers the essential purpose and content. It could note whether expired hostings are included or whether results are paginated, but nothing critical 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?

The tool takes zero parameters, so there is no parameter semantics burden to compensate for; baseline 4 applies. The description correctly implies the full-account scope with no filtering options.

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 (List) and resource (every domain and hosting on the account) and enumerates key returned fields (expiry dates, nameservers, auto-renewal). The word 'every' implicitly separates it from singular siblings like get_hosting and get_domain, but no sibling is named explicitly, so it falls 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 scope ('on the account') implies when to use it, but there is no explicit guidance on when this is preferable to get_domain or get_hosting, nor any stated exclusions. Usage is inferable but not spelled out.

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 and openWorldHint=true, so the safety profile is covered. The description adds a useful filter definition ('deferred requests that have not been processed yet'), but says nothing about ordering, result size, or freshness of the pending set.

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

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

A single compact sentence with the scope qualifier front-loaded and no wasted words. It is appropriately sized, though the term 'deferred' is slightly less obvious than 'pending' and goes unexplained.

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 tool with annotations carrying the safety profile and an output schema describing return values, the description is nearly sufficient. The one remaining gap is disambiguation from list_requests, which the agent cannot resolve from the description.

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 description-side parameter guidance is not needed. Baseline for a no-parameter tool is 4; the schema fully documents the empty argument object.

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 clear verb (List) and resource (deferred/unprocessed requests), so an agent knows exactly what is returned. However, it does not distinguish this from the sibling list_requests, leaving ambiguity about which listing tool applies.

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 nearby list_requests sibling, nor any stated preconditions. The agent must infer the difference from wording 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral detail beyond that: a deferred request leaves its result ('retour') empty until processing completes. This is useful but cryptic, mixes languages, and says nothing about filtering, pagination, 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?

Two short sentences with no filler, and the primary purpose is front-loaded ahead of the deferred-request caveat. The second sentence is somewhat opaque, but nothing is padded.

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 spelled out. Still, for a search tool with three filters it omits how the filters interact and — most importantly — how it differs from list_pending_requests, leaving an agent under-equipped to choose or invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents value, subtype, and endpoint. The description adds no syntax, defaulting, or combination logic beyond that, which is the correct baseline when structured fields do the work.

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 verb and resource ('Search the requests made through the API'), so the broad purpose is discernible. However, it never distinguishes this from the near-identical sibling list_pending_requests, nor does it clarify what 'requests' means here versus pending ones. The purpose is vague enough that an agent cannot reliably separate the two 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 statement of when to use this tool, when not to, or which sibling to prefer for a narrower case. The only contextual clue is the note about 'retour' staying empty for deferred requests, which describes state rather than selection criteria.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: prices are quoted in EUR and cover four distinct price categories (purchase, renewal, transfer, restore). It says nothing about pagination, ordering, or rate limits on what is presumably a large catalogue.

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

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

One sentence, front-loaded with the verb and resource, then the return payload and currency. No filler whatsoever.

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 structure need not be explained, and annotations carry the safety profile. The description covers the resource, the price categories, and the currency. The only gap is routing against sibling price tools, which matters here given the crowded price/pricing neighbourhood.

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 'tld' parameter is documented in the schema with an example ('.fr' or 'fr'). The description adds nothing about the filter, 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?

States a specific verb ('List') and resource ('the extensions LWS sells') and enumerates the price categories returned (purchase, renewal, transfer, restore), which an agent can act on directly. It does not, however, explicitly distinguish itself from the sibling get_renewal_prices, leaving the overlap between 'all prices for every TLD' and 'renewal prices' to inference.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the closely related sibling get_renewal_prices. The agent must guess whether to call this or a narrower price 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 indicate destructiveHint=true, openWorldHint=true, and readOnlyHint=false. The description adds that the code is emailed to the domain owner and that the action is deferred, which is useful context, but it does not explain the destructive nature, auth requirements, or whether repeated calls behave differently. The description does not contradict 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?

The description is a single concise sentence with the effect front-loaded. However, the appended '(deferred)' is slightly vague and could be clearer, keeping it from a perfect score.

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

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

With one parameter, full schema coverage, output schema, and annotations covering safety, the description is minimally sufficient. It omits prerequisites, explicit usage context, and a clear explanation of what 'deferred' means for the caller.

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 required domain parameter is fully documented in the schema. The description adds no additional meaning about the domain parameter, so the baseline of 3 applies.

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

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

The description states a specific action: requesting the transfer authorization code to be emailed to the domain owner. It uses a passive construction ('Have ... e-mailed') and does not distinguish this from related domain-transfer siblings such as set_transfer_protection, but the core purpose 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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent is not told under what circumstances this tool should be chosen over another, nor what conditions must hold before calling it.

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-destructive, idempotent, open-world mutation. The description adds meaningful behavioral context beyond that: it also controls renewal of the associated domain when the domain was bought at LWS. It does not cover permissions or timing consequences, but the added side-effect disclosure is valuable.

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

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

A single sentence with zero filler, front-loading the action and resource. 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?

The tool is simple, has an output schema, and annotations cover the safety profile, so the description does not need to explain return values. It communicates the core effect and the domain side-effect, though it omits permission requirements and what happens to an existing renewal cycle when toggled off.

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 50%. The description clarifies that 'hosting' is the hosting whose renewal is toggled and ties it to its domain, adding some meaning. However, the 'enabled' parameter is only implicitly described by 'on or off' and receives no explicit true/false semantics beyond what the boolean schema already conveys.

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 ('Turn ... on or off') and resource ('automatic renewal of a hosting (and its domain, if bought at LWS)'), making the effect unambiguous. It does not explicitly differentiate from siblings, but no sibling tool overlaps with this purpose, so the omission is minor.

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 toggle wording: use it when you want to enable or disable auto-renewal. There is no explicit when-to-use guidance, no prerequisites, and no named alternative, though no alternative sibling exists.

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=true and openWorldHint=true, so the agent knows this mutates external state. The description adds only the token '(deferred)', which is unexplained and ambiguous rather than clarifying what gets changed, when, or with what authorization.

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, front-loaded sentence with no padding. However, the trailing '(deferred)' is cryptic and arguably does not earn its place since it is never explained.

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 schema covers both parameters. For a destructive mutation tool, though, the description lacks any permission, timing, or side-effect context, leaving it 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 100%, so both 'domain' (with format example) and 'enabled' (true=locks, false=allows) are already fully documented. The description adds no parameter meaning beyond the schema, 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?

States a specific verb (lock/unlock) and resource (domain transfer to another registrar), which an agent can distinguish from siblings like set_auto_renew or update_nameservers. It is clear what the tool does, though it never explicitly names a sibling or scope boundary.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives mentioned. The agent must infer that this applies to domain transfer protection only from the name and the phrase 'transfer of a domain to another registrar'.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured information: that this is a partial update ('Only the fields given are changed'), which tells the agent that omitted fields are preserved rather than nulled — a critical behavioral trait 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?

Two short sentences, zero filler, with the partial-update guarantee placed immediately after the action statement. Nothing could be removed without losing 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. However, for a 7-parameter mutation tool the description omits half the editable fields and says nothing about permission requirements or side effects such as a password change affecting the customer-area login.

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 low (14%), so the description is expected to compensate, and it names only three of seven parameters (address, phone, password). The remaining fields (city, postal, country) are undocumented in the description and only partially in the schema, though the contact/country/password/phone schema notes do carry format details.

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?

Specific verb+resource ('Update a contact's ...') with an enumeration of updatable fields, which distinguishes it from create_contact/get_contact in the sibling list. The field list is however partial — the schema also accepts city, postal and country, which the description never mentions, so the stated scope is narrower than the actual one.

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 list_contacts, get_contact or create_contact; the agent must infer that this is the mutation counterpart of get_contact. No prerequisites (e.g. needing a valid contact ID from list_contacts) are given in the description, although the schema notes the ID source.

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 annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses two genuinely non-obvious behaviors: an upsert fallback when the id does not exist, and that the updated record receives a NEW id that must be reused for later changes. It doesn't address permissions/auth scope or whether replacement is recoverable. Note a mild tension: the new-id-on-update behavior means a repeated call with the same id would insert again, which sits awkwardly with idempotentHint=true, though the description does not directly assert idempotency.

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 follow-up note; the purpose and the upsert caveat are front-loaded with no filler. The indented line break around the new-id note is slightly awkward 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description supplies the odd upsert and id-change semantics, but omits permission/authentication requirements and any propagation caveat for a mutation tool with an openWorldHint.

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 83%, so the schema already documents id, ttl, name, value and domain; baseline is 3. The description's only added semantic is "Every field is required," which is a whole-record-replacement hint but is imprecise since ttl has a default and only 5 of 6 fields are in the required list.

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 ("Replace an existing DNS record") and is immediately distinguishable from the sibling tools add_dns_record and delete_dns_record. The scope of the operation is clear 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?

It conveys implied usage context (call it when a record already exists and must be replaced, passing all fields) and warns that a missing id causes an add, but it never explicitly says when to prefer add_dns_record over this tool or vice versa. Usage must be inferred from the verb choice rather than stated.

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

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

Annotations already declare destructive=true, readOnly=false, and openWorld=true, so the safety profile is covered. The description adds genuine value by disclosing the real consequence ('makes its LWS DNS zone stop answering') and the deferral mechanism, which annotations cannot 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?

Front-loads the core action, then layers the side-effect warning and the required-count rule. The parenthetical 'deferred: see list_pending_requests' is slightly cryptic but tight overall with 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 not be described. The description covers the mutation's consequence, the parameter-count rule, and the deferral path, leaving little an agent needs to call it correctly.

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

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

Schema coverage is 100% (baseline 3), and the description adds a non-obvious semantic rule not in the schema: all four are required and a value must be repeated when fewer than four exist. That meaningfully shapes how the agent fills ns1-ns4.

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 ('Replace') and resource ('the four nameservers of a domain') with scope. It routes the agent to a sibling ('deferred: see list_pending_requests'), so it can be distinguished from related request tools without opening a schema.

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

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

Explains the deferred nature of the operation and points to list_pending_requests for tracking it, giving clear context on how the call behaves. It stops short of explicit when-to-use vs when-not guidance against a direct alternative.

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