OSIR Domain Registrar

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond that, such as the output concept of suggestions, but does not disclose ordering, pagination, or vocabulary behavior.

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

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

The description is a single clear, front-loaded sentence with no fluff beyond the redundant 'addPrefixToDomain:' heading that repeats the tool name. It is appropriately short and readable.

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

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

For a simple read-only suggestion tool, the description conveys the core output (domain suggestions) and all parameters are fully documented. The absence of an output schema is mitigated by the intuitive result type, though no details about response structure are given.

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

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

Schema description coverage is 100%, with all five parameters already documented in the input schema. The description contributes no additional parameter semantics, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('Generate') with a specific resource ('domain suggestions') and a precise method ('adding prefixes to a base name'). This clearly differentiates it from the sibling addSuffixToDomain and other suggestion tools by identifying its distinct mechanism.

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

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

The description gives no guidance on when to use this tool versus close alternatives like addSuffixToDomain, generateDomainSuggestions, or bulkDomainSuggestions. There are no explicit conditions, exclusions, or pointers to a more appropriate 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?

Goes beyond the idempotentHint annotation by explaining that duplicate storage returns the existing key, and by noting that authentication is required and the return value is a key id. This adds meaningful context for how the tool behaves in practice.

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

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

Three sentences, front-loaded with the action and purpose, followed by idempotency and downstream integration details. Every sentence contributes value without filler.

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

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

For a three-parameter tool with complete schema descriptions and idempotency annotations, the description covers the workflow, authentication requirement, and return value. Nothing essential for selecting or invoking the tool is missing.

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

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

Schema description coverage is 100%, with clear descriptions for name, publicKey, and sessionKey, so the baseline of 3 applies. The description adds context about the returned key id but does not need to restate 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?

States a specific verb and resource: 'Store an SSH public key on your account' for injection into VPS installs. This clearly separates it from siblings like listMySshKeys and deleteSshKey.

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 clear when-to-use guidance: it is safe to call before every order and it returns a key id to feed into orderVps or buildVpsInstance. It does not explicitly mention alternatives or when not to use it, but the intended workflow is well specified.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not responsible for safety disclosure. It adds the core behavior of suffix appending, but does not disclose whether suggestions are checked for availability, how suffixes are selected, or what the result contains. This is adequate but not rich.

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

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

The description is one short sentence and front-loads the essential mechanism. However, the leading 'addSuffixToDomain:' label redundantly re-states the tool name and adds no 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?

The schema and annotations cover parameters and safety, but there is no indication of return format and no guidance for choosing among the many suggestion-related siblings such as addPrefixToDomain, bulkDomainSuggestions, spinDomainWords, or suggestAlternatives. For a tool with no output schema and a crowded sibling group, this leaves meaningful gaps.

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

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

Schema description coverage is 100%; every parameter is individually described, so the description need not repeat parameter details. The description only restates the general 'base name + suffix' relationship, adding no new parameter semantics beyond what the schema already provides.

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

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

The description states a clear verb ('Generate'), resource ('domain suggestions'), and mechanism ('adding suffixes to a base name'). It distinguishes from the prefix-based sibling implicitly, but does not name any alternative such as addPrefixToDomain or generateDomainSuggestions, so it stops short of a 5.

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

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

The phrase 'adding suffixes to a base name' implies this tool is for suffix-based suggestion generation, but there is no explicit when-to-use/when-not-to-use guidance and no reference to the many sibling suggestion tools such as addPrefixToDomain, bulkDomainSuggestions, or generateDomainSuggestions.

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 goes well beyond the destructiveHint annotation by stating that it ERASES ALL DATA, is irreversible, is asynchronous, requires authentication, and returns an actionId requiring confirmation. This gives the agent a clear picture of consequences and lifecycle.

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 compact and front-loaded, starting with the destructive warning before explaining the async flow and confirmation step. Every sentence adds necessary operational or safety 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, asynchronous tool with no output schema, the description fully covers the lifecycle: prerequisites, destructive effect, completion polling, and confirmation action. An agent can safely and correctly invoke the tool based on this text.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters well. The tool description doesn't add per-parameter detail, but it doesn't need to; the baseline of 3 applies.

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

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

The description opens with a specific verb+resource: 'Stage an operating system install (or reinstall) on a VPS instance.' It clearly identifies the action and distinguishes it from siblings like orderVps (creating a new instance) and deleteVpsInstance (removing one).

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

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

It provides explicit operational guidance: the install is asynchronous, poll getVpsInstanceDetails until buildState is COMPLETE, and then use executeConfirmedAction with the returned actionId after user approval. It doesn't name explicit when-not/alternatives, but there is no direct sibling for this operation, so the context is sufficient.

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 meaningful behavioral context beyond the annotations: results are grouped per originating keyword, each suggestion has availability that can be available/taken/unknown, and unknown or premium-TLD names should be verified before recommendation. No contradiction with the readOnly/idempotent hints.

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 dense sentences covering action, constraints, workflow, and follow-up with no filler. The tool name prefix is slightly redundant, but the substantive content is front-loaded and 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?

There is no output schema, so the description compensates by stating output grouping, the three possible availability values, and the safe confirmation path via checkDomainAvailability. This gives an agent enough to call the tool correctly and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3; the description enriches keywords and tlds by restating hard caps and linking TLD selection to listCategorizedTlds. It also clarifies output grouping semantics, though lang and maxResults rely on schema defaults.

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 action—generate domain suggestions—with precise constraints (1-10 keywords, 1-6 TLDs, hard cap) and output grouping. This clearly differentiates it from sibling tools like generateDomainSuggestions by emphasizing bulk/multi-keyword scope.

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

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

Explicitly prescribes a typical flow: call listCategorizedTlds first to choose TLDs, then use this tool, and follow up with checkDomainAvailability for uncertain results. It does not explicitly contrast with generateDomainSuggestions, so it is clear on workflow but not a full when-not-to-use guide.

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

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

Beyond the annotations, the description adds valuable behavioral context: the operation is destructive and irreversible once executed, requires authentication, returns an actionId, and is only a staging step rather than the final execution. This directly helps the agent understand the two-phase nature of the cancellation and what to do with the result.

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 compact and front-loaded: purpose first, then the safety warning, then the workflow. Every sentence contributes essential information, and the warning about destructiveness is prominent before the user proceeds.

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 tool with rich annotations, the description covers all critical aspects: what it does, what it returns, the required follow-up action, the destructive nature, and authentication. Nothing an agent needs to call it correctly or handle its result is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add parameter-specific meaning, but it also doesn't need to; the schema carries the burden. A baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Stage cancellation') and resource ('pending domain transfer'), and clearly distinguishes this tool from the actual execution step by naming executeConfirmedAction as the follow-up. It also implies the domain must currently be pending, distinguishing it from transfer initiation tools.

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

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

The description explicitly states when to use this tool (for a pending domain transfer) and outlines the exact workflow: after calling it, present the returned summary and call executeConfirmedAction with the actionId if the user approves. This gives the agent clear routing and next-step guidance without ambiguity.

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 readOnlyHint=false and destructiveHint=false, so the agent knows it's a mutating but non-destructive operation. The description adds the authentication requirement, which is not in annotations, and clarifies 'payment term (billing cycle)' semantics. However, it does not disclose side effects such as immediate effect on billing or potential proration, so context added is minimal.

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 one sentence plus an auth requirement, with the action front-loaded. No filler words; the name prefix is slightly redundant but harmless.

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 mutation with only two required parameters, the schema covers all inputs and the description provides the operation's purpose and auth prerequisite. The lack of an output schema is acceptable for a write operation, and no critical invocation detail appears missing. It's sufficiently complete for an agent 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?

All three parameters are fully described in the schema, including the allowed values for paymentTerm and the conditional use of sessionKey. The description adds no parameter-level detail beyond calling the payment term a billing cycle, so baseline 3 applies.

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

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

States a specific action and object: 'Change the payment term (billing cycle) for a VPS instance.' This clearly identifies the verb 'change' and the resource 'payment term of a VPS instance,' distinguishing it from VPS lifecycle tools like buildVpsInstance or deleteVpsInstance. The added auth note is extra context, not purpose.

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 guidance on when to use this tool over alternatives, nor exclusions. The only usage-related information is 'Requires authentication,' which serves as a prerequisite rather than a selection criterion. Usage is implied from the purpose, but not 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?

The tool is a polling operation, and the description says 'Poll for device login completion' and notes that success returns a sessionKey. This adds context beyond the annotations, which only state readOnlyHint=false, idempotentHint=false, and destructiveHint=false. It doesn't detail error behavior or what happens before completion, but for a simple poll the disclosure is adequate.

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: purpose, call sequence, and required input/return handling. The most important information is front-loaded, and there is 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?

