AiVikings.ai

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false), and the description adds genuinely new context on top: the domain must be owned by the authenticated customer, and SRV records additionally require port and weight. It stops short of saying what happens on a conflicting existing record or whether a duplicate add errors out.

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

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

Three tight sentences with zero filler: purpose and scope first, then the type list, then the naming rules and the SRV caveat. Every sentence contributes a distinct, actionable fact.

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

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

An output schema exists, so return values need not be explained, and the safety profile is annotation-covered. However, for an 8-parameter mutation with 0% schema description coverage, leaving record_ttl and record_priority entirely unexplained is a real gap an agent could stumble on.

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

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

Schema coverage is 0%, so the description must carry the load. It usefully explains relative-name expansion and '@' for the apex (record_name), enumerates valid record_type values, and ties record_port/record_weight to SRV. It says nothing about record_ttl (default 43200) or record_priority, leaving two of eight parameters undocumented anywhere.

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 ('Add a managed DNS record') plus the ownership scope ('to a domain owned by the authenticated customer'). An agent can immediately tell this is a creation operation, though the description never explicitly contrasts it with sibling update_dns_record or configure_dns_record.

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 ownership constraint and the supported record-type list imply when this tool applies, and 'SRV records require port and weight' gives a conditional usage rule. But there is no explicit statement about when to use this versus update_dns_record or configure_dns_record, so the routing decision is left to inference from 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 declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description's job is to add what they cannot. It does: assigning a role "replaces any previous default for that role" discloses an overwrite side effect, and "false leaves that role unchanged" explains the non-merged, per-flag semantics. It doesn't mention permission requirements or failure modes for a nonexistent handle.

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

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

Four sentences, each doing distinct work: what it does, how the flags behave, the overwrite consequence, and the trigger condition. Front-loaded with the action and free of repetition.

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. What remains thin is whether at least one flag must be true and what happens if the handle doesn't exist or belongs to another customer, but for a five-parameter tool this is close to complete.

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

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

Schema description coverage is 0%, so the description carries the full burden and mostly meets it: it names all four boolean flags and explains that true assigns while false is a no-op, which is exactly the ambiguity an agent would face given the default=false values. contact_handle is characterized as needing to be an "existing" handle, though no format or lookup guidance is given.

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: assign one existing contact handle as the default for selected domain-registration roles. The mention of selected roles and the per-role booleans makes clear this is a partial, targeted assignment rather than a wholesale contact swap, which implicitly separates it from update_registrant_contact and remove_domain_registration_contact_roles. It stops short of naming either 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?

"Use this when registration validation reports a missing registrant, admin, technical, or billing contact" gives a concrete triggering condition an agent can act on. There is no explicit when-not guidance and no named alternative for the inverse or broader case, but the activation context is unambiguous.

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 readOnlyHint/openWorldHint annotations, it discloses the exact result vocabulary and the critical caveat that lists over 50 skip the registry, producing unconfirmed probably_available statuses. It also states the tool deliberately omits prices and premium status, which is behavior an agent cannot infer from annotations or schema.

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

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

Purpose is front-loaded in the first sentence, followed by the status vocabulary and the escalation rules. The long parenthetical status list is information-dense and earns its place, though the packed parentheses and caps make it harder to scan than ideal.

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

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

With an output schema present, return shapes needn't be spelled out, yet the description usefully adds the semantic interpretation and reliability differences among statuses — exactly the context a schema cannot convey. Nothing an agent needs to call this correctly and report results honestly is missing.

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

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

Schema coverage is 0%, so the description must carry the load: it explains the domains array with a hard limit of 200 and explains include_price's effect (adds premium and prices). The currency parameter is never mentioned, leaving one of three params undocumented anywhere.

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

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

The description states a specific verb and resource ('Check whether domain names can be registered') and scopes the input ('a list of one or more names, up to 200'). It is clearly distinguishable from siblings like list_domains (existing registrations) and get_domain_pricing (prices).

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

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

It gives explicit routing rules: use include_price for single names or lists up to 10, and 'always call get_domain_pricing for the chosen name' before purchase. It also describes the mandatory re-check workflow for probably_available results on lists over 50, covering when and when-not to trust a result.

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, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered by structured data. The description adds useful behavioral context about resolving a complete hostname against the authenticated customer's longest matching parent domain, but it does not explicitly state whether an existing A record is overwritten or what permissions are required.

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 compact paragraph that front-loads the core operation and then explains the record_name conventions. The hostname-compatibility sentence is longer but earns its place by resolving a real ambiguity in the domain parameter; there is little wasted text.

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

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

Given the presence of an output schema and rich annotations, the description need not explain return values or repeat safety hints. However, for a destructive DNS mutation with 0% schema coverage, it remains incomplete: it does not describe record_value, does not clarify overwrite behavior, and does not route the agent away from add_dns_record or update_dns_record.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does a good job explaining record_name semantics for root and subdomain records and clarifies that domain may accept a full hostname, but it says nothing about record_value, leaving one required parameter's meaning entirely to the bare schema.

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

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

The description states a specific verb and resource: configuring an A record for a domain through AIvikings. It is clear what the tool does, but it does not distinguish this operation from siblings like add_dns_record or update_dns_record, leaving ambiguity about whether it creates, replaces, or updates a record.

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 explains how to use record_name for root and subdomain records, but it gives no guidance on when to choose this tool over add_dns_record, update_dns_record, or other DNS-related siblings. It lacks any explicit when-to-use, when-not-to-use, or alternative-selection guidance.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so mutation and network-reaching behavior are known. The description adds a genuinely useful non-schema fact — that the returned handle is reusable across multiple domains and how it is auto-generated when omitted — but says nothing about failure modes, required account/prepaid balance, or validation errors. Useful but partial 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?

