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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description reinforces this with 'changes nothing' and adds useful context about order refusal due to insufficient balance, which is not captured by the annotations. This extra context slightly exceeds the baseline given the already-complete 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 of appropriate length. The first sentence front-loads the core purpose, and the second adds essential usage guidance and an alternative reference. There is no unnecessary verbiage; every part 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 operation, the description fully covers what the agent needs to know: what is returned (balance and currency), why it matters (before debiting operations), and how to handle billed amounts. No additional details are required 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?

The schema has zero parameters, and the description explicitly confirms it 'takes no arguments'. While this is redundant with the schema, it provides clear confirmation to the agent, eliminating any ambiguity. Given the perfect schema coverage and the explicit statement, a score above baseline is warranted.

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 ('Returns') and the resource ('the account’s prepaid balance and its currency'). It also distinguishes this tool from sibling eurodns_invoice_get by explicitly noting that billed amounts are handled elsewhere, making its 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?

It gives specific guidance on when to use the tool: 'Read it before any tool described as debiting credit' and explains the consequence of an insufficient balance ('an order is refused'). It also explicitly names an alternative (eurodns_invoice_get) for already-billed amounts, covering both when-to-use and when-not-to-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, openWorldHint, idempotentHint, and destructiveHint=false. The description reinforces this by stating it reads the profile only and never modifies data. No contradictions exist.

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

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

The description is long but densely informative, covering retrieval, listing, filtering, pagination, sorting, and relationships to sibling tools. It avoids filler while sacrificing some brevity for completeness.

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 10 optional parameters and an output schema, the description covers the main decision points: id vs list, filters, pagination, sorting, and relationship to domain contacts. It is complete enough for an agent 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 coverage is 100% with detailed descriptions on every parameter, including pagination, filtering, and sorting semantics. The description adds extra practical notes like 'prefer a filter to a large size' and 'walk pages until a short one comes back', going slightly 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 clearly states the action: return one contact profile by id or list the account's profiles when id is omitted. It also distinguishes itself from sibling tools like eurodns_domain_get and eurodns_contact_save_profile, making its 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 and parameter docs give explicit usage guidance: omit id to list, walk pages until a short one returns, prefer filters to large sizes, and sortOrder is only read with sortField. It also tells the agent to read before saving, providing practical context for when to use the 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?

The description explicitly warns that every call sends mail, highlighting the side-effectful nature. It also states the return of validation state. No contradiction with annotations (readOnlyHint=false, idempotentHint=false).

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 well-organized: action, usage guidance, and identification note. No fluff or redundancy.

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

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

Given the output schema exists, the description covers the return value (validation state), usage conditions, and side effects. No missing critical information for an agent to call this 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 parameter body.contactsDetails is fully described as the list of contacts to send to, with the note that they are identified as returned by eurodns_domain_get. This gives both meaning and source context beyond the raw 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 clearly states the action (sends email), the target (contacts in body.contactsDetails), the content (validation link), and the return (validation state). It distinguishes this tool from siblings by referencing eurodns_domain_get as the source for contact identification.

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 explicit when-to-use guidance ('when a registrant validation is pending or about to expire') and when-not-to-use ('do not use it as a check, since every call sends mail'). This is directly actionable for an agent.

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 critical behaviors: the update clears omitted fields, the operation does not alter existing domain registrations, and it does not set the default profile. This goes well beyond the annotations and gives the agent a full picture of side effects, with no contradiction.

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 with a distinct job: the first states the action and return, the second the crucial update requirement, the third the side effects and distinction from the default-setter. No filler, and the most important operational detail (full-body update) 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?

Given the complexity (nested body, create-vs-update, mutation), the description covers the essential decision points: how to create vs update, what to include in the body, what side effects to expect, and the alternative tool for setting defaults. The output schema handles return details, so nothing an agent needs to call 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 already documents id (omit to create), body (send every field), and lang. The description adds a useful tip to start from get_profile, but it largely repeats the schema's guidance. Since the schema carries the parameter meaning, the description adds marginal extra value, aligning with the baseline of 3.

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 dual action (create when id omitted, update when id provided) and names the resource (contact profile) and the return value. It also implicitly differentiates from siblings like eurodns_contact_get_profile (read) and eurodns_contact_set_as_default_profile (default setting), so an agent can pick it correctly 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 explicitly instructs that updates must carry every field because the API clears omitted ones, and tells the agent to start from eurodns_contact_get_profile's output. It also clarifies when NOT to use this tool (making a profile the default) and that existing domains are unaffected, which routes the agent to the correct alternative.

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, destructive, and idempotency hints. The description adds behavioral context by stating the scope: 'Future orders pick the default; domains already registered are not touched' and that it 'returns the roles now applied'. This clarifies the side-effect scope and return behavior beyond the annotation flags, though it does not detail error cases or authentication requirements, which are not critical here.

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 concise sentences, each serving a purpose: the first states the core function, the second gives behavioral scope, and the third provides usage routing. No filler words; information is front-loaded and efficiently structured.

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

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

For a tool with two parameters, a nested object, and an output schema, the description covers the action, role mapping, effect on future vs existing domains, return value, and how to find the id. It also distinguishes from related tools. Nothing an agent needs to correctly invoke it is missing.

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

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

Schema description coverage is 100%, so both id and body are already described. The description adds value by explaining the role semantics ('org (registrant), admin, tech and billing') and by telling how to obtain the id via eurodns_contact_get_profile. This goes beyond the schema's basic descriptions, enriching the parameter understanding.

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

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