For a one-parameter tool with a clear position in a flow, the description covers the prerequisite call, input origin, success return, and how to use the result. It doesn't mention failure modes or polling behavior details, but an output schema exists and the sibling list clarifies the flow context, so the omission is minor.

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

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

Schema coverage is 100%: the parameter deviceCode is already described as 'The device_code value returned by loginWithDevice.' The description repeats this ('the device_code returned by loginWithDevice') and adds 'Required,' but this is also already in the schema's required list. No new semantic information about the parameter is provided beyond the schema.

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

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

The description opens with 'Poll for device login completion,' which names a specific verb and resource, clearly distinguishing this tool from its siblings like loginWithDevice (which initiates the flow) and getAuthStatus (which checks general auth state). It also states the concrete success outcome ('returns a sessionKey'), leaving no ambiguity about what the tool does.

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 explicitly gives the usage context: 'Call this after loginWithDevice() once you have opened the verification URL and signed in.' It also specifies the prerequisite input (deviceCode returned by loginWithDevice) and the downstream behavior ('pass it as the sessionKey argument on every subsequent authenticated tool call'), making the call sequence 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful behavior beyond that: anonymous callers receive list pricing, authenticated callers receive account pricing, and no authentication is required to use the tool.

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

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

Three short sentences convey purpose, authentication behavior, pricing, and required input with no filler. The leading 'checkDomainAvailability:' label duplicates the tool name but does not seriously hurt readability.

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

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

For a simple two-parameter read-only lookup with an output schema and rich annotations, the description covers purpose, authentication model, pricing difference, and required parameter. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, and the domain example in the description mirrors the schema's own description. The description does not add meaningful detail about the sessionKey parameter or any behavior beyond what the input schema already documents, so it sits at the baseline.

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

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

The description opens with a specific verb and resource: 'Check if a domain name is available for registration, with price.' Naming domain rather than host or keyword separates it from sibling tools, and the price mention distinguishes it from a pure availability-only check.

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 provides clear operational context: no authentication is required, anonymous callers get list pricing while authenticated callers get account pricing, and domain is the required input. It does not explicitly name alternatives like checkHostAvailability or getDomainPricing, but the domain-specific wording makes the intended use clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavior beyond those: it requires authentication and 'returns whether the hostname is free', explaining the return semantics. It also clarifies the scope to host/glue records. No contradictions with annotations.

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

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

Two tight sentences cover purpose, auth, return value, and workflow position. Every clause earns its place, and the main action is front-loaded. No fluff or repetition of 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?

For a simple read-only availability check with one required parameter, the description provides everything an agent needs to invoke it correctly: what it does, that auth is required, what the return represents, and when to call it relative to createHost. With no output schema, the return semantics note is sufficient.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The tool description adds no new parameter meaning; it only repeats that the hostname is a host/glue record, which the schema already conveys with 'Fully qualified host name'. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Check if a host/glue record name is available for creation.' It clearly distinguishes itself from sibling tools like checkDomainAvailability and checkKeywordAvailability by specifying 'host/glue record', and it ties to createHost. This is precise and unambiguous.

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

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

The description gives clear usage context: 'call before createHost' explicitly tells the agent when to invoke this tool. It also notes the authentication prerequisite. However, it doesn't explicitly say when not to use it or name alternatives (e.g., checkDomainAvailability), so it stops short of a full 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?

The annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond that: the operation spans all supported TLDs and registries and returns detailed per-domain results. It doesn't mention rate limits or result structure, but the additive scope and detail-level information earn it slightly above baseline.

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 compact and front-loaded, with the core purpose in the first sentence and a useful alternative in the second. It loses one point for the redundant 'checkKeywordAvailability:' prefix that merely repeats the tool name already known from the 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?

The description is sufficient for basic selection and invocation: it states scope, result granularity, and when to use the faster alternative. However, since there is no output schema, the phrase 'detailed per-domain results' is vague about what fields the agent should expect, and it doesn't clarify default behavior when tlds or registries are omitted beyond the implicit 'all supported.'

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

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

Schema description coverage is 100%, so the schema fully documents keyword, tlds, and registries. The description adds no parameter-specific syntax or semantics beyond what the schema already provides, making the baseline of 3 appropriate.

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

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

The description begins with a specific verb and resource: 'Check keyword availability across all supported TLDs and registries with detailed per-domain results.' It also distinguishes this tool from the summary variant by emphasizing detailed per-domain results, so an agent can identify its unique purpose without opening sibling schemas.

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

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

The description explicitly names the alternative tool, checkKeywordAvailabilitySummary, and gives the condition for choosing it: 'when you only need counts; it is faster.' This is clear, actionable routing guidance that leaves little to inference.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond annotations: it returns only summary statistics, never per-domain results, and is faster than the full checkKeywordAvailability tool. This is valuable but does not detail what the summary statistics contain or any response format.

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 one tight sentence that front-loads the core purpose and immediately states key behavioral distinctions. The repeated tool name prefix is slightly redundant, but the rest is compact and every clause adds meaningful 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?

Parameters are fully documented in the schema and safety behavior is covered by annotations, so the description does not need to repeat those. However, there is no output schema, and the description only vaguely says 'summary statistics' without explaining what statistics are returned. An agent might still be uncertain whether the output satisfies a user's request.

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

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

Schema description coverage is 100%, with clear explanations for tlds, keyword, and registries. The description does not add any parameter-level guidance, which is acceptable since the schema already documents each parameter fully. No extra semantic value is needed beyond what the schema provides.

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

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

The description clearly defines the tool as checking keyword availability across TLDs and registries, and explicitly distinguishes it from the sibling checkKeywordAvailability by emphasizing summary-only results and faster execution. This gives an agent a precise idea of what the tool does and how it differs from similar tools.

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

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

The description gives clear selection context: use this tool when only summary statistics are needed and when faster results matter, while explicitly noting that per-domain results are not included. It names the alternative tool but does not fully state 'use checkKeywordAvailability when per-domain results are required,' leaving a small gap in explicit when-not-to-use 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 cover read-only, idempotent, and non-destructive behavior. The description adds the authentication requirement and clarifies that the count is scoped to the authenticated user's own instances, which is useful operational context beyond what the annotations provide.

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

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

A single sentence that front-loads the action and resource, followed by the key authentication requirement. No wasted words or redundant restatements of the tool name.

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

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

For a simple count operation with an optional parameter and strong annotation coverage, the description is largely complete. It states the essential authentication requirement and ownership scope; the return value is self-explanatory as a count, so no output schema is necessary.

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 optional sessionKey parameter is fully documented in the schema (100% coverage), so the baseline of 3 applies. The description does not add any parameter-specific semantics, but it does hint that authentication is required, which is indirectly related to the sessionKey.

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

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

States the verb 'Get' and the resource 'total count of VPS instances', scoped to the authenticated user. This clearly distinguishes it from sibling tools like listMyVpsInstances, which returns a list, and getVpsInstanceDetails, which returns details for one instance.

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

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

The description implies usage for counting instances rather than listing them, but it never explicitly names alternatives or says when to choose this tool over listMyVpsInstances. The authentication requirement is stated, but no when-to-use or when-not-to-use guidance is provided.

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

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

Beyond the annotations (mutation, idempotent, non-destructive), the description discloses that the call requires no auth, sends a verification email, leaves the account in PENDING_VERIFICATION with specific permitted actions, and re-sends the email if called again. These are behavioral traits not present in the schema or annotations.

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

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

The prose is front-loaded with the core action, then gives the identity constraint, verification step, state implications, and repeat-call behavior in compact clauses. No filler sentences; each clause earns its place even though the description runs longer than the minimal example.

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 9-parameter mutation with a nested object and output schema, the description is sufficient: it covers auth requirements, step sequencing, state restrictions, and repeated call behavior. Output details are delegated to the output schema, which is appropriate.

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?

All nine inputs are documented in the schema (100% coverage), so the baseline is met. The description reinforces the contact-principal rule, but that rule largely repeats the schema's contact description and does not add new parameter semantics.

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

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

The description opens with a concrete verb and resource—'Create a new OSIR customer account'—and adds workflow context ('step 1 of onboarding, no authentication required'). It is distinguishable from siblings like createContact and verifyAccount because it defines the account-level creation step and even names verifyAccount as the follow-up.

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?

'Step 1 of onboarding' plus 'complete via verifyAccount' gives a clear invocation context, and the PENDING_VERIFICATION vs ACTIVE states explain when the account is usable. It does not list exclusions or alternative tools for non-account cases, but the workflow 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 annotations (readOnlyHint=false, etc.), the description adds that authentication is required and that the created contact is returned including its id for assignment to domains. This is useful behavioral information not otherwise conveyed by annotations alone.

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

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