Three sentences, front-loaded with purpose then prerequisites then the handle rule. Efficient, though sentence order puts the input-validation pointers ahead of the more consequential role-boolean semantics that go unmentioned.

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

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

An output schema exists so return values need not be explained, and the handle semantics are covered. However, for a 16-parameter creation tool with 0% schema description coverage, the description leaves the default_* role flags and the distinction between address and address_line_2, organization, and phone fields 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 description coverage is 0% across 16 parameters, and the description only explains the handle default-generation scheme. That is real added meaning for one important optional field, but nine required fields and the four default_* role booleans (default_admin, default_billing, default_technical, default_registrant) get no clarification at all, leaving a large gap for a 16-parameter 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?

Specific verb (create) plus resource (reusable contact for domain registration) with the lifecycle role made explicit — the handle feeds register_domain. This distinguishes it cleanly from siblings like get_contact, list_contacts, and update_registrant_contact.

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

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

Explicitly routes the agent to list_contact_countries and list_contact_states before choosing country/state values, and names the downstream consumer (register_domain) plus reuse scope. That is when-to-use plus alternatives guidance, not mere implication.

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, idempotentHint=false, readOnlyHint=false. The description adds value beyond that by spelling out permanence/irreversibility and the provider-ID provenance requirement. It does not cover permissions, behavior on an unknown/invalid ID, or what happens to dependent records, so not a 5.

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

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

Two short sentences, front-loaded with the destructive nature and followed by the required precondition. No filler, 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?

An output schema exists, so return values need not be described. For a two-param destructive tool the description covers the essential danger signal and the ID-sourcing prerequisite. Gaps remain on the meaning of 'domain' and error behavior, but nothing critical to invoking it safely is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does: it explains that dns_zone_record_id must be the exact ID returned by the provider (a real usage constraint). But the required 'domain' parameter is never explained — whether it is the zone, the registrant domain, or must match the record's parent — leaving half the parameters ambiguous.

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

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

The description names a specific verb and resource ('Permanently delete a managed DNS record'), plus a critical scope qualifier 'permanently' that distinguishes it from update_dns_record/configure_dns_record. An agent can tell instantly that this is the destructive removal path in the sibling set.

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

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

It gives an explicit prerequisite workflow: 'Call list_dns_records first and pass the exact DNS zone record ID returned by the provider.' That is concrete when-to-use guidance tied to a named sibling. It lacks explicit when-not-to-use or exclusion rules (e.g., versus update_dns_record), which keeps it below 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=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds only the provider reference "through AIvikings" and does not disclose important transfer behavior such as required auth-code handling, potential charges, or expected transfer timeline.

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 single sentence is brief but under-specified rather than appropriately concise. For a domain transfer, a mutation tool with required credentials and multiple parameters, it omits essential structure and context.

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 non-idempotent, open-world domain transfer with zero schema parameter descriptions, the description is not complete enough to guide correct invocation or explain the transfer workflow.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It mentions only the domain implicitly and does not explain auth_code or period_years at all, leaving their semantics entirely undocumented.

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

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

The description states a specific verb and resource: "Transfer a domain". It is clear enough to understand the basic action, but it does not distinguish this tool from closely related siblings such as register_domain, renew_domain, or get_transfer_auth_code.

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 like register_domain or renew_domain, and no mention of prerequisites such as obtaining an auth code first. The agent must infer the workflow from the schema and sibling names.

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=false, so the safety profile is covered. The description adds only the qualifier 'reusable,' hinting contacts can be shared across domains, but says nothing about what is returned on an invalid handle or whether lookup is scoped to the account.

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 eight-word sentence with the resource and the lookup key front-loaded. Nothing is wasted and nothing is buried.

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

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

The tool is simple (one required param, read-only) and an output schema exists, so return values need no explanation. However, with 0% schema coverage the description should at least say where a contact handle comes from, which it omits.

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

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

Schema description coverage is 0%, so the sole parameter 'contact_handle' is undocumented in the schema. The phrase 'by its handle' tells the agent the parameter is a contact handle, but adds no format, source, or validity information beyond the field name.

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

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

States a specific verb and resource ('Get one reusable contact') plus the lookup key ('by its handle'), so the agent knows this is a single-record fetch rather than a list. It does not name or differentiate itself from siblings like list_contacts or get_customer, which keeps 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?

Usage is only implied: fetch one contact when you already have a handle. There is no explicit statement of when to prefer this over list_contacts, nor any note that the handle must come from a prior create_contact or list_contacts 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful nuance not in annotations: name and email are populated only "when the key belongs to a customer," warning the agent that a partial/null result is possible. It stops short of describing error or auth-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?

A single sentence with no waste, front-loading the resource and the scoping condition (current bearer key) before the conditional return detail.

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 to document the return shape, and annotations covering safety, the description supplies everything an agent needs to select and invoke the tool correctly. The conditional-response caveat is the one extra detail that mattered, and it is included.

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 are zero parameters, so the schema carries nothing to misinterpret and the baseline is 4. The description correctly frames the bearer key as ambient context rather than an argument, matching the empty input schema.

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

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

States a specific verb and resource: returns the authenticated customer for the current bearer API key, plus the fields included (name, email). This clearly distinguishes it from the sibling get_customer, which presumably takes an identifier, though the description never names that 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?

The phrase "for the current bearer API key" implies the when: use it to identify the caller rather than look up an arbitrary customer. However, no alternative sibling (e.g. get_customer) or exclusion condition is named, so the routing guidance 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=false, so safety is covered. The description goes beyond that by disclosing an identity-binding rule: the returned record is tied to the bearer token and any supplied ID must be consistent with it — a genuine behavioral constraint an agent would otherwise miss.

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 primary retrieval behavior front-loaded and the constraint second. Nothing is redundant with the schema or annotations.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. What remains thin is error behavior on an ID/token mismatch and confirmation that the parameter may be omitted — minor gaps for a single-parameter read 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 coverage is 0%, so the schema only gives an anyOf string/integer nullable type with no meaning. The description compensates by explaining that customer_id must match the token identity, but it omits that the parameter is optional (default null) and what a non-matching value produces.

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 (customer record) plus a scope qualifier: the record is linked to the current bearer token. That scope meaningfully separates it from siblings like get_contact and list_contacts, though it never names those alternatives explicitly.

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

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