States the specific verb 'Makes' and the resource 'contact profile', and clarifies the exact action: setting the profile as default for selected roles (org, admin, tech, billing). It differentiates from siblings by referencing get_profile and save_profile, so an agent can immediately know this tool is for default-role assignment, not profile editing or retrieval.

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 tells when to use this tool: to set defaults for future orders. It also says what it does not affect (existing domains) and directs the agent to eurodns_contact_get_profile for finding the id and eurodns_contact_save_profile for editing profile fields instead. These clear alternatives and conditions leave no ambiguity about when this tool is appropriate.

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=true and destructiveHint=false, and the description reinforces this by saying 'without saving anything' and 'Nothing is saved.' It adds relevant behavioral context beyond the annotations, though it does not discuss auth or rate limits, which are not central here.

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 purpose, then immediately gives usage guidance and exclusions. Each sentence adds distinct value with no redundant or vague wording.

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 output schema is provided and the description gives enough context about the validation report and the relationship to sibling tools. Since the output schema exists, the description does not need to enumerate return fields, and it covers the necessary operational context.

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?

Both parameters are described with meaningful context: domainName includes an example and hosting note, while body explains it must be the complete zone in the shape returned by eurodns_dns_get_zone. This goes well beyond the parameter names and provides clear semantic guidance.

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

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

The description uses a specific verb ('Validates') and resource ('candidate zone'), and clearly distinguishes this tool from eurodns_dns_save_zone and eurodns_dns_diff_zone by stating what it does and does not do. This makes the tool's 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?

Explicitly instructs to use this tool before eurodns_dns_save_zone because save returns a bare 400 on rejection, and clarifies that previews of changes are handled by eurodns_dns_diff_zone. It also states the required body shape, leaving no ambiguity about when and how 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the 'without saving' claim is redundant. However, the description adds valuable context beyond annotations: it clarifies that this checks a template, not a live zone, and that it returns a per-record report. This enriches the agent's understanding of the tool's behavior without contradicting any 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, front-loaded with the core action and outcome, then usage guidance and differentiation. Every clause earns its place with no fluff. The structure is clear and efficient.

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

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

Given the tool's purpose (validation before save), the input schema is comprehensive, and an output schema is present, the description covers the essential context: what it does, what it doesn't do, and when to use it. Nothing an agent needs to correctly invoke this 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%, so all parameters already have detailed descriptions. The description mentions the main fields (name, records, urlForwards, mailForwards) but doesn't add anything about their formats or constraints beyond what the schema provides. Since coverage is high, the baseline of 3 is appropriate; the description adds marginal 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 uses a specific verb ('Validates') and resource ('candidate zone profile in body') and enumerates the exact components checked (name, records, urlForwards, mailForwards). It clearly distinguishes from siblings by naming eurodns_dns_save_zone_profile and eurodns_dns_check_zone as alternatives, so an agent can tell them apart immediately.

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

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

Explicitly states when to use: 'before eurodns_dns_save_zone_profile' and explains why (its rejection is a bare 400). It also gives a clear exclusion: 'for a zone use eurodns_dns_check_zone instead.' This provides both positive and negative usage guidance with named 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?

The annotations already mark the operation as destructive, open-world, and idempotent. The description goes beyond these by detailing the exact rejection behavior for ambiguous and locked records, and clarifying that recordId supersedes type and host. 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 compact, uses parallel structure, and packs essential usage details without redundancy. Each sentence adds distinct information: primary action, disambiguation rule, and guidance to consult sibling tools.

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 annotations (destructive, open-world, idempotent) and the schema (full parameter coverage), the description completes the picture by explaining failure modes and the recommended workflow. An agent has enough context to call this tool correctly and safely.

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

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

The schema covers all five parameters with detailed descriptions, including requirements ('Required without recordId') and enums for type. The description reinforces the meaning of rdata as an exact current value and clarifies the apex representation, adding value 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 clearly states the tool deletes a DNS record from a zone, specifies the two identification methods (recordId or type+host), and names the sibling tools for reading and bulk updates. It fully distinguishes this from eurodns_dns_get_zone and eurodns_dns_save_zone.

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

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

The description explicitly advises reading the zone first with eurodns_dns_get_zone, explains when rdata is needed for disambiguation, and contrasts with mass removal via eurodns_dns_save_zone. It also explains rejection of ambiguous or locked records, giving clear usage 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?

Beyond the annotations (destructiveHint, idempotentHint), the description adds important behavioral context: deletion is permanent, there is no snapshot to restore from, already-created zones keep their records, and it recommends a pre-check with the get tool. These details substantially inform the agent about side effects and risks.

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, tightly packed with purpose, consequences, and guidance. No redundant phrasing or unnecessary details; every sentence adds 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 simple delete operation with a single parameter and no output schema, the description covers all essential context: what is deleted, what happens to dependent zones, the permanence, the recommended pre-check, and the alternative tool. This is sufficient for an agent to use it correctly.

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

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

The input schema already fully describes the single parameter 'id' with type and provenance (from the list returned by eurodns_dns_get_zone_profile). The tool description does not add further parameter-specific meaning, so the score rests at 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 explicitly states that the tool deletes a zone profile permanently and returns nothing on success, clearly identifying the action and result. It also distinguishes from related tools by naming eurodns_dns_save_zone_profile as the alternative for changes, so an agent can easily tell what this 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?

The description gives explicit guidance on when to use this tool versus alternatives: it recommends confirming the id and contents with eurodns_dns_get_zone_profile first, and instructs to use eurodns_dns_save_zone_profile for modifications instead of deletion. This makes the appropriate usage 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?