The description is two compact sentences with no fluff. The primary purpose is front-loaded, followed by auth requirement and return value. 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?

The description covers purpose, auth, and the key return value (the id). With no output schema, mentioning the id is valuable. Minor gap: it doesn't describe the full return structure or any side effects, but the schema handles parameter details.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add any parameter-level detail beyond what the schema already provides, and that is acceptable given the thorough schema descriptions.

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

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

The description states a specific verb (create), resource (contact), and purpose ('for use with domain registrations'). This clearly distinguishes it from contact-related siblings like updateContact, deleteContact, getContact, and listContacts.

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 provides clear context: creating a contact for domain registrations, and it explicitly notes that authentication is required. It doesn't explicitly name alternatives or exclusions, but the create-vs-update/delete role is obvious from the verb and resource.

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

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses that authentication is required, that missing zones for newly registered domains are automatically initialized, and that the created record (with id) is returned. It does not cover duplicate-name behavior or propagation timing, but the key side effects of creation and return value are transparent.

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 compact and front-loaded with the core action. The only redundancy is the leading 'createDnsRecord:' prefix that repeats the tool name; otherwise every sentence conveys useful information (auth, auto-initialization, return value).

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

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

For a 7-parameter mutation tool with no output schema, the description covers the essential prerequisites, a notable automatic behavior, and the shape of the return value. It does not describe possible error conditions or edge cases, but the schema and sibling context fill most of what an agent needs to select and invoke 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?

The input schema already describes all seven parameters at 100% coverage, so the baseline is 3. The description adds no additional parameter-level detail, only mentioning that the returned record contains an id. No compensation is needed, but none is provided beyond the schema.

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

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

States a specific verb and resource: 'Create a new DNS record for a domain.' This clearly differentiates from sibling tools like updateDnsRecord, deleteDnsRecord, getDnsRecord, and listDnsRecords. The mention of 'new' and 'for a domain' leaves no ambiguity about the operation's scope.

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

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

Provides clear context by stating authentication is required and explaining that zones are auto-initialized for newly registered domains, which signals when initializeDnsZone is unnecessary. It also mentions returning the id for later updates or deletion, pointing users to the appropriate sibling tools. However, it does not explicitly state when not to use this tool versus those alternatives.

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

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

Annotations mark this as a non-read-only, non-idempotent operation, but the description adds value by explicitly requiring authentication, advising an availability pre-check, and disclosing that the created host record is returned. No contradiction with 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 focused sentences front-load the core purpose, then add the prerequisite and return behavior. Every sentence contributes useful information without repetition or filler.

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

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

For a create operation with no output schema and partial annotation coverage, the description covers what the tool does, its authentication requirement, the suggested pre-check, and its return value. It could mention failure behavior, but the essentials for correct invocation are present.

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

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

Schema description coverage is 100%, so parameter meaning is already fully documented. The description reinforces the hostname example but does not add substantial new parameter semantics beyond what the schema provides.

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

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

The description states a specific verb and resource ('Create a new host/glue record') with a concrete example ('ns1.example.com'). It clearly distinguishes from related siblings like createDnsRecord and deleteHost by naming the host-record concept.

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

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

The description gives clear context and an explicit prerequisite: check the name first with checkHostAvailability. It does not enumerate alternative tools or when not to use it, but the purpose is specific enough that the guidance 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?

The description discloses critical behaviors beyond the annotations: it is BILLABLE and deducts from account balance, requires authentication, returns an actionId for confirmation, and reveals that the generated password appears exactly once and can never be retrieved again. None of this is present in the annotations, so the description carries and fulfills the full burden.

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 dense but every sentence earns its place: staging, billing, quote prerequisite, actionId handoff, one-time password disclosure, and client settings. Pricing/billing warnings are front-loaded ahead of implementation details.

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 paid two-step action with no output schema, the description is complete: it explains the quote step, the actionId confirmation step, the one-time password behavior, the ability to reset later, and what client settings to share. An agent has the information needed to execute the flow responsibly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the overall flow but adds little parameter-specific detail beyond what the schema already provides; it does not explain term formats, sessionKey mechanics, or localPart constraints beyond the schema.

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

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

The description uses a specific verb and resource: 'Stage creation of a paid mailbox on a mail-enabled domain.' It also clarifies that this tool does not immediately create the mailbox, which distinguishes it from namesake expectations and from executeConfirmedAction.

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

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

The description gives an explicit workflow: get a quote with getMailboxQuote, confirm the price with the user, call createMailbox, then call executeConfirmedAction with the returned actionId if approved. It also references setMailboxPassword for later changes, giving clear when-to-use and next-step 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?

With only weak annotations (readOnlyHint=false, idempotentHint=false), the description carries the burden and excels. It discloses the two-phase confirmation model, that execution returns checkoutUrl and expiresAt, and that the balance credit is not immediate and must be polled for. This goes well beyond what annotations provide.

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

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

The description is dense but efficient, front-loading the purpose and then walking through the required follow-up actions in a logical order. Every clause adds necessary behavioral or workflow information, with no filler or repeated schema content.

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-phase mutation tool with no output schema, the description covers the essential flow well: actionId, confirmation, checkoutUrl, expiresAt, and polling. The only minor gap is a slight ambiguity around 'present the summary to the user'—it does not specify where that summary content comes from, but the overall workflow is still actionable.

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

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

Schema description coverage is 100%, so the schema already documents amount, currency, and sessionKey thoroughly. The description does not add parameter-level details beyond what the schema states. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Stage a Stripe checkout session to add funds to the account balance.' This clearly differentiates it from payment-related siblings like payInvoice (paying an existing invoice) and getPaymentTransactions (reading transactions). An agent can immediately tell what the tool accomplishes.

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

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

The description gives clear process guidance: requires authentication, returns an actionId, must be confirmed via executeConfirmedAction, and should be followed by polling getPaymentTransactions. It does not explicitly contrast with alternatives like payInvoice or previewPaymentFees, but the flow and purpose are clear enough that an agent can decide when to invoke it.

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

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

While annotations already flag destructiveHint=true, the description adds meaningful behavioral context: 'Stage deletion' reveals the two-phase nature, 'fails if the contact is assigned to active domains' discloses a key failure mode, and 'Requires authentication' and 'Returns an actionId; present the summary to the user, then call executeConfirmedAction' explain the necessary follow-up behavior. This goes well beyond what annotations provide.

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

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

The description is compact and front-loaded: the core purpose appears first, followed by a DESTRUCTIVE warning, a failure condition, and the mandatory confirmation workflow. Every sentence contributes necessary information without repetition or filler.

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

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

For a two-phase destructive tool with no output schema, the description covers everything an agent needs: the staging behavior, failure condition, authentication requirement, the actionId return value, and the exact next tool to call. The required next step, executeConfirmedAction, is explicitly named, making the workflow complete.

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

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

Schema description coverage is 100%, and both parameters are individually documented in the input schema, including that contactId comes from listContacts and sessionKey is only needed for device login. The tool description does not add additional parameter-level detail, which aligns with the baseline 3 for high schema coverage.

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 uses a specific verb and resource: 'Stage deletion of a contact.' It clearly distinguishes this from createContact, updateContact, and executeConfirmedAction by explaining it is the staging step, not the final deletion. The additional constraint about active domains adds specificity.

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 clearly indicates when to use the tool: when a contact deletion needs to be staged, and then when to proceed with executeConfirmedAction. It also gives an exclusion condition: fails if the contact is assigned to active domains. It does not explicitly contrast with sibling tools like updateContact, but the workflow guidance is strong enough to route an agent correctly.

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 destructiveHint annotation, the description discloses that the tool only stages deletion, is irreversible once executed, returns an actionId, and requires a follow-up confirmation call. This significantly enriches the agent's understanding of the tool's non-immediate and gated destructive behavior. No contradiction with annotations; idempotentHint is consistent with staging.

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, dense sentence that front-loads the purpose, includes critical warnings, and provides the action flow. Every clause adds value without redundancy. It is concise and well-structured for an agent to parse quickly.

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 description covers the essential flow: staging, confirmation, and execution. It states the return value (actionId) and the next step. It doesn't elaborate on what the summary should contain or what happens if the user declines, but these are minor gaps given the tool's simplicity and the presence of annotations.

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

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

The description adds no parameter-specific meaning, but the input schema provides complete descriptions for all three parameters, including examples and context (e.g., recordId references listDnsRecords, sessionKey explains when to include). Since schema coverage is 100% and descriptions are thorough, the baseline of 3 is appropriate.

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

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

The description clearly states the tool stages the deletion of a DNS record, distinguishing it from create/update operations. It specifies the resource and action precisely, and the warning 'DESTRUCTIVE and irreversible once executed' adds critical purpose context. The sibling list includes createDnsRecord and updateDnsRecord, so this purpose is unambiguous.

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

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