The constraint 'A supplied customer ID must match that token' implies the use case (retrieving your own customer record) but the description never says when to prefer this over get_contact, list_contacts, or get_current_user. Usage must be inferred from the token-scoping sentence.

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=false; the description goes well beyond that with append-only semantics, newest-first ordering, permission scope, pagination mechanics, timezone requirement, and operational caveats (accepted ≠ provider completion, history begins at audit enablement, agent labels self-reported). This is exactly the extra context 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 purpose and the core scoping rule (omit domain), then flows through permission, ordering/pagination, timestamp format, and event-semantics caveats. Every sentence adds distinct information with no repetition.

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?

Output schema exists so return shape need not be described, and the description covers permissions, pagination, timezone rules, and result interpretation. The main residual gap is the unexplained 'action' filter and limit semantics for a zero-coverage schema.

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

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

Schema description coverage is 0%, so the description must compensate. It explains domain (omit for portfolio), cursor (reuse same filters), and from/to timestamps (require timezone), which is meaningful added meaning. It does not explain the action filter or limit behavior, leaving two of six parameters undocumented anywhere.

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 (read append-only domain change history) plus scope (authenticated customer, per-domain or portfolio-wide). No sibling tool in the list exposes audit/history data, so it is unambiguously distinguishable from the DNS/contact/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?

Gives concrete usage conditions: omit domain for portfolio history, requires audit:read, pass next_cursor with the same filters for another page, and timestamps must include a timezone. It lacks explicit when-not-to-use guidance or named alternatives, but no sibling overlaps, so the remaining gap is small.

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

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

Annotations only cover readOnly and openWorld; the description adds the failure contract (null price fields plus price_unavailable_reason when the currency is unavailable), the no-conversion rule, and a data-boundary guarantee that upstream cost prices are never exposed. That is real behavioral disclosure beyond structured fields, though rate limiting or freshness caching is not addressed.

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

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

Four tight sentences, front-loaded with what the tool does, then return values, then currency behavior, then the privacy boundary. No filler and no repetition of schema 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?

For a two-parameter read-only pricing lookup with an output schema, the description covers the essentials an agent needs: what is returned, currency defaults and limits, null-failure semantics, and the premium flag's purpose. 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 coverage is 0%, so the description carries the load: it identifies the domain as a single-domain lookup and explains currency semantics, including the valid explicit values USD and EUR, which the schema does not enumerate. It compensates well for the schema gap without documenting format for the domain argument itself.

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

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

The description opens with a specific verb and resource ("Get a fresh price quote for one domain") and enumerates exactly what is returned (registration, renewal, transfer prices, is_premium). This clearly separates it from siblings like check_domain_availability, register_domain, and renew_domain.

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 currency guidance (omit for default, USD/EUR explicit) gives usable calling context, but there is no explicit statement of when to call this versus siblings such as check_domain_availability or register_domain. The relationship to the purchase flow is left 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?

The description usefully discloses that the call reaches the external registrar and writes back to the saved record, which is context the annotations don't carry. However, that persistence side effect sits in tension with readOnlyHint=true, which tells an agent nothing in its environment is modified. No mention of failure behavior when the registrar is unreachable or of rate limits on the outbound lookup.

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, with the action and its registrar source front-loaded ahead of the usage note.

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

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

With a single required parameter and an output schema, the definition covers what it returns and when to call it. The remaining gap is operational: latency/cost of the live registrar round-trip and what the agent should do if the fetch fails.

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 0%, so the description is the only place semantics could be added, and it says nothing about the expected format of `domain` (registrable name vs. stored domain ID) or normalization rules. The parameter name is largely self-explanatory, so this is a gap rather than a blocker.

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 ('Fetch the latest domain status, expiry and nameservers from the registrar') plus the side outcome ('refresh the saved AIvikings record'). That is clearly distinct from list_domains or get_domain_audit_log, though it doesn't name a sibling to contrast with.

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

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

'Use this for an on-demand update, including pending transfers' gives a concrete triggering condition and calls out the transfer case. It stops short of saying when not to use it (e.g., routine reads from the cached list) or which sibling to prefer instead.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description is free to add business semantics, which it does: both wallets are returned, and a zero balance in one currency may still permit registration via automatic conversion. It does not mention auth requirements beyond 'authenticated customer' or any caching/freshness of the balance, keeping it short of a 5.

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

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

Three short sentences: purpose first, response contents second, then the one non-obvious caveat about conversion affecting register_domain. Nothing is redundant and the important nuance is not 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-value documentation is unnecessary, and the description covers the non-obvious cross-tool consequence with register_domain. The only real omission is the role of the `currency` argument, which is a minor but genuine gap for a one-parameter read 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 single `currency` parameter has 0% schema description coverage, so the description must carry the load. It mentions 'the requested currency' but never explains what the parameter actually controls, given that both USD and EUR balances are returned anyway, and it does not state the accepted values (USD/EUR) or the USD default.

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

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