The description reinforces the readOnlyHint annotation by stating 'without writing anything' and details what the output includes (added, updated, unchanged). While it doesn't explicitly address the openWorldHint or idempotentHint, the behavior is clear enough and consistent with the annotations. No contradictions found.

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

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

The description is extremely concise, consisting of two sentences that pack all essential information without any redundant phrases. It front-loads the core purpose and then distinguishes from the validator tool, making it easy 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?

Given the tool's simplicity (two parameters, no nested objects) and the presence of output schema information (though not shown), the description sufficiently covers what an agent needs to know: it performs a diff, is read-only, and is intended as a dry-run before upsert. The only minor gap is the lack of explicit detail on return format, but the description's mention of 'added, updated, and unchanged' adequately communicates the output.

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

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

Schema coverage is 100% and the description adds clarity to both parameters: domainName is 'Zone to compare against, e.g. example.com' and records are 'Records the caller intends to end up with.' The phrase 'intends to end up with' clarifies the diff semantics beyond the raw schema, earning a score above 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 clearly states the tool's function as a read-only diff: 'Reports what would change if records were applied to the zone domainName — added, updated with old and new values, and unchanged — without writing anything.' It distinguishes itself from sibling tools like eurodns_dns_get_zone (retrieve), eurodns_dns_save_zone (write), and eurodns_dns_upsert_record (modify) by emphasizing it does not write.

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 advises when to use it: 'Use it to review a change before making it with eurodns_dns_upsert_record,' and when not to: 'It is not the API’s validator: for a per-record validity report on a full zone document use eurodns_dns_check_zone instead.' This provides clear guidance for an agent choosing between similar tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, non-mutating operation. The description adds value by clarifying the tool reports only the hosted zone's DNSSEC state, not the registry's publication, and frames its use for verification. It does not contradict annotations and adds contextual nuance beyond the structured fields.

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 well-structured, leading with the core function, then usage guidance, then a caveat about scope. Each sentence contributes value without redundancy. It is slightly longer than the bare minimum but every clause earns its place, so it is appropriately sized and 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?

Given the tool has one parameter, a clear output schema, and annotations that establish its read-only and idempotent nature, the description is fully adequate. It covers purpose, usage timing, and a key limitation (registry scope). An agent has everything needed to invoke it correctly and interpret results without ambiguity.

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 sole parameter, domainName, is fully described in the schema ('Name of the zone, e.g. example.com: a domain whose DNS is hosted here.'). With 100% schema description coverage, the baseline is 3. The description only restates that it operates on the zone of domainName, adding no substantive new semantics beyond the schema. It meets the baseline but does not exceed it.

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

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

The description clearly states the tool returns whether a zone is DNSSEC-signed, along with keys and DS data, using a specific verb ('returns') and resource (DNSSEC status of a zone). It explicitly distinguishes itself from siblings like eurodns_domain_set_dnssec (which sets DNSSEC) and eurodns_dns_get_zone (general zone retrieval) by focusing on DNSSEC status and verification. The scope limitation (only reports hosted zone, not registry) further differentiates it from a generic registry 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?

The description provides explicit guidance on when to use it: 'Read it before and after eurodns_domain_set_dnssec, and again after moving nameservers, to confirm the zone and the registry agree.' It also specifies a when-not scenario: for domains registered elsewhere, it advises checking the registrar separately rather than trusting this tool. This clearly routes the agent to the correct usage and alternative.

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 and idempotent annotations, the description discloses that the zone is 'live' (not a snapshot), specifies the 404 error condition, and lists exactly what data is returned, adding behavioral detail.

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 informative without being bloated. It front-loads the core purpose, then provides actionable usage guidance and contrasts with related tools, all in a well-organized 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 get operation, the description covers the purpose, expected inputs, error cases, and relationship to sibling tools. It also enumerates the returned data fields, making it self-contained for an agent.

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

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

The schema covers the single parameter with 100% coverage, and the description enhances it with an example and clarifies that the domain must be hosted by this service. This adds semantic value beyond the bare schema.

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

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

Clearly states that the tool returns the full live DNS zone for a domain, listing record fields and additional data like URL and mail forwards. This distinguishes it from other operations like save or upsert.

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 advises reading the zone before any change, for finding record IDs for deletion, and contrasts with upsert for single-record changes and save_zone for full-zone replacement. Also notes the 404 case for unhosted domains.

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 meaningful behaviors beyond the annotations, such as the 404 response for a nonexistent id, pagination walk behavior, and the truncation risk with wide pages. Combined with the readOnly, idempotent, and non-destructive annotations, the agent can fully predict side effects.

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 well-organized, packing purpose, variants, usage guidance, and edge-case behavior into a compact form. Every sentence adds practical value without redundancy or fluff.

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 moderate complexity of a paginated fetch-or-list tool, the description covers all essential context: resource semantics, live-zone alternative, save-profile prerequisite, pagination behavior, sort constraints, and error behavior. Nothing important 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?

The input schema already covers all parameters with high-quality descriptions, so the baseline is strong. The description adds useful caveats beyond the schema, such as sortOrder only being read with sortField, and the recommendation to prefer filters over large page sizes due to character-limit truncation.

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's dual purpose: return one zone profile by id, or list the account's profiles filtered by name and paged when id is omitted. It also specifies the resource type (zone profiles) and distinguishes them from live zones.

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 says profiles are templates, not live zones, and directs users to eurodns_dns_get_zone for live zone records. It also advises reading a profile before calling eurodns_dns_save_zone_profile, giving clear when-to-use guidance relative to sibling 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 indicate read-only, but the description adds nuance: it clarifies that omitting id lists snapshots, and it warns against replacing the zone, enriching behavioral context beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary action, and avoids redundancy. It efficiently packs purpose and usage guidance without unnecessary detail.

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

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