The description explicitly instructs the agent to present the summary and call executeConfirmedAction if approved, providing a clear two-step usage flow. It does not explicitly contrast with alternatives like updateDnsRecord, but the deletion intent is obvious. The 'Requires authentication' note is generic but not misleading.

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, but the description adds crucial context: 'DESTRUCTIVE and irreversible once executed', 'Requires authentication', and the two-phase flow via actionId. This is high-value behavioral disclosure beyond the structured annotations and explains the staged-deletion contract.

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 compact and front-loads the destructive warning before the workflow steps. Each sentence adds a distinct, necessary fact: what is staged, the danger, the auth requirement, and the exact follow-up action.

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 tool with complete schema coverage and relevant annotations, the description fully covers what an agent needs: the action is staged, destructive, requires auth, and the returned actionId feeds into executeConfirmedAction. No output schema is present, but the return value is described in prose.

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

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

Schema description coverage is 100%, with both hostname and sessionKey already explained in the input schema. The tool description does not add parameter-specific detail, but none is needed because the schema fully covers semantics.

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

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

The description states a specific verb ('Stage deletion') and resource ('host/glue record'), immediately clarifying what the tool does. It also distinguishes this from the actual execution step by naming executeConfirmedAction as the follow-up, making its role in the deletion flow explicit.

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

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

The description gives clear procedural guidance: returns an actionId, present the summary to the user, then call executeConfirmedAction with the actionId if approved. It does not explicitly contrast this with sibling deletion tools like deleteDnsRecord or deleteMailbox, but the resource scope is clear enough for correct selection.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses critical behaviors: the mailbox stops working immediately, data is destroyed only after a 14-day grace period, and the operation is staged rather than executed directly. It also names the exact response payload (actionId) and the required confirmation handoff. This is exactly the kind of behavioral context an agent needs for a destructive operation, and it is not available anywhere else.

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, zero filler. The core action is front-loaded ('Stage deletion of a mailbox'), followed by consequences, then the actionable workflow. Every sentence carries essential information: effect timeline, auth requirement, and the follow-up protocol. This is appropriately sized for a destructive tool with a confirmation flow.

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?

Since there is no output schema, the description correctly takes on the burden of explaining the return value and names it precisely (actionId), along with the exact next step (call executeConfirmedAction). It also covers the operational impact (immediate disablement, 14-day grace) and auth requirement. For a two-phase destructive operation, nothing an agent needs to invoke 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 coverage is 100% — both mailboxId and sessionKey are already fully documented in the input schema, including the osk_ prefix convention and the OAuth/device-flow distinction. The description adds no parameter-specific detail beyond what the schema provides, so the baseline of 3 applies. The mention of 'requires authentication' loosely reinforces the sessionKey role but adds no new semantics.

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

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

The description opens with 'Stage deletion of a mailbox' — a specific verb (stage deletion) paired with a clear resource. The 'stage' framing distinguishes it from an immediate-delete tool and from sibling mailbox tools like createMailbox, setMailboxPassword, and listMailboxes. The two-phase nature is explicit and leaves no ambiguity about what the tool accomplishes.

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 provides clear workflow context: it explains that deletion is staged, requires authentication, and mandates a follow-up call to executeConfirmedAction with the returned actionId. This tells the agent exactly what to do after invocation — present the summary and get confirmation. It doesn't explicitly contrast with alternatives or state when not to use it, but the workflow guidance is concrete enough that no usage confusion remains.

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

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

Annotations already flag destructiveHint and idempotentHint, and the description adds useful beyond-schema context: deletion does not affect existing servers and is reversible by adding the key again. It also notes the authentication requirement. No contradiction with 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 short sentences, each earning its place: the operation, the critical consequence, and the authentication requirement. It is front-loaded and free of filler.

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

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

For a simple two-parameter delete operation, the description plus annotations cover scope, reversibility, and prerequisite. It does not describe the response format, but no output schema exists and the behavior for success/error is fairly predictable for a delete call.

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

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

Schema description coverage is 100%, and parameter descriptions are explicit, including where to obtain keyId and how to handle sessionKey. The tool description itself adds little parameter-level meaning, so the baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Remove an SSH key from your account.' This clearly distinguishes it from sibling operations like addSshKey and listMySshKeys, and the account-level scope prevents confusion with server-specific key management.

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 states a prerequisite ('Requires authentication') and a consequence that informs when it is appropriate to delete (servers are unaffected, key can be re-added), but it does not explicitly name alternatives or specify when not to use it. The intended use is implied rather than directly contrasted with addSshKey.

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

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

Annotations already mark the tool destructive and readOnlyHint=false, and the description reinforces this with 'DESTRUCTIVE and irreversible.' It adds valuable behavioral context beyond annotations: authentication is required, the tool returns an actionId, and the deletion is not final until executeConfirmedAction is called. No contradiction with annotations.

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

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

Two dense sentences carry all essential information: the operation, its severity, auth requirement, return value, and the follow-up action. The most critical warning is front-loaded, and there is no filler.

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

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

The description is complete for a destructive two-phase operation. It covers safety, auth, the actionId return contract, and the handoff to executeConfirmedAction, which is essential because no output schema exists. Nothing critical is missing for an agent to invoke 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 100%: instanceId and sessionKey both have clear descriptions already. The tool description does not add parameter-level detail, so it meets the baseline for relying on the schema without adding new semantic value.

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

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

The description names a specific verb and resource—'stage deletion/cancellation of a VPS instance'—and explains that the action is destructive and irreversible. This clearly distinguishes it from the sibling executeConfirmedAction by framing deletion as a staged, two-step process.

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 explicitly explains the required workflow: call this tool to stage deletion, present the returned summary to the user, and then invoke executeConfirmedAction for approval. It does not list exhaustive exclusions or alternatives, but the condition-based next step is unmistakable.

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

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

With annotations already marking this as non-read-only, idempotent, and non-destructive, the description adds meaningful behavioral context: it can hit a DNS conflict, may require user consent before overwriting SPF/MX records, and requires authentication. It explains the failure path and the consent flow better than the annotations alone, though it does not describe what the successful response looks 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?

The description is compact and front-loaded with the core purpose. Every sentence earns its place: purpose, cost context, failure handling with consent, and authentication requirement. No redundant or filler content.

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 tool with five parameters, one required, and no output schema, the description covers the key operational concerns: what it does, when it fails, how to recover, and authentication. Minor gaps are the absence of any mention of the success return value and the lack of an explicit pointer to a related verification step for external DNS mode, though the schema partially covers that.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds value by connecting the failure scenario to spfMergeConfirmed and takeoverConfirmed, explaining when to use these flags. It also clarifies the ownership prerequisite for the 'domain' parameter. This is genuine semantic enrichment beyond the rich 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 identifies a specific verb and resource: 'Enable email hosting on a domain you own.' This clearly distinguishes the tool from siblings like createMailbox, listMailDomains, and verifyMailDns, whose roles are different enough that an agent can select this one correctly.

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

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

The description gives clear usage context: use it on a domain you own, it is free, mailboxes cost extra, and authentication is required. It also provides conditional guidance for DNS conflicts, including when to set confirmation flags. It does not explicitly name alternative tools or state when not to use this tool, so it stays just short of a 5.

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

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

Annotations already indicate destructive and non-read-only behavior. The description adds valuable constraints beyond annotations: the action expires after 5 minutes and can only be executed once. It doesn't mention failure modes after expiry, but with the annotation coverage 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?

Two sentences with no wasted words: the first states the purpose, the second packs two essential constraints. The repeated tool name at the start is trivial, but every sentence carries real 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 2-parameter tool with rich schema descriptions and clear constraints, the description covers the core prerequisites: what the action is, when it can be executed, and its limits. It omits return-value or error behavior, but no output schema exists and the staging flow largely implies the result.

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

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

Schema description coverage is 100%, with thorough parameter explanations: actionId is the UUID from the staging tool's response, and sessionKey has clear usage rules with OAuth vs device flow. The description adds no parameter-specific detail, so baseline 3 applies.

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

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

The description states a specific verb and resource: execute a previously staged destructive or financial action after user approval. This distinguishes it from siblings like payInvoice or deleteHost by emphasizing the staged-and-approved gating, though no sibling is named explicitly.

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

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

The description gives clear usage context: only for previously staged actions, only after user approval, and subject to a 5-minute expiry and single-use rule. It doesn't name alternatives, but the staging-to-execution flow is implicitly defined, and this is clearly the confirmation step.

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

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

Annotations already cover the read-only, idempotent, and non-destructive profile. The description adds value by stating that results include availability, which is useful since there is no output schema. No contradiction with annotations.

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

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