States a specific verb and resource ('Return the authenticated customer's prepaid balance') plus the scope ('for domain purchases') and the contents of the response (USD and EUR wallets). No sibling tool overlaps with balance retrieval, so it is unambiguous which tool to pick.

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 reference to register_domain implies this is a pre-registration funds check, and the conversion note explains how to read a zero balance. However, it never explicitly says 'call this before register_domain' or when not to call it, leaving the usage pattern to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds meaningful context beyond that: the secret is not cached or stored but fetched on demand, and access is restricted to domains owned by the authenticated customer. It does not disclose what happens when ownership checks fail or whether the code expires, keeping it short of a 5.

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

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

Two short sentences with no waste, front-loading what is returned and then the on-demand access property. Every sentence earns its place.

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

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

An output schema exists so return values need not be documented, and the ownership precondition plus on-demand semantics cover the essentials for a single-parameter read tool. Only error/edge-case behavior is missing.

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

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

Schema coverage is 0% for the single 'domain' parameter, so the description must compensate. It adds the important constraint that the domain must be owned by the authenticated customer, but gives no format guidance (bare name vs FQDN) or behavior for unknown domains.

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 (return) and resource (EPP transfer auth code) scoped to a domain owned by the authenticated customer. It implies but does not explicitly name its nearest sibling, regenerate_transfer_auth_code, so an agent must infer the distinction between reading and regenerating.

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 secret is fetched only on demand" hints that this is a non-mutating retrieval and that a code already exists, which implicitly separates it from regenerate_transfer_auth_code. However, no explicit alternative is named and no conditions or error cases (e.g. domain not owned, domain locked) are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and the closed/fixed nature of the data are covered. The description adds the useful detail that returned names are the exact ones accepted by the contact endpoints, but says nothing about ordering, caching, or size of the list.

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, zero filler, with the resource and its intended use front-loaded. 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 no explanation, and the zero-parameter schema needs none either. The description covers purpose and usage; only minor details such as list size or stability are missing, which is acceptable here.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Mentioning that the IDs pair with country names implicitly tells the agent what the output values are for.

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

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

Specific verb (List) plus specific resource (ConnectReseller country names and IDs), with the qualifier 'exact' signaling that these are the provider's canonical values, not arbitrary ISO codes. It is clearly distinguishable from the sibling list_contact_states, though that distinction comes from the tool name rather than the description.

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

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

'for creating or updating contacts' gives a clear use context that links the tool to create_contact and the contact-update siblings. It does not state exclusions or name an alternative lookup source, but for a zero-parameter reference lookup the when-to-use signal is adequate.

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=false, so the safety profile is covered. The description adds the authenticated-customer scoping detail, but it does not mention pagination, ordering, or return behavior beyond what the output schema provides.

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

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

The description is a single, front-loaded sentence with no redundant or filler content. Every part of the sentence contributes to identifying the resource and scope.

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, zero-parameter list tool with an output schema and read-only annotations, the description is nearly complete. It could be improved by briefly clarifying its relationship to similar contact-listing siblings or noting pagination behavior, but nothing essential for invocation 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 has zero parameters, so there are no parameter semantics for the description to clarify. The baseline for a 0-parameter tool is 4, and the description appropriately does not invent parameter 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?

The description gives a specific verb ('List') and resource ('reusable contacts') with the scope 'belonging to the authenticated customer.' It is clear what the tool returns, though it does not explicitly distinguish itself from sibling contact-listing tools such as list_domain_registration_contacts or get_contact.

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 implies usage for retrieving all reusable contacts for the current customer, but there is no explicit guidance on when to choose this tool over get_contact, list_domain_registration_contacts, or create_contact. The context is adequate but lacks alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that names are "exact" and must be reused verbatim, which is useful behavioral context, but says nothing about failure modes (unresolvable country, ambiguous input) or whether it caches/prepares data.

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

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

Two sentences, zero waste, with the resource and scope front-loaded and the downstream usage note second. Every sentence earns its place.

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

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

An output schema exists, so return values need no explanation, and the input forms plus intended downstream use are documented. What's missing is any tie-in to the list_contact_countries sibling and expected behavior when the country can't be resolved.

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

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

Schema coverage is 0% for the single required 'country' parameter, so the description carries the burden — and it does supply the accepted forms (country name, country ID, or ISO code), which is meaningfully more than the bare string schema. It stops short of saying which form is preferred or how ambiguity is resolved.

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: listing exact ConnectReseller state names for a given country. It implicitly distinguishes itself from the sibling list_contact_countries by dealing in states rather than countries, but never names or contrasts that sibling explicitly.

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

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

"Use the returned name in contact requests" gives clear downstream context for when this lookup is needed (populating create/update contact calls). There are no exclusions or guidance about when to skip it or how it relates to the countries sibling.

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 access-scoping rule (only domains owned by the authenticated customer) and the fact that the response carries zone record IDs, but says nothing about pagination, empty results, or result size for large zones.

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 scope, with no filler. The second sentence carries actionable follow-up information rather than padding.

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 described; the description covers ownership scope and the key returned identifier. The remaining gap is the ambiguous 'domain' argument format, which an agent needs to call correctly.

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

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

Schema description coverage is 0% and the single required parameter 'domain' is unexplained — the description does not clarify whether it expects a registrable name, a subdomain/FQDN, or an internal zone identifier, which directly affects whether the call succeeds. It only restates that the domain must be customer-owned.

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 ("List the managed DNS records") and scopes it to domains owned by the authenticated customer, which separates it from broader tools like list_domains. It does not name the update/delete siblings explicitly, but the read-only listing 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?

Gives a clear workflow cue: use this to obtain the record ID needed before updating or deleting a record, which implies the correct call ordering against update_dns_record/delete_dns_record. No explicit 'when not to use' or alternatives are listed, 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 establish this is a read-only, closed-world call, and the description adds substantive context beyond that: what each entry contains (completeness flag, missing required fields, default roles, registration handle) and the prerequisite ordering. It does not mention whether results are paginated or how many contacts are typically returned, but the key behavioral traits are covered.

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

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

Three sentences, each earning its place: identity of the resource, contents of each returned entry, and the mandatory call ordering. The prerequisite warning is front-loaded at the end where it is most likely to be read as a rule.

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 only needs to explain the workflow role and the shape of the result, and it does both. The return fields (completeness, missing fields, roles, handle) are summarized so the agent knows what to do with the output before ever parsing the schema.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly implies there is no filtering input by saying it lists the authenticated customer's handles wholesale.

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 ('List the authenticated customer's registrant/contact handles for domain registrations') and scopes it to the authenticated customer, which distinguishes it from the broader list_contacts sibling. It stops short of explicitly naming how it differs from list_contacts, so it is clear but not fully sibling-differentiated.

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?

'Always call this before attempting a domain registration' gives a hard prerequisite tying it to register_domain, which is genuinely actionable. It does not say when to call it outside the registration flow or why list_contacts would not be the right choice, so it is clear context without explicit alternatives/exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description contributes the added fact that results come from a local datastore rather than a live registry. However, it says nothing about staleness, sync state, or result ordering/limits — relevant for a listing tool whose data can drift from the provider.

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 key qualifier ('local registrar datastore') appears immediately. It is efficient, though arguably too terse to carry any routing or state-freshness information.

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

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

With no parameters, an output schema present, and annotations covering the safety profile, the structural burden is low and the description is minimally sufficient. The remaining gap is conceptual: nothing tells the agent that the local datastore may lag the provider or that reconcile_domains exists to sync it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is reported at 100% with an empty properties object, leaving no gap.

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

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

Specific verb (list) plus resource (domains), and the phrase 'local registrar datastore' does meaningful work by implying this reads local state rather than querying availability or provider status. It stops short of naming a sibling (e.g. check_domain_availability, reconcile_domains) that an agent should consider instead, so it is clear but not fully differentiated.

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 mention of when to prefer check_domain_availability or reconcile_domains, and no statement about whether the local datastore may be stale. The only implicit signal is the word 'local', which an agent must interpret 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?

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description adds useful auth scoping ('owned by the authenticated customer') but does not explain the actual side effect (blocking outbound transfers), what happens if the lock is already set, or whether the lock is reversible and only via unlock_domain.

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 action and the ownership constraint front-loaded. Nothing is redundant or 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 needn't be described, and the tool is a simple single-parameter mutation. What remains missing is meaningful for a destructive, non-idempotent write: the concrete consequence of locking (transfer prevention), behavior when already locked, and the reversal path.

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 one required parameter with 0% schema description coverage, so the description must compensate. It identifies the argument as a domain belonging to the authenticated customer, which adds an ownership precondition, but gives no format or identifier convention (e.g., 'example.com' vs. internal ID).

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

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

States a specific verb and resource: 'Enable the registrar transfer lock for a domain', which is precise and clearly the inverse of the sibling unlock_domain. It stops short of naming that sibling, so the agent must infer the pairing from the sibling list rather than from the text.

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

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

Usage is implied by the purpose (lock a domain to prevent registrar transfer) and scoped to domains owned by the authenticated customer, but there is no explicit when-to-use, when-not, or pointer to unlock_domain as the reversal path. An agent can infer the context but is given no routing guidance.

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

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

Annotations already indicate readOnly and openWorld behavior. The description adds important context beyond annotations: admin-only restriction, bearer token requirement, and the note that provider operations/credentials remain in the existing middleware service. No rate limits or output format details, but output schema exists, so this is sufficient.

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

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

Four efficient sentences, front-loaded with purpose and usage. Every sentence contributes: scope, prerequisite, authentication, and boundary. No wasted words.

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 read-only nature, single optional parameter, and presence of an output schema, the description is nearly complete. It covers purpose, usage, authentication, and a relevant boundary. The only significant gap is the unexplained 'account_id' parameter, but overall it supplies enough context to call the tool correctly.

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

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

Schema coverage is 0% for the single optional parameter 'account_id'. The description does not mention 'account_id' at all, leaving the agent with no guidance on whether it filters results, what omitting it does, or what values are valid. Since coverage is low, the description should have compensated but does not.

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 ('read') and precise resources: 'enabled provider accounts, capabilities and transaction input schemas'. This clearly distinguishes it from sibling tools like middleware_submit_transaction and middleware_get_transaction, which handle other aspects of the middleware workflow.

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 'Use this before middleware_submit_transaction', giving a clear workflow prerequisite. Also states 'Middleware admin only' and requires a static admin bearer token, providing actionable conditions for use.

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 the valuable access-control constraint (admin only) but says nothing about error behavior for unknown contact_id or whether results differ from the registrar-side contact store.

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

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

One sentence, no filler, with the access restriction front-loaded before the operation. It is arguably too terse for the ambiguity it leaves, but nothing in it is wasted.

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

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

An output schema exists, so return values need no explanation, and the admin gate is stated. Still, for a tool sitting alongside a similarly named get_contact, the description leaves the agent guessing about store differences and failure modes.

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

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

Schema coverage is 0% for the single parameter, so the description carries the burden. It does tell the agent that contact_id refers to a middleware-local contact id (a meaningful disambiguation from other id spaces in the sibling set), but gives no format or example.

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

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

States a specific verb (read) and resource (a local middleware contact) plus the lookup key (contact_id). The qualifier 'local middleware' does distinguish it from the sibling get_contact, though the distinction is only implicit rather than spelled out.

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 'Middleware admin only' clause establishes a prerequisite and audience, which is real usage guidance. However, it never says when to pick this over get_contact or list_contacts, nor what to do if the contact is not found in the middleware store.

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

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

Adds real context beyond the annotations: the admin-only authorization requirement and the fact that this returns a cached projection rather than live provider data. However, the "submit action=refresh" instruction contradicts the actual one-parameter schema, muddying rather than clarifying 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 sentences with the admin restriction front-loaded and no filler. The second sentence, however, spends space on a refresh action this tool cannot perform, which is wasted budget.

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. What is missing is the delegation path for the refresh workflow (which tool actually performs it) and any semantics for the single undocumented parameter, both of which the description raises but does not resolve.

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

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

Schema description coverage is 0%, so the description must carry the meaning of domain_id, but it only restates the name. It does not say what format the ID takes, whether it matches the ID used by get_domain_status/get_domain_audit_log, or where to obtain it.

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 ("read the middleware's domain projection by domain_id") and adds a clear access qualifier ("Middleware admin only"). "Projection" is jargon, and the description never explicitly contrasts this with the sibling get_domain_status, so an agent must infer which one to call.

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 only conditional guidance is "For a live provider refresh submit action=refresh first," but this tool's schema has no action parameter, so the instruction cannot be executed here and likely belongs to a sibling such as middleware_submit_transaction. It never names alternatives like get_domain_status for live data, leaving the core choose-which-tool decision unresolved.

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

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

Annotations only supply readOnlyHint and openWorldHint; the description adds real context beyond them — an admin-only access restriction, the meaning of each terminal/non-terminal status, and the operational rule that non-succeeded states must not cause a retry/duplicate order. It stops short of stating behavior for unknown transaction_ids or error responses.

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

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

Two sentences with no filler: the first front-loads the access restriction and the verb+resource, the second packs the status semantics, the duplicate-order prohibition, and the authcode follow-up. 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?

An output schema exists, so return-value explanation is unnecessary; the description covers access control, status interpretation, and the authcode follow-up. Minor gaps: where the transaction_id originates and what happens on a not-found or unauthorized lookup.

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 zero schema description coverage, so the description carries the burden. It ties the call to 'transaction_id' but adds no format, provenance (e.g. from middleware_submit_transaction), or validation detail beyond the field name itself.

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: 'read a middleware transaction's status and result by transaction_id', which is clearly a single-record lookup. It implicitly contrasts with the sibling middleware_list_transactions via 'by transaction_id', though it never names that sibling explicitly.

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

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

Gives a hard audience gate ('Middleware admin only') and concrete downstream guidance: 'succeeded confirms completion; pending_provider, outcome_unknown and manual_review must not trigger a duplicate order.' It also routes to the alternative middleware_get_transaction_secret for authcodes. No explicit when-not guidance versus middleware_list_transactions, hence not 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 only cover readOnlyHint and openWorldHint; the description adds the admin-only restriction, the required upstream secret-read scope, and that the read is audited – meaningful operational context for a sensitive operation. It does not describe error behavior when the scope is missing, so it falls just short of a 5.

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

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

Two tight sentences with the audience restriction front-loaded, followed by the permission and audit facts. No filler or repetition.

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 description covers authorization and auditing. The only real gap is the absent detail on the transaction_id argument, which an agent would need to supply 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?

There is one required parameter with 0% schema description coverage, so the description carries the burden yet says nothing about transaction_id's expected format, source, or whether it comes from middleware_list_transactions. The parameter name is largely self-explanatory, so the gap is moderate rather than severe.

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

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

The description states a specific verb and resource: read a protected transaction secret via the middleware API. That distinguishes it from middleware_get_transaction, which returns the transaction rather than its secret. It stops short of naming the sibling explicitly, which keeps 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?

The 'Middleware admin only' qualifier gives a clear audience and the mention of a required secret-read scope implies prerequisites, but there is no guidance on when to call this versus middleware_get_transaction or middleware_list_transactions. Usage is implied 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 readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the non-obvious access constraint (admin only) and the concrete pagination loop seeding 'cursor' from the previous 'nextCursor'. It stops short of describing ordering, result volume, or what an empty list means, keeping it off a 5.

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

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

Two short sentences with the access restriction and scope front-loaded, then pagination. No filler, and no sentence that fails to earn 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?

A return schema exists, so return values need not be explained, and the admin/pagination essentials are present. The gaps are the undocumented 'limit' behavior and the unexplained relationship of 'account_id' to the 'selected' account, which matter for correct invocation on a 4-parameter tool.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full burden. It explains the 'domain' filter and the 'cursor' pagination mechanic usefully, but says nothing about 'limit' (default 100, no stated maximum) and leaves 'account_id' ambiguous even though the phrase 'selected middleware account' gestures at it.

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 persisted middleware transactions') and scopes it to the selected middleware account with an optional domain filter. This distinguishes it reasonably well from middleware_get_transaction, though it never names that sibling explicitly.

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

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

The 'Middleware admin only' qualifier and the domain-filter note imply when to reach for it, and the pagination hint tells the agent how to continue a listing. However, there is no explicit guidance on when to pick this versus middleware_get_transaction or middleware_get_capabilities, so the agent must infer the boundary.

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 destructive/openWorld/idempotent, but the description adds what they can't: admin-only authorization, asynchronous acceptance semantics ('202/queued means accepted, not completed'), the retry rule for idempotency keys, and the explicit scope exclusion that these orders bypass the ConnectReseller customer wallet and local domain portfolio.

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 authorization constraint and capability dependency are front-loaded, and each following sentence adds a distinct operational fact (account vs domain routing, key reuse, async polling, intent requirement, scope). No sentence restates another or repeats structured data.

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, open-world, asynchronous transaction tool with a 0%-covered schema, the description supplies everything else needed: prerequisites, parameter sourcing, retry policy, and how to confirm completion. An output schema exists, yet the description still adds the 202-vs-completed distinction that matters for agent control flow.

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

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

Schema coverage is 0% and the nested input object is untyped, so the description carries the full burden and does so: it names the source of action/input values, explains when domain_id vs account_id apply, and defines idempotency_key's stability requirement on retries. This compensates well for the schema's silence.

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 ('submit a middleware transaction') and immediately scopes it to middleware admin operators, which separates it from the many read-side middleware_* siblings. It also names the sibling it depends on (middleware_get_capabilities) and the sibling it hands off to (middleware_get_transaction).

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?

Explicit routing rules: action/input come from middleware_get_capabilities, domain actions need domain_id, account actions use the selected enabled account, and account_id is only needed when several accounts are enabled. It also tells the agent to poll middleware_get_transaction after a 202/queued and to require explicit user intent for paid or destructive actions.

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, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds useful context by stating that the old code is invalidated and that the domain must be owned by the authenticated customer, which goes beyond the annotations and helps the agent understand the side effect and authorization scope.

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

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

The description is a single, well-structured sentence that front-loads the action, return value, ownership constraint, and side effect. Every clause carries useful information 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?

An output schema exists, so return values need not be explained in detail, and the annotations already cover the destructive and non-idempotent nature. The description is nearly complete for a one-parameter mutation tool, though it could explicitly mention the sibling read tool or clarify parameter format for full 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 0% for the single 'domain' parameter, so the description must compensate. It adds the meaningful constraint that the domain must be owned by the authenticated customer, but it does not clarify the expected domain format (e.g., full domain name versus ID) or any other parameter semantics, leaving a gap.

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

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

The description states a specific verb and resource: regenerate an EPP transfer auth code and return a new one. It clearly conveys the action and effect, but it does not explicitly distinguish itself from the sibling tool get_transfer_auth_code, leaving the agent to infer the difference between fetching versus regenerating.

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 word 'regenerate' and the note that the old code is invalidated, which suggests this is for replacing an existing code rather than retrieving one. However, there is no explicit guidance naming get_transfer_auth_code as the alternative or stating when regeneration is appropriate versus simply reading the existing code.

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 a non-read-only, open-world, non-idempotent mutation; the description adds real value on top by disclosing default-nameserver fallback, the wallet currency-conversion rule (only the missing amount is converted), and a gate requiring explicit user acceptance before a premium charge. It stops short of stating retry/duplicate-charge behavior or failure modes, which matters for a non-idempotent financial mutation.

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

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

Front-loads the core action, then layers prerequisite, currency, wallet, and premium guidance in a sensible order with no filler sentences. It is dense and slightly long, but each sentence carries actionable workflow information rather than restating the 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?

An output schema exists, so return values need no explanation, and the description covers the money-related decision path thoroughly. The remaining gap is operational safety: nothing says whether a retry double-charges or what valid period_years values are, which is a meaningful omission for an irreversible purchase with six parameters.

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

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

Schema coverage is 0%, so the description must carry the load, and it does for four of six parameters: nameservers (omitted → account default), contact_handle (one reusable contact for all four roles), currency (must match the USD/EUR quote), and allow_premium (gated on user acceptance of the premium quote). It adds nothing about domain format or period_years bounds, leaving one required parameter entirely unexplained.

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

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

Opens with a concrete verb+resource: 'Register a domain through AIvikings', and the remaining sentences make clear this is a new registration workflow, distinguishing it implicitly from domain_transfer and renew_domain. It never explicitly says 'not for transfers/renewals', so it falls just short of the sibling-differentiation bar for 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?

Gives an explicit ordered workflow: call list_domain_registration_contacts first, create_contact if no registration-ready contact exists, and only set allow_premium=true after the user explicitly accepts the get_domain_pricing quote. It names the alternative tools and the condition that selects each, so the agent has no ambiguity about sequencing.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known; the description adds genuine value beyond them by clarifying that the contact itself is not deleted, that false is a no-op per role, and that removal can cause downstream registration validation failures. What it doesn't say is what happens if all four flags are false, or whether re-removing an already-removed role errors.

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

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

Three tight sentences: the action first, then the flag mechanics, then the failure mode and remediation. Given 0% schema coverage, the middle sentence about the booleans is doing necessary work rather than padding.

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 mutation with an output schema and full annotations, this covers action, scope, side effects, and a remediation path, which is nearly everything an agent needs. The remaining gaps are the all-false edge case and repeat-call behavior, neither of which is fatal.

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

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

With schema coverage at 0% the description must carry the load, and it does: each of the four booleans is tied to a named registrant/admin/technical/billing role and given explicit true/false semantics, and contact_handle is described as an existing handle the roles are removed from. Nothing about the five parameters is left ambiguous.

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), a specific resource (default domain-registration roles), and a bound scope (one existing contact handle), so it is clearly distinguishable from the sibling assign_domain_registration_contact_roles. It stops short of naming that sibling explicitly as the counterpart operation, so it falls just under 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?

Explains exactly how to invoke the flags (set one or more of remove_registrant/admin/technical/billing to true; false leaves the role unchanged) and warns that removing a role without reassignment can break registration validation unless register_domain is called with an explicit registration-ready contact_handle. That is a real when/how-not signal, though it never points to assign_domain_registration_contact_roles as the way to move a role to a different contact.

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=false, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. But renewal is a billable, non-idempotent mutation, and the description says nothing about charges, prepaid balance requirements, whether the extension is applied immediately, or what happens on repeat calls — a real gap that annotations alone don't close.

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?

Single short sentence with no filler, so it is concise and front-loaded on the verb. The brevity is under-specification rather than efficiency, since the space saved is never used for constraints or routing.

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

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

An output schema exists, so return values need not be explained. Still, for a two-parameter, billable, non-idempotent mutation the description leaves the agent without cost, prerequisite, parameter-format, or repeat-call behavior — insufficient for the operation's complexity.

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

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

Schema description coverage is 0% for both required parameters, so the description must compensate and it does not: it never defines the expected 'domain' format (FQDN?) or what 'period_years' means (years of extension, allowed range, default). With such low coverage this is a significant omission.

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

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

Names a specific verb+resource pair ('Renew a domain'), which cleanly separates it from siblings like register_domain, domain_transfer, and lock_domain. However, 'through AIvikings' adds a provider label rather than scope detail, and there is no explicit contrast with the nearest alternative (register_domain).

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 renew versus registering a new domain or transferring one, and no stated prerequisites such as the domain already being registered with the provider. Nothing tells the agent which sibling to pick for a near-expiry vs. expired vs. unregistered case.

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 safety is covered; the description adds real value by identifying which lock is removed and asserting an ownership precondition. It doesn't say what happens if the lock is already disabled (relevant given idempotentHint=false) or what failures look like.

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 front-loaded sentence with no filler; the action, scope, and timing condition are all present and ordered usefully.

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 described, and annotations carry the safety profile. Still, a destructive non-idempotent mutation leaves open the already-unlocked case and the format of its sole input, which an agent needs before invoking it.

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

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

The single parameter has 0% schema description coverage, and the description only says 'a domain' — no hint whether the value is a name, ID, or fully-qualified form. The schema does the bare minimum and the prose does not compensate.

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 (disable) and the exact resource (registrar transfer lock) plus ownership scope, and the 'before a transfer-out' framing distinguishes it from the inverse sibling lock_domain and from domain_transfer.

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 phrase 'before a transfer-out' gives clear context for when this tool applies, and the ownership qualifier implies it won't work on domains outside the account. It stops short of naming lock_domain/domain_transfer as explicit alternatives or excluding retry scenarios.

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, idempotentHint=false and openWorldHint=true, so the risk profile is known without the prose. The description adds genuine context beyond that by framing the call as a full replacement ('all record fields must describe the desired replacement'), warning the agent that omitted settings are not preserved. It does not spell out that unset optional fields (ttl, priority, port, weight) fall back to schema defaults, nor mention DNS propagation delay.

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

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

Three short sentences, no filler, with the replacement semantics and the list_dns_records prerequisite both front-loaded. Every sentence carries distinct information: what it does, what to do before calling, and how to build the payload.

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?

Output schema exists and annotations are rich, so return values and safety are covered elsewhere. However, a nine-parameter destructive mutation with 0% schema coverage and no enum constraint on record_type leaves real gaps: accepted record types, TTL units/bounds, and when record_port/record_weight/record_priority are applicable (only MX and SRV) are all 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 description coverage is 0%, so the description must carry parameter meaning, and it covers essentially one field: dns_zone_record_id, including where to source it from list_dns_records. The other eight parameters — domain, record_name, record_type, record_value, record_ttl, record_priority, record_weight, record_port — get only the collective phrase 'all record fields'. Notably, record_type is a free string with no enum, so supported record types (A, AAAA, CNAME, MX, SRV, TXT) need to come from somewhere and the description does not supply them.

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 managed DNS record'), which separates it from add_dns_record and delete_dns_record among its siblings. The line 'All record fields must describe the desired replacement' implicitly distinguishes it from a partial-update tool like configure_dns_record, but that sibling is never named, so the differentiation is left 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?

Gives an explicit precondition and workflow: 'Call list_dns_records first and pass its DNS zone record ID.' That is concrete, actionable guidance an agent can follow directly. It stops short of naming when to prefer this over configure_dns_record or add_dns_record, so the alternative-selection guidance is incomplete.

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, idempotentHint=false and openWorldHint=true, so safety is covered structurally. The description adds nothing on top: it does not say that the entire nameserver set is overwritten, that propagation is asynchronous, or that a registry/provider call is involved. 'Replace' merely echoes the destructive hint.

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?

Single front-loaded sentence with no bloat, which is structurally good. But the brevity comes at the cost of substance, and 'through AIvikings' spends words on branding rather than 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 destructive, non-idempotent, open-world mutation with two undocumented parameters, the description leaves too much unsaid; the existing output schema removes the need to explain return values, but prerequisites and replacement semantics are still missing.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only implies a domain and a nameserver set. It says nothing about nameserver string format, minimum count, ordering, or whether the array fully substitutes the existing set — exactly the ambiguities an agent would hit.

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 ('nameservers'), which is clearly distinct from the record-level siblings like add_dns_record and update_dns_record. No explicit sibling callout, and 'through AIvikings' is vendor branding rather than purpose information.

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, no prerequisites (registered domain, lock status, registry requirements), and no mention of how this differs from DNS-record-level tools beyond the word 'Replace'. The agent must infer everything about context of use.

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

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

Adds substantial consequences beyond the annotations: name/organization/email edits trigger registrant verification and can impose a 60-day inter-registrar transfer lock, and accepted changes report as verification pending. This tells the agent why the destructive flag matters and what the caller commits to, which annotations alone (destructiveHint, non-idempotent) 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?

Four sentences, each carrying a distinct fact: purpose, contact_handle behavior, verification/lock consequence, and the resulting status. The core scope is front-loaded and nothing is repeated from the 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?

An output schema exists, so return values need not be described, and the high-stakes verification/lock behavior is well covered. The remaining gap is update semantics for the many optional fields—whether a partial payload replaces or clears existing contact data—which an agent needs before mutating a registrant record.

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

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

Schema description coverage is 0% across 13 parameters, and the description only explains three of them: contact_handle's apply-without-copy semantics, acknowledge_transfer_lock's gating role, and which fields trigger verification. It leaves ten address/phone fields undocumented, including whether omitted fields are preserved or cleared, so it only partially compensates for the coverage gap.

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

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

States a specific verb and resource ('Update the registrant contact') with explicit scope ('a domain owned by the authenticated customer'). It also distinguishes the mode of operation from contact creation, noting that passing contact_handle applies an existing reusable contact rather than copying fields into a new record, which separates it from create_contact.

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 concrete conditions: pass contact_handle by itself to reuse an existing contact, and set acknowledge_transfer_lock=true when changing name, organization, or email. It does not explicitly name sibling tools like create_contact or list_contacts as alternatives, so the routing guidance is implied rather than stated.

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