Given the tool's simple two-parameter interface and the presence of an output schema, the description covers all necessary behavioral aspects, including the optional id behavior and relationship to other DNS operations.

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

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

Schema descriptions fully cover both parameters (domainName and id) with adequate detail. The tool description repeats similar information without adding new meaning, so it adds little beyond the schema.

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

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

The description clearly states the tool returns a snapshot or lists snapshots for a zone, with the verb 'Returns' and 'lists'. It distinguishes from siblings by emphasizing read-only behavior and contrasts with restore 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?

It explicitly instructs to use this tool for viewing historical zone states and points to save_zone or upsert_record for restoring, providing clear when-to-use and 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?

The description contradicts the annotation destructiveHint=false by stating 'Every record, URL forward and mail forward absent from body is deleted.' This is a destructive side effect that the annotation denies, so the description conflicts with the provided metadata.

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 dense yet efficient paragraph. It front-loads the primary purpose, then each subsequent sentence adds crucial guidance (deletion behavior, alternative tool, validation workflow, rdata convention) without redundancy.

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

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

Given the complex nested body schema, the description supplies all necessary context: how to obtain the complete zone (get_zone), what happens to omitted records, when to use upsert_record instead, the benefit of running check_zone first, and the rdata field convention. The output schema is also 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?

The body parameter description adds critical meaning beyond the schema: 'The complete zone as returned by eurodns_dns_get_zone, with your changes applied: records, urlForwards and mailForwards. Anything left out is deleted; record values go in rdata.' This clarifies the expected payload and deletion semantics. The domainName description provides a concrete example.

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

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

The description states a specific verb and resource: 'Replaces the entire zone of domainName with body and returns the saved zone.' It also distinguishes from siblings by referencing eurodns_dns_upsert_record and eurodns_dns_get_zone, making the tool's role clear.

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

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

Provides explicit when-to-use guidance: 'to change one record use eurodns_dns_upsert_record instead, which validates and keeps the rest' and 'Run eurodns_dns_check_zone first: a rejected save answers a generic 400, while the check names the offending record.' This clearly contrasts with related 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?

The description states that on replace, every record absent from body is dropped, which is a destructive action. However, the annotation destructiveHint is false, contradicting this. The description does not explicitly say it is destructive, but the effect is destructive, and the annotation suggests otherwise. This is a clear contradiction, so the score is 1.

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 four sentences, compact and front-loaded. It immediately states the create/replace distinction, then covers the critical replace behavior, validation advice, and error nuance. No filler or redundant repetition; 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?

Given the complexity of the operation (nested objects, replace semantics) and that an output schema exists, the description covers the critical pitfalls: how to safely replace, how to validate, and the error response behavior. It also names the sibling tools to use. Nothing an agent needs to call 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?

The schema descriptions for id and body are already detailed (100% coverage). id explains it comes from get_zone_profile and that omitting creates a new profile; body describes the profile structure and the destructive replace behavior. The tool description adds the note about rdata, but this is also in the schema. The description adds little beyond the schema, so a 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 creates a zone profile when id is omitted and replaces the profile with that id otherwise, and returns the saved profile. It explicitly distinguishes from get (read) and check (validate) via sibling references, so the agent can easily 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?

It gives explicit guidance: start from the full profile returned by eurodns_dns_get_zone_profile when replacing, because absent records are dropped. It also advises validating with eurodns_dns_check_zone_profile to get precise error names, since a rejected save only returns 400. This tells the agent exactly when to use this tool and when to use 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?

Given the annotations (readOnlyHint: false, destructiveHint: false, idempotentHint: true, openWorldHint: true), the description goes beyond the annotations by explaining that the tool reads the zone, applies the change, validates, and only writes if validation passes. It also states that a rejected change writes nothing, which is a key behavioral detail not covered by 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 concise yet comprehensive—four sentences covering purpose, alternative guidance, special-case parameters, and validation behavior. Every sentence adds value, and the structure front-loads the primary action before discussing edge cases.

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 tool's moderate complexity (7 parameters, 4 required, enums, and both append and matchRdata special cases), the description provides all necessary context: what the tool does, how it differs from siblings, when to use advanced parameters, and the validation/write behavior. The presence of an output schema covers return format, and the description fills the remaining gaps for successful 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?

The schema already has 100% parameter description coverage, and the tool description adds extra meaning beyond the schema, such as clarifying that the API field is 'rdata' not 'data', explaining when to use matchRdata for multiple records sharing a type and host, and specifying the behavior of append. This significantly aids in correct parameter usage.

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 adds or updates a single DNS record and returns the saved record with the action taken. It distinguishes itself from the sibling tool save_zone by explicitly noting it replaces the whole zone, and from delete_record by implying record-level modification. The verb and resource are specific 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 explicitly says 'Prefer it over eurodns_dns_save_zone, which replaces the whole zone', giving direct guidance on when to use this tool instead of an alternative. It also explains when to use append (add a second record with same type/host) and matchRdata (update a specific record among several) which are conditional usage instructions.

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 that the call reads only and reserves nothing, that results reflect how registries answer, and that availability here does not imply ordering capability. These are meaningful behavioral disclosures not present in the readOnlyHint/openWorldHint/destructiveHint annotations.

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

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