Two tight sentences with no filler: action, routing guidance, and return-value note are each meaningful. The most important scoping information is front-loaded.

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

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

For a read-only suggestion tool with five schema-documented parameters, the description plus annotations are sufficient for an agent to select and invoke it. Without an output schema, the availability note is brief but adequate.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents each parameter. The description reinforces 'single keyword' usage but adds no parameter-specific detail beyond the schema.

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

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

The description names a specific verb ('Generate') and resource ('domain name suggestions') and scopes the behavior to keywords. It also explicitly distinguishes this tool from suggestAlternatives, so an agent can tell them apart.

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 provides a clear selection rule: 'preferred suggestion tool for a single keyword; use it over suggestAlternatives.' This gives an explicit when-to-use condition and names the direct alternative, leaving little 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, idempotentHint=true, and destructiveHint=false, so the description only adds the authentication requirement. That is useful but does not provide deeper behavioral context such as staleness, caching, or response shape.

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

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

The description is very brief and front-loaded with the core purpose. The redundant 'getAccountBalance:' prefix mildly repeats the tool name, but the content is otherwise efficient and free of filler.

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

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

For a simple read-only tool with one optional parameter and an output schema, the description is mostly sufficient. The authentication requirement is stated, and annotations cover safety, though it could note when to prefer this over similar account-related getters.

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

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

Schema description coverage is 100%, with the sessionKey parameter already well-documented. The description adds no extra meaning about parameters, so the baseline score of 3 applies.

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

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

The description clearly states the verb 'Get' and the resource 'current account balance,' and adds scope with 'for the authenticated user.' It does not explicitly distinguish itself from sibling tools like getAccountSummary, so it stops short of a 5.

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

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

The only guidance is that authentication is required, which is a prerequisite rather than guidance on when to use this tool versus alternatives. No sibling tools or conditional selection criteria are mentioned.

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

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

Annotations already communicate read-only, idempotent, and non-destructive behavior. The description adds the authentication requirement, which is a meaningful behavioral constraint beyond the annotations. It does not elaborate on edge cases or response shape, but the added auth context is valuable.

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

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

The description is a single, front-loaded sentence that states the purpose, lists the main contents, and notes the auth requirement. Every part earns its place with no redundant filler.

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

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

The tool is simple (one optional parameter, no output schema), and the description sufficiently explains what the summary contains and that authentication is required. It stops short of describing the exact structure of the returned summary, but that is not essential for selecting and invoking the tool.

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

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

Schema description coverage is 100% and the only parameter, sessionKey, is fully documented in the schema. The tool description does not add parameter-level detail, but with the schema already handling this, the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb and resource ('Get a comprehensive summary of the user's account') and enumerates the included areas (profile, balance, domain count, VPS count, pending transfers). This distinguishes it from overlapping sibling tools like getAccountBalance or getMyProfile by framing it as a single aggregated overview.

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

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

The description gives clear context for use: any time a broad account overview is needed rather than a single detail. It does not explicitly name alternatives or exclusion conditions, but the enumerated summary contents make the intended use reasonably obvious.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool returns authenticated status and token expiry, but does not disclose error behavior or authentication requirements beyond that.

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

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

The description is short and front-loaded with the core purpose. The redundant 'getAuthStatus:' prefix and the repeated sessionKey note are minor wastes, but overall it is compact and scannable.

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

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

For a simple read-only status check with one optional parameter, full schema coverage, and an output schema, the description covers the essential purpose and return info. It does not mention the nuanced 'omit sessionKey for OAuth' rule, but that is already in the parameter 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 100%, so the schema already fully documents the sessionKey parameter. The description's mention of 'sessionKey (from checkDeviceLoginStatus)' adds minimal value beyond the schema's own detailed explanation.

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

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

States a specific verb ('check'), a clear resource ('current session authentication'), and the return value ('authenticated status and token expiry'). It clearly distinguishes itself from sibling checkDeviceLoginStatus by referring to the current session and the session key source.

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

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

The description gives clear context: check whether the current session is authenticated, and pass an optional sessionKey from the device flow. It does not explicitly state when not to use the tool or name alternatives, but the purpose is distinct enough for an agent to infer correct usage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations by stating that authentication is required and by disclosing the specific fields returned, which matters since no output schema exists.

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

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

The description is three short sentences with no filler: purpose, auth requirement, parameter source, and return fields. The repeated tool name 'getContact:' is a minor redundancy, but each sentence earns its place and the key information is front-loaded.

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

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

For a simple single-resource read operation with one required parameter and a well-documented optional sessionKey, the description covers what an agent needs: what the tool does, where the identifier comes from, authentication expectations, and return contents. No output schema exists, so the explicit return-field list is especially valuable.

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

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

Schema description coverage is 100%, so the input schema fully documents both contactId and sessionKey. The description's mention of sourcing contactId from listContacts adds workflow context but does not materially extend the semantic detail already present in the schema.

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

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

The description states a specific verb and resource: 'Get detailed information about a specific contact.' It also distinguishes itself from listContacts by targeting a single contact, and the included return fields (name, email, phone, organization, address) make the purpose unambiguous.

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

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

The description gives practical usage guidance by telling the agent to obtain contactId from listContacts, which establishes the correct upstream workflow. It does not explicitly exclude alternatives such as getContactsForDomain, but the single-contact framing makes the intended use clear.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. On top of that, the description adds the authentication requirement and clarifies that the result is organized by contact role, which is useful behavioral context beyond the schema and annotations.

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

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

The description is a single tight sentence with no filler. It front-loads the core purpose, names the roles, and adds the two most important operational facts: authentication is required and the result is role-based.

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

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

For a simple read-only tool with one required parameter and full schema coverage, the description covers the essential operational and return information. There is no output schema, so it could be more specific about the exact shape of each contact object, but the current level is adequate for safe invocation.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add parameter-level detail, but it also does not need to; it reinforces that the domain parameter determines which contacts are returned.

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: it gets all contacts assigned to a domain and explicitly names the four roles (registrant, admin, tech, billing). This clearly distinguishes it from related tools like getContact and listContacts, which operate at a different level of granularity.

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 makes clear this is the tool to use when you need the set of role-based contacts for a specific domain, and it notes the authentication requirement. It does not explicitly name alternatives or exclusions, but the domain-scoped purpose is strong enough for an agent to infer when to choose it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful context beyond annotations by stating that no authentication is required and that the tool returns all configurations with pricing and specifications.

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

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

The description is short and front-loaded, with the core purpose stated first and the authentication requirement as a separate brief sentence. The only minor redundancy is repeating the tool name before the verb phrase.

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

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

For a zero-parameter, read-only catalog retrieval tool, the description gives enough context: it names the resource, the content scope, and the authentication requirement. There is no output schema, but the expected return shape is reasonably inferable from 'configurations with pricing and specifications.'

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 and an empty input schema, so parameter-level documentation is unnecessary. The baseline for zero-parameter tools is 4, and the description doesn't need to compensate for any undocumented parameters.

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

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

The description uses a specific verb and object: 'Get all available dedicated server configurations with pricing and specifications.' It clearly identifies the resource and scope, and the phrase 'dedicated server' distinguishes it from sibling catalog tools like getProductCatalog and listVpsPackages.

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

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

The description gives no explicit guidance on when to choose this tool over siblings such as getProductCatalog or listVpsPackages. 'No authentication required' is a useful prerequisite, but it does not help an agent decide between related catalog/list tools.

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

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

Annotations already establish the read-only/idempotent/safe profile, and the description adds beyond that by disclosing the authentication requirement and the exact return fields (name, type, content, TTL, priority). For a simple read operation with no output schema, this is solid, though it does not cover error/not-found 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?

All content is front-loaded: purpose in the first clause, then prerequisite, auth, and output. Each sentence carries distinct information, and no filler words are present.

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 low-complexity, read-only getter with a complete input schema and no output schema, the description supplies the missing output fields, auth context, and ID sourcing. Nothing required to call the tool successfully is absent.

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

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

Schema coverage is 100%, so the structured descriptions already fully explain domain, recordId, and sessionKey. The description reinforces that recordId comes from listDnsRecords, but that fact is already in the schema, so no additional parameter meaning is added.

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 ('details of a specific DNS record') scoped by 'id', which clearly separates it from list and mutation DNS tools among siblings. It also names where the ID comes from (listDnsRecords), reinforcing its role as the single-record read companion.

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

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

Provides clear context by instructing the agent to obtain recordId from listDnsRecords and noting that authentication is required. It does not explicitly enumerate when-not-to-use alternatives, so it misses the top-tier 'exclusions vs alternatives' bar.

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 provide the key safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), and the description adds the authentication requirement and clarifies the response covers 'history of all changes.' This is useful but does not disclose details like authorization scope, pagination, or ordering.

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

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

The description is two short sentences with no filler. It front-loads the core action and resource, then adds the authentication prerequisite. Every word contributes to understanding the tool.

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

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

For a simple read-only parameterized tool with full schema coverage and robust annotations, the description is sufficient. It identifies the resource, the object returned, and the auth requirement. It does not describe output format, but no output schema exists and the return concept is clearly stated as 'audit trail (history of all changes).'

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

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

Schema description coverage is 100%, so the schema already explains both parameters. The description does not add semantics beyond identifying the target as 'a specific domain,' which is already captured in the domain parameter description.

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: 'Get the audit trail ... for a specific domain.' This clearly identifies the tool's function and implicitly differentiates it from broader account-level tools like getMyAuditLogs and getRecentActivity, though it does not explicitly name those 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?

The phrase 'for a specific domain' implies when to use this tool, and 'Requires authentication' is a useful prerequisite. However, it does not explicitly say when to prefer this over related audit/log tools or when not to use it, leaving the usage context mostly implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the operation's safety profile. The description adds useful context by stating that no authentication is required and that the result includes all available TLDs, but it does not describe the return shape, ordering, or pagination behavior. The description does not contradict the annotations.

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

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

The description is two short sentences: the first is front-loaded with the verb, resource, and key content, and the second adds an important access condition. There is no filler or irrelevant 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 parameterless, read-only, idempotent tool, the description is largely self-contained. However, with no output schema and several overlapping siblings, it would be stronger if it clarified the difference between this tool, getDomainPricing, and listCategorizedTlds, or hinted at the response format.

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

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

The input schema has zero parameters, so there are no parameter details the description needs to clarify. The description appropriately omits parameter information, and the 'with pricing information' phrase adds return-value context that is independent of parameters.

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

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

The description uses a clear verb-resource pair: get all available domain extensions (TLDs) with pricing information. It clearly states what is returned, but does not distinguish itself from closely related siblings such as getDomainPricing and listCategorizedTlds, so it lacks explicit sibling differentiation.

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

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

The description gives no guidance on when to call this tool instead of similar sibling tools like getDomainPricing or listCategorizedTlds. It only states an access requirement ('No authentication required'), which does not help an agent choose between alternatives.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses meaningful edge-case behavior: dates are null while registration is pending, and autoRenew is omitted for transferred-out domains. This helps the agent interpret responses correctly without contradicting the annotations.

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

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

The description is a single compact passage that front-loads the core purpose, enumerates the returned data categories, and adds two valuable edge-case notes. Every sentence earns its place with no filler.

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

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

For a read-only tool with no output schema, the description enumerates the main response categories and two important null/omission behaviors. Combined with the fully documented input schema and safety annotations, an agent has enough to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, with both domain and sessionKey already clearly documented. The description only reinforces that the tool handles one domain, adding no new parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get registry (EPP) state plus account settings for one domain', followed by a concrete list of returned information. This clearly distinguishes it from sibling tools like checkDomainAvailability or listUserDomains by focusing on detailed single-domain registry and account data.

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

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

The description gives a clear use case: retrieving detailed EPP state and account settings for one specific domain. It does not explicitly name alternatives or exclusion criteria, but the intended context is evident from the scope and field list.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds 'Requires authentication,' which is a useful operational precondition not expressed in annotations. No contradiction with the annotations.

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

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

Two short sentences front-load the purpose and follow with the authentication precondition. There is minor redundancy in repeating the tool name as a prefix, but otherwise every word earns its place.

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

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

Given the output schema, fully documented optional parameters, and annotations covering the safety profile, the description is largely complete for a simple catalog lookup. It could additionally note the optional-extension behavior or differentiate from getProductCatalog, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, with both parameters clearly explained: 'extension' includes the no-leading-dot format and 'sessionKey' clarifies the two auth flows. The description adds no parameter-level detail, but none is needed because the schema carries the load.

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

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

States the exact resource ('pricing for domain extensions') and source ('product catalog'), making clear this is a catalog lookup rather than an availability check or registration action. It does not explicitly contrast with siblings like getProductCatalog, but the specificity is sufficient to disambiguate.

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

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

The description implies the tool is for retrieving domain-extension pricing and states the authentication precondition. However, it gives no explicit guidance about when to prefer this over alternatives such as getProductCatalog or getDomainExtensions, nor any when-not-to-use guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds meaningful context beyond annotations: no authentication needed, prices are display-only with the authoritative amount computed at purchase, and results are ordered cheapest first. No contradiction exists.

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

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

Three sentences with no filler: purpose and contents first, then usage timing, then price caveat. Every sentence contributes necessary operational or qualifying information, and the most important scope is front-loaded.

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

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

For a single-parameter, read-only tool with a rich output schema and detailed annotations, the description covers auth requirements, when to call, call frequency, result ordering, and pricing semantics. Nothing an agent needs to select or invoke it correctly is missing.

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

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

Schema coverage is 100% for the single domain parameter, and the schema already explains it as a fully qualified domain name. The description references 'specific domain' but does not add meaningful semantic detail beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and names the exact resource: hosting options and exact prices for a specific domain, enumerating VPS packages, email plans, web forwarding, and app/site deployment. This scope distinguishes it from siblings like listVpsPackages or listMailPlans without needing to open their schemas.

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

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

Gives explicit invocation timing: call ONCE after availability check or registration, and explicitly says not to repeat the offer in the same conversation. It also clarifies no authentication is required, giving the agent clear when-to-call guidance versus alternative tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: it states that authentication is required and describes what the response contains (host names and IP addresses).

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

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

The description is two sentences with no filler, and the main action is front-loaded. The redundant 'getHostsForDomain:' prefix is minor and does not meaningfully detract.

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 description covers the core call intent, authentication requirement, and return content. Without an output schema, it would benefit from more detail on response shape or empty-result behavior, but for a straightforward list operation it is largely sufficient.

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

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

Schema description coverage is 100%, so the schema fully documents both 'domain' and 'sessionKey'. The description adds no parameter-specific meaning, but with complete schema coverage the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('List') and names the exact resource ('all host/glue records associated with a domain'), which clearly distinguishes this from sibling tools like getContactsForDomain or listDnsRecords. The scope is unambiguous.

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

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

The description makes the use case clear: call this when you need host/glue records for a domain. It does not explicitly name alternatives or exclusion conditions, but the purpose is distinct enough that usage intent is obvious.

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

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

The annotations already mark readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that authentication is required and that the response includes line items, providing useful behavioral context without contradicting the annotations.

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

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

Two short, front-loaded sentences with no filler. The core action and the distinctive detail (line items) come first, followed by the auth requirement.

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

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

For a simple read-only tool with rich annotations, the description plus schema covers the essentials: what it returns, the auth prerequisite, and the parameters. The only notable omission is explicit guidance distinguishing it from sibling invoice-related tools, but that is a usage-guideline gap rather than a completeness gap.

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

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

Schema description coverage is 100%, so the schema fully documents invoiceId and sessionKey. The description itself adds no parameter-level meaning; it stays at the baseline expected when the schema does the heavy lifting.

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

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

The description names a specific verb and resource ('Get detailed information about a specific invoice') and adds 'including line items,' which clarifies scope. It is clear enough that an agent can tell it returns a single invoice detail rather than a list, though it never explicitly names a sibling tool such as listInvoices for contrast.

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 about when to choose this tool over alternatives like listInvoices or getInvoiceStatistics. The only usage hint is 'Requires authentication,' which is a prerequisite, not a selection criterion.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds an explicit authentication requirement and names the output categories, which provides useful context beyond the annotations. No contradiction exists.

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

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

The description is a single, compact sentence with the core operation and output categories front-loaded. The redundant tool-name prefix is minor but slightly prevents a perfect score for structure.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description provides enough invocation context and enumerates the expected output categories. It misses no critical call-time information.

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

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

Schema description coverage is 100%, and the schema itself explains the sessionKey parameter and when to pass or omit it. The description only reinforces that authentication is required and does not add new parameter-level meaning, so baseline 3 is appropriate.

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

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

The description names a specific verb and resource ('Get summary statistics of invoices') and enumerates the exact aggregates returned: total paid, pending, and overdue amounts. This clearly distinguishes it from listInvoices (raw list) and getInvoiceDetails (single-invoice detail).

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 intended use case is implied by the phrase 'summary statistics of invoices,' but the description does not explicitly say when to use this tool over listInvoices or getInvoiceDetails, nor does it state exclusions. It is adequate but not explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond that: the quote is display-only, not authoritative, and requires authentication. This gives the agent useful behavioral expectations without contradicting the annotations.

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

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