Three sentences deliver the core action, the alternative tool condition, and the key limitation, all without redundancy. The primary behavior 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?

With an output schema present and annotations covering the read-only/open-world safety profile, the description supplies the remaining decision-relevant context: what to check, when to use it, when not to, and what an available result means. 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 coverage is 100%, and the schema already describes body.domainNames as fully qualified names with an example. The description references the same parameter without adding extra syntax or constraints, so the schema carries the semantic weight.

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: it checks whether domain names in body.domainNames can be registered and returns per-name availability. It also distinguishes itself from eurodns_domain_get, so an agent can tell this availability-check tool apart from the full-record lookup tool.

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

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

The description explicitly says to use it for names not held in the account and directs the agent to eurodns_domain_get instead for domains already in the account. It also clarifies that this server does not register domains, so an available name must be ordered elsewhere, leaving no ambiguity about when this tool is appropriate.

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

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

Annotations already declare this as read-only and idempotent, so the safety profile is covered. The description adds genuinely useful behavior beyond that: unknown names return 404 rather than availability, omitting domainName switches from exact get to search, and a search without filters returns the entire portfolio. There is 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?

The description is three sentences, front-loaded with the primary behavior, then the alternative tool, then search and paging behavior. Every sentence carries operational value with no filler 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?

With an output schema and safety annotations already present, the description covers everything an agent needs: exact get mode, search mode, filter and paging references, no-criteria behavior, and the 404 case. It does not need to explain return values because the output schema supplies 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 detailed parameter descriptions already carry the main semantic load. The description does clarify that domainName selects exact-get mode while body, page, and size drive search mode, but that grouping is already stated in the schema, so it adds no substantial new parameter meaning.

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

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

The description names a specific verb and resource: it returns one registered account domain with status, expiry, renewal method, contacts, and nameservers when domainName is given, or searches the account's domains when it is omitted. It also explicitly distinguishes itself from eurodns_domain_check_availability, which prevents an agent from confusing lookup of held domains with availability checks.

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 when-to-use route: if a name might not be held yet, use eurodns_domain_check_availability instead, because this tool answers 404 for unknown names. It also explains that a search without criteria lists the whole portfolio, which is the intended way to find a name you do not know exactly.

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 side effects: signing the zone, publishing DS records, and the risk of breaking validation if only one side is disabled. It also states that the call returns nothing, complementing annotations that indicate this is a non-read-only, non-idempotent, non-destructive operation.

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

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

The description is information-dense without being verbose. It packs scope distinction, prerequisites, side effects, and a warning into a few sentences, each earning 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 fully explains the operation, when to use each scope, what changes occur, what to check before and after, and the return behavior. This is complete for an agent to decide when and how to call it safely.

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

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

The schema already covers all parameters at 100%, and the description adds meaningful context for each: scope clarifies registry vs. zone behavior, enabled clarifies true/false meaning, and domainName specifies fully qualified format and how to find the value via eurodns_domain_get.

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 enables or disables DNSSEC for a domain in one of two scopes, with a specific verb and resource. It distinguishes itself from sibling tools by focusing on setting DNSSEC state rather than checking or managing DNS zones.

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 explains when to use registry scope versus zone scope, including the prerequisite of the domain being registered elsewhere for zone scope. It also advises checking eurodns_dns_get_dnssec_status before and after, which is directly relevant sibling tool 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?

Although the annotations already indicate destructive and non-idempotent behavior, the description adds specific context that removing an alias causes mail sent to it to bounce. This extra detail helps the agent understand the real-world consequence of the action.

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 concise and well-structured—two sentences cover the core action, return value, usage context, and alternative. Parameter descriptions are compact and informative without unnecessary detail.

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

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

Given the full input schema, output schema presence, and sibling context, the description provides all necessary information for an agent to call the tool correctly. No critical details are 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?

All three parameters are documented with meaningful descriptions: id explains its origin from subscription_get, alias includes an example format, and action explicitly maps 'add' and 'remove' to create/delete behavior. The schema coverage is complete.

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 adds or removes an alias address for a mailbox and returns the updated subscription. It also explicitly differentiates from the catchall sibling by noting its use case for one named extra address.

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 one named extra address) and when to use the alternative (eurodns_email_set_catchall for every unknown address). This gives the agent clear selection guidance.

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

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

Annotations already flag readOnlyHint=false, idempotentHint=true, and destructiveHint=true; the description adds meaningful behavioral context by explaining that enabling routes addresses without a mailbox/alias to this subscription and may attract unsolicited mail, while disabling refuses such mail. It 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?

Four sentences, front-loaded with the primary action and return value, followed by behavioral effect, alternative, and id source. Slightly wordy and awkward in the middle sentence, but no wasted sentences.

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

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

Together with the complete input schema and output schema, the description gives enough context to select and call the tool correctly: action, routing behavior, alternative tool, and source of the id. It does not need to explain return shape because output schema exists.

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

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

Schema coverage is 100% and the schema already documents id as the numeric email subscription id from eurodns_subscription_get and enabled as true/false behavior. The description mostly restates these semantics rather than adding new parameter-level meaning.

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

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

States a specific action (turns catch-all on/off) on a specific resource (email subscription id), describes the returned updated subscription, and distinguishes itself from the sibling eurodns_email_set_alias by naming the alternative for named addresses.

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 explicit when-to-use context for enabling/disabling the catch-all and an explicit exclusion: use eurodns_email_set_alias for a single named address. It also tells the caller where the subscription id comes from via eurodns_subscription_get.

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 beyond the annotations by noting the value is written straight through to the provider and is never stored or logged. This adds meaningful context about data handling. The annotations already cover readOnly/destructive/idempotent hints, so the extra detail is a bonus.

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 information-dense, consisting of two sentences that cover purpose, usage, and key caveats. No unnecessary words or redundant details 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?