The description is compact and front-loaded with the key purpose. The additional sentences about authoritative price and authentication are relevant and non-redundant. Minor deduction for repeating the tool name at the start.

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 output schema exists and annotations cover safety, the description sufficiently covers purpose, auth requirements, and non-authoritative behavior. It is complete enough for an agent to call the tool correctly, though it could optionally mention that listMailPlans provides valid package IDs.

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?

Input schema coverage is 100%, with each parameter already documented, including term default and packageId source. The description does not add parameter-level meaning, but the schema carries the full burden, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get a display-only price quote for a mailbox plan.' It clearly distinguishes this from other tools like getTransferQuote by scoping it to mailbox plans. The display-only qualifier also clarifies the nature of the result.

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 conveys clear context: this tool is for display-only quoting, requires authentication, and the backend re-derives the authoritative price at purchase. It implies the tool is for pre-purchase previews and not for final pricing, though it does not explicitly name alternative tools or when-not-to-use conditions.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds the authentication requirement, which is useful context not present in annotations, but it does not disclose result shape or behavior on unauthenticated calls. This is acceptable but not rich.

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

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

The description is one concise sentence that front-loads the action and scoping. The redundant 'getMailboxUsage:' prefix is minor and does not meaningfully hurt clarity.

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 low-complexity read-only tool with one optional parameter and complete schema coverage, the description provides enough context: what is returned (per-mailbox bytes), why it is used (quota display), and the auth requirement. It could name the alternative quota tool, but nothing critical is missing.

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

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

Schema description coverage is 100% for the single optional sessionKey parameter, so the schema fully documents the parameter. The description adds no parameter-specific detail, matching the baseline for high schema coverage.

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 clearly states the action (get disk usage), the resource scope (per mailbox), the unit (bytes), and the intended use (quota display alongside the plan's quotaBytes). This makes it readily distinguishable from quota-related siblings like getMailboxQuote.

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 quota display alongside the plan's quotaBytes' implies a use case, but the description does not explicitly state when to prefer this tool over alternatives or when not to use it. Usage context is present but left to inference.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds an explicit authentication requirement and scopes the operation to externally managed DNS setups, which is useful context beyond the structured annotations. No contradictions.

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 sentence that front-loads the purpose, records types, and use context. It starts with a redundant repetition of the tool name, but this is minor and does not detract from readability.

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

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

For a simple read-only lookup, the description covers what records are returned, the qualifying scenario (external DNS), and authentication. No output schema exists, but the sentence adequately indicates return content. It does not discuss output format, which is a minor gap.

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

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

Schema coverage is 100%, so the schema already explains both parameters fully. The description adds no additional parameter-level meaning; it only restates that these are DNS records needed by a mail domain.

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 a precise resource ('DNS records a mail domain needs'), enumerating record types (MX, SPF, DKIM). The 'managing DNS externally' clause also frames why this tool exists, distinguishing it from general DNS-listing tools without naming one.

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

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

The description tells the agent when this tool applies: when customers manage DNS externally and need the required DNS records. It does not explicitly name alternatives like verifyMailDns or listDnsRecords, but the external-DNS context is a clear usage signal.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'Requires authentication', which is useful context, but it does not disclose pagination behavior, ordering, or what 'recent' means. With annotations handling safety, this is adequate but not rich.

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

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

Two short sentences with no filler. The scope is front-loaded and the authentication requirement follows immediately. Every word earns its place.

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

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

For a simple read-only tool with no required parameters and a fully documented schema, the description covers the essential aspects: what it returns (audit logs), scope (user's logs across all services), and a prerequisite (authentication). No output schema exists, so return value details are not expected. The only slight gap is not disambiguating from getRecentActivity, but the scope phrase largely covers this.

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

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

Schema description coverage is 100%, so the schema already documents page, size, and sessionKey. The description adds no additional meaning about parameter usage, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('get'), a clear resource ('audit logs for the authenticated user'), and a scope qualifier ('across all services') that distinguishes it from domain-scoped tools like getDomainAuditTrail. The purpose is immediately understandable.

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 authenticated user across all services' implies when to use this tool, and 'Requires authentication' sets a prerequisite. However, it does not explicitly name alternatives like getDomainAuditTrail or getRecentActivity, nor does it state when NOT to use them.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful context by stating that authentication is required and specifying exactly what account data is exposed, which goes beyond what annotations alone convey.

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

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

The description is a single sentence that front-loads the primary purpose and includes the key usage constraint ('Requires authentication') without any redundant filler.

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

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

For a simple read-only profile getter with one optional parameter fully described in the schema, the description provides enough context: the resource, the fields included, and the authentication requirement. No output schema exists, but the listed fields give a clear expectation of return contents.

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

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

Schema description coverage is 100% for the only parameter, sessionKey, so the schema already documents it fully. The tool description does not add any new parameter-specific details, matching the baseline for high schema coverage.

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 clearly identifies the verb (Get), the resource (authenticated user's profile and account information), and the scope (name, email, organization, balance, domain/VPS counts). This detail differentiates it from siblings like getAccountBalance and getAccountSummary without ambiguity.

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

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

It clearly states the authentication requirement and that this targets the authenticated user's own data, providing useful context. It does not explicitly mention when to prefer a sibling like getAccountBalance, but the scope is specific enough that an agent can infer appropriate 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral context that the data is scoped to the authenticated user and that authentication is required, which goes slightly beyond the structured metadata but does not disclose pagination behavior or response characteristics.

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 focused sentence that immediately names the operation and its scope, followed by a brief authentication note. Every word contributes meaning, and there is no filler or redundant restatement.

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

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

For a simple read-only paginated history tool, the description plus schema and annotations cover the essential invocation context: what it returns conceptually, that it is read-only, and that the caller must be authenticated. The absence of an output schema is acceptable, though a note about the shape of the transaction list could improve completeness.

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

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

Schema description coverage is 100%, and each parameter (page, size, sessionKey) already has a meaningful description in the input schema. The tool description adds no parameter-level detail beyond what the schema provides, so it meets the baseline without adding extra value.

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

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

The description clearly states a specific verb and resource: 'Get payment transaction history for the authenticated user.' This distinguishes it from related billing tools like getAccountBalance or listInvoices in broad terms, though it does not explicitly name or contrast those 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?

The description implies when to use the tool (when payment transaction history is needed for the authenticated user) and states the authentication prerequisite. However, it does not explicitly say when not to use it or mention alternative tools for related financial data, leaving routing partially 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, idempotentHint, and destructiveHint false. The description adds a useful behavioral detail beyond annotations: 'No authentication required.' This helps an agent understand access prerequisites, though it does not describe response shape or potential size.

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

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

The description is two short sentences with no filler. It front-loads the core purpose and includes only the essential additional detail about authentication. 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?

For a simple, parameterless read-only catalog tool, the description is complete: it states what the catalog includes, confirms no authentication is needed, and annotations cover the safety profile. No essential calling information 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, and schema coverage is 100%, so there are no parameter gaps to fill. The description still adds semantic value by enumerating the content categories of the catalog, matching the baseline for a parameterless tool.

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

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

The description clearly states the verb 'Get' and the resource: the complete product catalog, explicitly listing the included categories (domain extensions, VPS packages, dedicated servers). This distinguishes it from more specific siblings like getDedicatedServerCatalog, getDomainExtensions, and listVpsPackages by framing this as the umbrella catalog.

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

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

The description gives context that no authentication is required, but it does not explicitly say when to use this tool versus the more targeted sibling tools. The usage is implied by 'complete product catalog,' but there is no explicit when-not-to-use or alternative routing guidance.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that authentication is required and that the scope spans all domains and services. It does not disclose ordering, recency window, or response shape, but for a simple read-only getter with one optional parameter this is acceptable.

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 that states the operation, scope, and auth requirement without filler. The leading 'getRecentActivity:' prefix repeats the tool name, but it does not meaningfully reduce clarity or conciseness.

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

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

For a read-only, idempotent tool with one optional, well-documented parameter and no nested objects, the description plus schema provides enough to invoke it correctly. The main omissions are the exact output shape and the definition of 'recent,' but these are minor for a tool of this simplicity.

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

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

Schema coverage is 100% for the single optional sessionKey parameter, with detailed format, provenance, and omit-when-OAuth guidance already in the schema. The description itself adds no parameter-level meaning, so the baseline of 3 applies because the schema carries the full burden.

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 uses a specific verb ('Get') and identifies the resource: the most recent activity across all domains and services for the user. The cross-domain/cross-service scope helps separate it from domain-specific getters, but it does not explicitly distinguish it from getMyAuditLogs or other activity-style siblings, leaving some contrast 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?

The only usage guidance is the prerequisite 'Requires authentication.' It does not state when to prefer this tool over getMyAuditLogs, getAccountSummary, or other list-style tools, nor does it specify when not to use it. The description implies general-purpose activity retrieval but gives no explicit alternative routing.

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 communicate read-only, non-destructive, and idempotent behavior. The description adds the authentication requirement and what the call returns, plus the workflow cue that this is a preflight quote before a mutating transfer operation. No contradiction with 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 short sentences, each earning its place: the tool's purpose, its authentication and return behavior, and the exact workflow placement. It is front-loaded with the core action and avoids redundancy with 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?

For a simple quote tool with one required parameter and a rich output schema, this description covers what the tool does, that it requires authentication, what it returns, and when to call it. Nothing essential for correct invocation or selection is missing.

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

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

Schema description coverage is 100%, so the schema fully documents 'domain' and 'sessionKey'. The description does not add parameter-level detail beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb+resource ('Get a transfer price quote for a domain') and clarifies that it returns transfer price, currency, extension years, and new expiration date. This sets it apart from transfer-status and pricing-list siblings by scoping it to the pre-transfer quote step.

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 explicitly states 'Call before initiateTransfer to show the user the cost,' giving clear contextual timing and connecting it to the relevant workflow. It does not list exclusions or compare against alternatives such as getDomainPricing or getTransferStatus, but the sequencing guidance is sufficient for selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing the authentication requirement and summarizing the returned fields (status, request date, current registrar, expected completion), which goes beyond the structured annotations.

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

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

Two sentences with no filler; the core purpose is front-loaded, followed by authentication and return-value highlights. 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?

For a simple read-only status tool with no output schema, the description adequately covers what it returns and the auth requirement. Minor missing context is explicit guidance on error cases (e.g., transfer not found) and positioning relative to listPendingTransfers, but these are not critical for correct invocation.

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

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

Schema coverage is 100%, with both parameters already described in clear detail (domain format and sessionKey usage conditions). The description adds no additional parameter-specific semantics, so the baseline score of 3 is appropriate.

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

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

States a specific verb ('Check') and resource ('current status of a domain transfer'), making the tool's function clear. While it doesn't explicitly distinguish itself from related siblings like listPendingTransfers or getTransferQuote, the name and description make the intent obvious.

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 notes that authentication is required, which is a useful prerequisite, but it does not explain when to choose this tool over alternatives such as listPendingTransfers for a list of transfers or getTransferQuote for pricing. 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 mark the operation as readOnly, idempotent, and non-destructive, so the description only needs to add context beyond that. It adds 'Requires authentication' and 'including resource usage,' but does not cover return format or any rate-limit/pagination behavior; this is still acceptable given the safety annotations.

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

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

A single front-loaded sentence states the action, target, and an extra detail (resource usage) with no filler. The 'getVpsInstanceDetails:' prefix is slightly redundant with the tool name but does not harm clarity.

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

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

For a simple read operation with two well-documented parameters and no output schema, the description gives enough high-level context plus the auth prerequisite. It does not enumerate the returned fields, but 'detailed information... including resource usage' plus annotations are sufficient for correct invocation.

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

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

Schema description coverage is 100%, and the schema already explains instanceId's provenance and the sessionKey's conditional use in detail. The tool description adds no parameter-level meaning, so the baseline 3 applies.

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

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

The description uses the specific verb 'Get detailed information' with a clear resource ('a specific VPS instance') and calls out 'resource usage' as included scope. It does not explicitly differentiate from siblings like getVpsPackageDetails or listMyVpsInstances, but the 'specific instance' framing distinguishes it from listing operations.

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 choose this tool over alternatives such as listMyVpsInstances or getVpsPackageDetails. The only contextual hint is the schema note that instanceId comes from listMyVpsInstances; the description itself gives no usage instructions 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, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral context by stating the authentication requirement and clarifying that the anonymous browsing path is served by listVpsPackages. No contradiction with annotations.

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

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

The description is two sentences with no filler. It front-loads the core purpose, then states the auth requirement and the alternative tool, all in a compact and easily parseable format.

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

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

For a simple read-only detail tool with full schema coverage, the description provides the essential context: purpose, auth requirement, and when to use the sibling listVpsPackages tool. The only minor gap is that no expected response shape is described beyond pricing tiers, but no output schema exists and this is unlikely to block correct invocation.

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

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

Schema description coverage is 100%, so both packageId and sessionKey are well documented in the schema itself. The description does not add additional parameter-level meaning, but it does not need to because the schema already carries the parameter semantics.

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

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

The description uses a specific verb ('Get detailed information') and a specific resource ('a specific VPS package') and explicitly mentions pricing tiers. It also distinguishes itself from listVpsPackages, making the tool's unique purpose clear without requiring schema inspection.

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

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

The description explicitly states that authentication is required and directs anonymous users to listVpsPackages, which already provides per-term pricing. This gives the agent a clear decision rule for selecting this tool versus the sibling tool.

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

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

Beyond the annotations (idempotentHint true, destructiveHint false), the description adds meaningful behavioral context: it is safe on existing zones and will not overwrite records, and it explicitly requires authentication. No contradiction with annotations exists.

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

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

The description is compact and efficient: it front-loads the core action, then gives exclusions, use cases, safety behavior, and auth requirement in short sentences. Every sentence adds useful information without 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 two-parameter create-style tool with complete schema coverage and useful annotations, the description covers the action, when to use it, when not to use it, safety on existing zones, and authentication. There is no significant missing context that would prevent correct invocation.

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

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

Schema description coverage is 100%, and both parameters are already well documented in the input schema. The description adds no additional detail about the domain format or sessionKey semantics, so the schema carries the parameter explanation burden.

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 action ('Initialize (create)') and a clear resource ('the DNS zone for a domain'), and distinguishes it from the automatic initialization that happens with registerDomain. It also makes clear this is about the zone itself, not DNS records, so it will not be confused with createDnsRecord or updateDnsRecord.

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 explicitly states when the tool IS needed ('pre-existing domains without a zone', after transfer, or registration opted out with initializeDnsZone:false) and when it is NOT needed (after registerDomain). This gives an agent actionable routing logic rather than leaving the decision 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses that the action deducts from the account balance, requires authentication, and returns an actionId that must be passed to executeConfirmedAction for approval. This gives the agent essential behavioral context about cost, authentication, and the two-step confirmation flow that annotations alone do not provide.

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

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

The description is compact and front-loaded with the core action, then the key alternative, then the side effects and follow-up step. Every sentence contributes necessary information without repetition or filler.

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

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

There is no output schema, so the description correctly explains the return value (actionId) and the next action required. It also covers prerequisites, the triggering condition, cost, authentication, and the alternative tool. An agent has enough context to call it correctly and complete the confirmation 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 description coverage is 100%, so the schema fully documents all three parameters. The description adds minor context by implying authCode is the code obtained from the losing registrar, but it does not materially expand on the schemas for domain or sessionKey. Baseline 3 is appropriate given the high schema coverage.

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: 'Starts a transfer for a domain already prepared at the losing registrar.' It also explicitly differentiates itself from the sibling transferDomain, which handles staging transfer plus registrant assignment in one step. This disambiguation is strong and immediately actionable.

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 when-to-use guidance: use this tool only when the domain is already unlocked and the auth code is in hand. It names the alternative transferDomain and specifies the condition for choosing it ('when the user gives you contact details'). It also explains the required follow-up step with executeConfirmedAction, leaving no ambiguity about the workflow.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds genuinely useful behavioral context beyond those hints: results are 'unranked candidates,' prices are decimal strings, return fields are named, and 'No auth required' is stated. This meaningfully helps an agent anticipate behavior without contradicting the annotations.

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

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

The description is compact and front-loaded with purpose, then workflow usage, filters, and return shape. The repeated 'listCategorizedTlds:' prefix is slightly redundant, but every remaining sentence earns its place and there is no filler.

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

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

With no output schema, the description appropriately describes the returned shape: unranked candidates with categories, audience, prices, and flags. It also covers auth requirements and optional filters. Minor gaps remain, such as currency and pagination, but none of these block a correct call.

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

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

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description only summarizes them as 'price cap, exclude ccTLDs/restricted/premium, registry,' which adds no semantic depth beyond the schema. This matches the baseline-3 case where structured data carries the load.

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

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

The description opens with a specific verb-resource pair: 'List TLDs from the OSIR catalog that have category and audience metadata.' It clearly distinguishes this catalog-listing tool from pricing/extension tools and explicitly ties it to the bulkDomainSuggestions workflow, so an agent can tell exactly what it does and why it exists.

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 when-to-use guidance: pick 3-6 relevant TLDs before calling bulkDomainSuggestions. It also describes the available filters, which shape usage. It stops short of naming alternative tools to avoid or explicitly excluding other catalog/list tools, so it earns a 4 rather than a 5.

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