Given the moderate complexity, the description covers all necessary aspects: how to retrieve the identifier, what the body should contain, the behavior (write-through, no logging), and the result (returns updated subscription). The output schema is available, and the description mentions the returned object adequately.

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

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

The schema fully describes both parameters, and the description enriches it by explaining that password and passwordConfirmation must be identical and that the value is sent to the provider without being stored or logged. This gives the agent more information than the raw schema alone.

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 sets a new password on the mailbox of the email subscription, using body.password and body.passwordConfirmation. It distinguishes itself from sibling tools like eurodns_email_set_alias and eurodns_email_set_catchall by focusing on password updates.

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 explains when to use the tool (to change an email subscription password) and provides guidance on finding the id via eurodns_subscription_get. It also names the alternative for changing addresses (eurodns_email_set_alias), giving clear context for choosing among similar operations.

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 the key behavioral nuance that filters are ignored when id is given and that results are paged. It doesn't contradict annotations, and the output schema covers return details.

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

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

Three sentences with zero filler. The main action is front-loaded, followed by the search filters, then a usage note, and finally pointers to siblings. 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 complex dual-mode tool with 14 parameters, the description clearly explains both modes, pagination, and explicitly routes related data to other tools. With an output schema present, an agent has everything needed to decide when and how to call this 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%, so the schema already documents all parameters. The description adds the context that filters apply only when id is omitted, which is also implied by the schema's id description. It doesn't significantly enhance parameter understanding beyond what the schema provides, so a 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?

States a specific verb and resource: 'Returns one invoice with its lines by id, or searches invoices when id is omitted'. It distinguishes itself from siblings by explicitly pointing to eurodns_order_get and eurodns_invoice_profile_get for related data, so an agent can tell it apart without opening 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?

Explicitly says when to use it ('Use it for what was billed and whether it is paid') and what it is not for (order behind a line and billing identity are in other tools). It also clarifies that filters are ignored when id is given, guiding the agent on parameter 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?

The description is consistent with the readOnlyHint, openWorldHint, and idempotentHint annotations, and clearly bounds the operation to returning or searching profiles. It adds helpful context about inactive profiles and chaining to invoice_get, though it does not describe error behavior or edge cases for invalid ids, which are covered only partially by 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 information-dense, with no obvious filler. It is somewhat run-on with multiple clauses, but every clause adds relevant context about the tool's purpose, usage, and filtering behavior, so it remains effective and focused.

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 15 optional parameters and existing output schema, the description provides sufficient orientation: it covers the main read/search modes, pagination guidance, the key filter fields, and the integration with eurodns_invoice_get. It does not elaborate on sorting or every filter field, but the rich schema descriptions fill those gaps, making the overall context adequately complete.

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

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

The schema already provides full descriptions for all 15 parameters, so the baseline is high. The description adds semantic value by explaining the id-versus-filter mode, the meaning of termMatchingMode, and the relationship between profile id and invoice retrieval, which helps clarify the most important parameters 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 clearly states the tool returns one invoice profile by id or searches account profiles with filters and pagination. It distinguishes itself from related tools by explicitly pointing to eurodns_invoice_get for retrieving invoices and noting that invoices themselves are not returned here.

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

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

The description explains when to use the tool: to fetch a single profile by id or search profiles by fields, and then pass the id to eurodns_invoice_get. It also gives negative guidance ('the invoices themselves are not here') and clarifies that filtering is preferred over large page sizes via schema descriptions, making the usage path 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?

The description supplements the readOnlyHint annotation by explaining pagination behavior ('walk pages until a short one comes back') and the truncation effect of wide pages. It does not contradict the annotations, which already cover read-only and idempotent semantics. It adds useful detail about response shape without repeating the annotation flags.

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 and front-loads the core purpose before adding usage and filtering guidance. It is somewhat talkative with commas and parentheticals but remains scannable and every clause carries meaning. It earns a high score for being compact while dense with decision-relevant information.

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

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

With 8 optional parameters and no required ones, the description covers the core decision points: when to use this versus the save counterpart, how to filter, and how pagination behaves. There is an output schema, so return value details do not need to be in the description. The description adequately guides an agent through the main usage scenarios without needing to enumerate every parameter.

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 adds only marginal value beyond the schema: it explains the task-level intent (find the profile a domain points at) but does not clarify parameter interactions beyond what the schema already states. The parameter descriptions themselves are already thorough, so the description does not need to add much.

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 resource: reusable nameserver sets/profiles. It distinguishes the singular (get by id) from the plural (list all) behavior, and explicitly names the sibling tool eurodns_nameserver_save_profile as the counterpart. The verb 'Returns' and the resource 'nameserver profiles' are both precise and specific.

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

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

The description gives direct usage guidance: use it to find the profile a domain should point at, or the id that save_profile takes. It also explicitly notes what this tool does NOT tell you (which profile a domain uses, directing to eurodns_domain_get), which is especially valuable for disambiguation. It additionally recommends filters over paging.

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 warns that the API clears any omitted nameservers and that changing a profile affects delegation for all domain pointing at it. This is destructive behavior, but the annotations declare destructiveHint: false, creating a direct contradiction.

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 concise and well structured: purpose first, then critical update behavior, then side-effect warning. Every sentence adds 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?

Given the nested nameserver structure and create/update semantics, the description covers what the tool does, how to construct an update, and an important side effect. It also states the return value is the saved profile.

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 explains the body shape, nameservers with fqdn and glue-record IPs, and the update-clearing behavior. It does not explain canDelete or defaultProfile, but overall adds meaningful parameter semantics beyond the raw 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 clearly states the tool creates or updates a nameserver profile and returns the saved profile. It names the resource and the create/update behavior, making it easy to distinguish from related tools.

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

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

It gives concrete guidance for updates: start from eurodns_nameserver_get_profile and send every field you keep. It does not explicitly enumerate alternatives for creation, but the create/update distinction is 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 establish the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context: id changes the operation from search to single-order fetch, filters are ignored when id is present, and results are paged. This goes beyond the structured annotations without contradicting them.

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 front-load the primary behavior, then add a practical use case and a sibling-tool pointer. Every sentence contributes information, with no repetition of schema 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?

Given the rich input schema, output schema, and comprehensive annotations, the description covers the essential decision points: single-get versus search, filter behavior, pagination, and where to find invoices. Nothing critical for invoking the tool 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%, so the baseline is 3. The description adds meaningful semantic value by explaining that filters are ignored when id is given, grouping the search parameters, and clarifying pagination behavior. It also distinguishes order lines from invoices, helping the agent understand the domain model.

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 that the tool returns one order with its lines and delivery status by id, or searches orders when id is omitted. It also differentiates itself from eurodns_invoice_get, making its scope unambiguous among the sibling 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?

It gives an explicit use case ('learn what happened to a subscription that was ordered but never became active') and states when filters apply versus when they are ignored. It also directs invoice-related needs to eurodns_invoice_get, providing a clear alternative.

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 read-only, idempotent, and non-destructive behavior. The description adds 'It alters nothing upstream' and clarifies the return count, providing useful additional behavioral context without contradicting 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 concise, well-structured, and front-loaded with the primary action and purpose. Every sentence 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?

Given the zero-parameter schema, the description fully covers what the tool does, when to use it, what it returns, and how it differs from a similar sibling tool. No important context 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 no parameters and the schema coverage is complete (empty properties), so the baseline of 4 applies. No additional parameter explanation is needed.

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's specific action ('Re-reads the account’s domain list'), its purpose ('backs name completion'), and its return value ('returns how many domains were loaded'). It also distinguishes itself from the sibling tool eurodns_domain_get.

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

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

Explicit guidance is provided: use it 'right after such a change' and not as a way to list domains, with the alternative tool explicitly named (eurodns_domain_get called without a domainName).

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 read-only, idempotent, and non-destructive behavior. The description adds context about the returned certificate contents without contradicting the annotations, but does not elaborate on other behaviors like error cases or side effects beyond what is implied.

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 somewhat verbose and repetitive, particularly the second sentence which reiterates the source of the IDs. It conveys necessary information but could be more concise without losing 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?

Given that an output schema exists, the description appropriately focuses on input sourcing and differentiation. It covers the essential context for using the tool correctly, including where to obtain IDs and what it does not handle (validation). The only minor gap is not explicitly stating that the output schema describes the return format, but that is implied by the existence of the output schema.

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

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

Schema covers 100% of parameters with descriptive text about their source and meaning. The description repeats the schema information without adding new semantic details, so it stays at the baseline score for full 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?

Clearly states the tool returns a single certificate with specific fields (common name, SANs, validity, status, certificate), and distinguishes it from sibling tools like validation retrieval. The verb 'Returns' is specific and the resource 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?

Explicitly instructs that both IDs come from eurodns_subscription_get for SSL products, and clarifies that validation status is handled by eurodns_ssl_get_validation, providing clear when-to-use guidance and differentiation from related 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?

The annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description reinforces that this call 'sends nothing' and only returns validation state, aligning with annotations without contradiction.

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 concise and well-structured, with the primary purpose stated first and supplementary guidance included naturally. Every sentence adds useful context without redundancy.

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

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

The description sufficiently explains when to use the tool and what it returns, and the output schema exists to describe the result structure. It does not detail all possible validation states, but this is not critical given the output schema and read-only nature.

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 have descriptions providing source context (from subscription_get or certificate list) and type details. The schema coverage is 100%, and the descriptions clarify how to obtain the IDs, though they rely on referencing other tool outputs.

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 returns validation details for a specific certificate name, including method, approver address, and token/record to publish. It also distinguishes this read operation from update and resend actions.

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 advises using this tool when an ordered certificate has not been issued, and mentions alternatives for changing the approver or resending email. It does not exhaustively list all alternate tools, but provides clear context for the primary use case.

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

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

Annotations already mark this as a mutating, non-destructive operation. The description adds material behavior beyond that: no charge is made, the subscription term does not move, SAN entries are re-validated, and the tool returns the new certificate. These are important operational facts not visible in 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 four sentences, front-loaded with the core action and key parameters, then adds behavioral caveats about charge, term, and validation. It is information-dense but each sentence earns its place; slightly dense phrasing keeps it from a 5.

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

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

For a three-parameter mutation with a nested body and an output schema, the description covers the trigger scenario, id provenance, validation follow-up, commercial impact, and return value. Nothing an agent needs to decide whether to invoke it or how 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 coverage is 100%, and the schema already documents all three parameters in detail, including the nested body fields and the origin of both ids. The description reinforces this with usage context but adds little semantic meaning beyond what the schema already provides, 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?

States a specific action verb ('Reissues') with the exact resource (certificateId of SSL subscription) and input (body.encodedCsr). It explicitly contrasts reissue with a paid renewal, which distinguishes it from related SSL lifecycle operations like renewal or validation updates.

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

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

Gives a concrete use case ('after a key rotation'), explicitly says extending the term is a separate paid renewal rather than a reissue, and directs the agent to eurodns_subscription_get for ids and eurodns_ssl_get_validation for the validation flow. This is strong when-vs-when-not 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 idempotentHint=false and destructiveHint=false. The description adds the concrete behavior 'every call sends another', which reinforces the non-idempotent nature and warns against misuse. It also states 'returns nothing on success', which is useful beyond annotations. It doesn't cover potential failure modes or rate limits, but for a simple action this is adequate; the description adds context 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?

Two sentences pack the core action, usage conditions, exclusions, and alternative tools with zero fluff. The essential action is front-loaded, and each clause earns its place. No redundancy.

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

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

For a simple resend action, the description covers what it does, when to use it, what it returns, and how to handle the wrong-address case. It also references the sibling for state checking. Given the presence of an output schema (not shown) and the annotations covering safety, the description is complete enough 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?

The schema has 100% coverage with rich descriptions (e.g., 'exactly as it appears on the certificate' and provenance from sibling tools). The description merely restates the parameter names without adding new semantic details. Since the schema already does the heavy lifting, 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 opens with a specific verb and resource: 'Sends the validation email for the name sanName of certificate certificateId, in SSL subscription subscriptionId, to its approver again'. It clearly identifies the action and parameters. It also distinguishes itself from sibling tools like eurodns_ssl_get_validation and eurodns_ssl_update_validation_approver by naming them, so an agent can 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 gives explicit when-to-use: 'Use it when the approver did not receive the first mail'. It also gives when-not-to-use: 'do not use it to check the state' and points to the correct alternative for state checking (eurodns_ssl_get_validation) and for fixing a wrong address (eurodns_ssl_update_validation_approver). This is textbook usage 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?

The description states that it changes the validation and returns the updated validation, matching the non-read-only annotation. It also mentions refusal of unapproved addresses, which adds useful behavioral context beyond the annotations, though it does not elaborate on all possible side effects.

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 fairly concise and front-loads the main action and object. The phrase 'from body.verificationMethod and the approver it names' is slightly awkward and could be clearer, but it does not add unnecessary length.

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

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

The description, combined with the fully covered schema and sibling-tool references, gives enough context to call the tool correctly. It mentions return value, accepted input sources, and directs to related operations when alternative actions are 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?

Every parameter is described with source and meaning: subscriptionId and certificateId explain where to obtain them, sanName gives an example, and the nested body explains verificationMethod and the approver constraint. The enum values for verificationMethod are also explained in the schema 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 clearly states the verb 'Changes' and specifies the resource: validation method or approver address for a SAN of a certificate in an SSL subscription. It also distinguishes itself from the related resend operation, making the tool's 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?

It explicitly says when to use the tool ('when the current approver cannot receive the email'), states the constraint that only addresses from eurodns_ssl_get_validation are accepted, and directs users to eurodns_ssl_resend_approver_email for the lost-mail case. This provides clear decision 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?

The description states it reads records only and manages nothing behind them, aligning with readOnlyHint and destructiveHint false. It also discloses that an id without product is refused, filters marked for another product are ignored, and wide pages are truncated, giving clear expectations about side effects and boundaries.

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 efficiently structured: it front-loads the core behavior, then gives a usage strategy, then covers constraints and edge cases. Every sentence contributes meaningful information without fluff 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?

Given the rich input schema and annotations, the description covers all necessary operational details: pagination semantics, sorting, product-specific filters, cross-product filtering, id uniqueness, and the character-limit truncation caveat. There is no obvious gap that would prevent an agent from using 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?

While the schema descriptions are already detailed, the tool description adds crucial semantic context: ids are only unique within a product, certain filters are product-specific or ignored in other modes, and subscriptionTypes is ignored when a product is given. This goes well beyond the baseline and clarifies ambiguous 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 clearly states the three modes of operation — fetch one subscription with product and id, list one product's subscriptions with product alone, or search across every product when both are omitted — and gives concrete examples of what each subscription type contains. It fully distinguishes this read operation from the many sibling 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?

It explicitly recommends starting with the cross-product search for an expiry review and then narrowing by product, which is actionable guidance. It also notes which filters apply to which product searches and warns about pagination and character-limit truncation, so an agent knows how to use the tool 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: the list can be very large, results are pageable, omitting id switches to list mode, and the tool says nothing about domain availability.

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 sentences with no filler, front-loads the core behavior, and each sentence earns its place: what it returns, when to use it, and what it explicitly does not do. The sibling reference is tightly interwoven rather than bolted on.

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 list/get tool with a rich input schema and an output schema, the description covers the essential decision points: how to get one vs. many, how to avoid overwhelming responses, and what it cannot tell you. No critical contextual gap remains.

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 description coverage is 100%, so the schema already explains all six parameters clearly. The description does add strategic emphasis around id omission, tldName filtering, and paging, but it does not add significant semantic detail that the schema lacks, 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 names a specific verb (Returns/lists), a clear resource (TLDs), and the conditional behavior based on whether id is provided. It also explicitly names the sibling tool it is not, eurodns_domain_check_availability, so an agent can immediately distinguish the two without inspecting 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 gives explicit usage context: read this before ordering an unfamiliar extension to learn registry requirements. It also warns against asking for the entire list and recommends filtering by tldName or paging with size, and explicitly routes availability questions to eurodns_domain_check_availability.

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