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

Beyond the annotations, the description discloses important behaviors: two-phase commit, asynchronous return of progress_id, eventual consistency (alias appears in list after a few seconds), and the manager-private restriction. This adds meaningful context beyond the readOnly/destructive hints, and there is no contradiction with annotations.

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

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

Three sentences, each carrying essential information: core action, architectural effect, and key behavioral caveats (async, two-phase, manager-private). No fluff, and the main purpose 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 tool's complexity (two-phase commit, async provisioning, destructive hint, output schema), the description and schema together cover the essential workflow: what it does, when to use it, what it returns, and the confirmation token's role. A slightly more explicit walkthrough of the two phases would improve it, but it is largely sufficient.

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

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

The schema already provides descriptions for aliases and confirmation_token, but site_id and hosting_id lack schema descriptions. The description itself does not elaborate these parameters, though the tool name and top-level text imply the hosting/site context. With only 50% schema description coverage, the description partially compensates by clarifying wildcard usage and DNS prerequisites for aliases, but leaves some gap for the two id 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 action (bind FQDNs), the target resource (web hosting site), and the effect (Apache vhost serves the new domains). It also distinguishes the tool from related siblings like delete_site_alias by noting 'no new site provisioning required'.

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 useful context: it mentions the two-phase commit, asynchronous behavior, and the fact that no new site provisioning is needed, implying when this tool is appropriate. However, it does not explicitly name alternatives or conditions for not using it, such as when deletion is needed (sibling delete_site_alias).

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

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

Annotations already indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds valuable context beyond annotations: 'GET runs immediately. POST/PUT/PATCH/DELETE follow the two-phase commit pattern.' It also discloses the /proxy/ endpoint restriction. This is meaningful behavioral information not present 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 three sentences long and front-loaded with the most critical information (escape hatch, target API, when to use). Every sentence earns its place: it covers purpose, usage boundary, and method-specific behavior with no filler 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?

The tool is a generic escape hatch with no dedicated schema descriptions. The description covers purpose, usage boundaries, and key behavioral differences (immediate GET vs. two-phase commit). It does not explain the two-phase commit process in detail, but the output schema and annotations provide additional context. Overall, it is reasonably complete for a generic API call tool, with minor gaps around parameter construction and explicit destructive operation warnings.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain the path, body, query, or confirmation_token parameters in any detail. The only parameter-related hint is that non-GET methods use a two-phase commit pattern, implying the need for confirmation_token. The description does not clarify the structure of body/query or the expected path format, leaving a significant gap in 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?

The description clearly states the tool's purpose: 'call ANY Infomaniak public API endpoint (api.infomaniak.com) when no dedicated tool exists.' It uses a specific verb ('call'), identifies the resource (Infomaniak public API), and distinguishes itself from the many typed sibling tools by explicitly positioning itself as an escape hatch.

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 this tool: 'when no dedicated tool exists.' It also states an exclusion and an alternative: 'Manager-private (/proxy/...) endpoints are NOT reachable through this tool — use a typed tool instead.' Additionally, it differentiates behavior by method (GET vs. POST/PUT/PATCH/DELETE), offering clear usage context.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context by outlining what will be checked (expiring products, maintenance, locked products, ongoing operations), which is useful beyond the annotations. It doesn't contradict 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?

The description is a single, front-loaded sentence that immediately states the tool's purpose and then lists the types of issues found. No wasted words.

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

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

The tool has an output schema and robust annotations, so the description need not explain return values. It covers the core purpose and categories, though it could mention the scope (entire organization) more explicitly. Overall it is sufficient for agent understanding.

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

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

Schema description coverage is 100%, and each parameter (account_id, days_ahead, max_domain_checks) has a detailed description including defaults, constraints, and rate-limit context. The tool description itself doesn't add parameter semantics, so baseline 3 applies.

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

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

The description uses a specific verb ('Scan') with a clear resource ('Infomaniak organization') and enumerates concrete categories of issues (expiring, maintenance, locked, ongoing operations). This distinguishes it from other audit tools like infomaniak_audit_dns_zones or infomaniak_audit_account_access.

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

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

The description clearly implies when to use this tool: for a broad health/audit scan of an organization. It doesn't explicitly state exclusions or alternatives, but the context is clear for a general audit tool.

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

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

Annotations already disclose read-only and idempotent behavior. The description adds valuable behavioral context: it scans all domains by default, each domain requires 2 sequential API calls, and the default max_domains keeps execution under ~30s. This goes beyond the annotations to set performance expectations.

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 core purpose, and includes a practical use case. Every word earns its place; no fluff or redundant 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 tool's complexity (bulk audit, optional params, output schema present), the description covers purpose, use case, performance implications, and scoping options. It omits explicit alternative tool comparisons, but overall it is complete enough for an agent to select and invoke correctly.

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

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

All three parameters are fully documented in the input schema, including descriptions, defaults, and constraints. The tool description adds little beyond the schema—only reinforcing the bulk-read scope. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb ('Bulk-read') and resource ('every domain owned by an account'), with the exact output (number of DNS records and DNSSEC status). It distinguishes itself from sibling tools like list_domains and dns_list_records by focusing on bulk auditing across all zones rather than per-zone 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?

The description provides clear context for when to use the tool ('spot-checking large fleets') and how to scope it (via filter_contains for targeted audits). It does not explicitly name alternative tools or list exclusions, but the guidance is sufficient for a read-only audit 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 adds valuable behavioral context beyond annotations: two-phase commit (requires a plan+apply flow) and the fact that going through the private API is required because the public API silently fails. This goes well beyond the readOnly/destructive hints.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence provides unique, non-redundant information. The warning about the public API is concise and highly useful.

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, return values need not be described. The description covers the critical non-obvious aspects (two-phase commit, private API) and is sufficiently complete for an agent to invoke the tool correctly. The schema covers parameter details.

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

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

The schema documents all parameters thoroughly (100% coverage), including the confirmation_token's role in the apply phase and the naming rules. The description mentions two-phase commit but does not add new parameter-level details beyond what the schema already provides.

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

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

The description clearly states 'Create a new MariaDB database on a web hosting' with a specific verb and resource. It also mentions the two-phase commit behavior and the private API, distinguishing it from sibling tools like list_databases or delete_database.

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

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

The description implies when to use this tool by stating it creates a database and warns that the public API silently no-ops, making this private-API tool necessary. It does not explicitly state alternatives or when not to use it, but the context 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?

The description adds critical behavioral context beyond the annotations, including the two-phase commit process, the distinction between SFTP-only and full shell access, and the password policy. These details are not exposed by the readOnlyHint/destructiveHint annotations and are valuable for an agent to understand the tool's non-obvious behavior.

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

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

The description is concise, with three sentences that front-load the core purpose and immediately provide essential distinctions (connection types, two-phase commit). Every sentence contributes functional information, and there is 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?

The description tells the agent the essential facts: what it does, the two-phase commit, and connection type meanings. The schema covers parameter details and the output schema exists, so return values are not required. It doesn't elaborate on permissions or failure modes, but for a create operation with rich schema support, this is sufficiently complete.

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

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

The input schema covers all 6 parameters with detailed descriptions (login prefix rule, password regex, hosting_id discovery, home_directory default, connection_type enum, confirmation_token purpose). The description text adds no significant parameter information beyond the schema, so it 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 clearly states the action 'Create a new FTP / SSH user on a web hosting', identifying the specific verb and resource. It distinguishes from sibling tools like infomaniak_list_hosting_users and infomaniak_delete_hosting_user by focusing on creation. The mention of two-phase commit further clarifies the tool's unique scope.

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

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

The description implies usage by specifying connection types and password policy, but it does not explicitly state when to use this tool vs alternatives like list_hosting_users or delete_hosting_user. No exclusions or alternative recommendations are provided, so the usage guidance is only implicit rather than explicit.

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

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

The description adds useful context beyond annotations, such as the two-phase commit flow and that the password never appears in the plan output. However, it does not explain the non-obvious destructiveHint=true annotation, and the operation is described as 'create' without discussing potential destructive side effects, leaving a gap in transparency.

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 exactly two sentences, front-loaded with the primary purpose, and includes the workflow and security note without any extraneous words. Every sentence earns its place.

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

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

The tool has a complex two-phase commit behavior, and the description covers it sufficiently. An output schema exists to document return values, and the description explains the core workflow. It could be more complete by mentioning prerequisites like discovering the mail_hosting_id, but that is covered in the schema, so the overall context is adequate.

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

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

The input schema already provides descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description adds value by clarifying the role of confirmation_token in the two-phase process and emphasizing that the password is only used in the apply call, which complements the schema's notes.

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 'Create a new mailbox on a mail hosting' with a specific verb and resource. It distinguishes itself from sibling tools like infomaniak_create_mailbox_alias and infomaniak_delete_mailbox, and the two-phase commit detail adds additional precision.

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 describes the two-phase commit process ('plan + token first, then apply with token'), which is a critical usage guideline. However, it does not explicitly mention when not to use this tool versus other mailbox-related tools, though the purpose is clear enough to infer proper usage.

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

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

Annotations already indicate non-read-only and destructive behavior. The description adds the 'Two-phase commit' detail, which is a notable behavioral trait beyond the annotations. However, it does not explain what the two phases are or that a confirmation_token is required, leaving important process behavior undisclosed.

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 purpose, and every word earns its place. The phrase 'Two-phase commit' is terse but conveys a critical constraint 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?

An output schema exists, so return values are covered. However, the two-phase commit process is underspecified: the description does not tell the agent that a confirmation token is needed or how the phases work. For a tool with a non-simple workflow, this is a notable gap in completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly clarifies alias and mailbox (via 'Add a new alias to an existing mailbox'), and mail_hosting_id is implied as an identifier, but the confirmation_token parameter—critical for the two-phase commit—is completely omitted. This leaves a key parameter unexplained.

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

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

The description clearly states the action (Add), the object (a new alias), and the target (an existing mailbox). It also explains the functional effect ('The alias will receive emails delivered to the underlying mailbox'), which distinguishes it from sibling tools like manage_mailbox_aliases.

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

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

The description provides clear context for when to use the tool: adding a new alias to an existing mailbox. However, it does not explicitly mention alternatives or exclusion criteria (e.g., when to use manage_mailbox_aliases instead), so it lacks full if-then guidance.

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

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

Annotations already indicate destructive and non-idempotent behavior, so the bar is lower. The description adds the 'Two-phase commit' detail and the fan-out forwarding behavior, which are useful. However, it doesn't disclose potential side effects, prerequisites beyond the schema, or what happens during the apply phase. It adds some context but not rich behavioral transparency.

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-loads the primary purpose, and includes only essential information. It is concise and well-structured with no filler.

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

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

The two-phase commit workflow is a significant behavioral complexity, but the description only mentions it in passing. It doesn't explain the phases, how to obtain the confirmation token, or the expected invocation sequence. While the schema documents the token, the description itself is incomplete for guiding an agent through a multi-step operation. The tool is also one of many redirection-related tools, and the description doesn't situate it within that 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?

Schema description coverage is 100%, and each parameter has a detailed description (e.g., name pattern, targets format, mail_hosting_id discovery, confirmation_token purpose). The tool description adds no parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Create a server-side mail redirection.' This is a specific verb+resource pairing. It also explains the forwarding behavior ('Emails received at name@<domain> will be forwarded to every address in targets'), which adds clarity and distinguishes it from sibling tools like list or delete redirections.

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 no explicit guidance on when to use this tool versus alternatives. It mentions 'Two-phase commit' as a process hint, but doesn't explain when to use it (e.g., for creating redirections) or when another tool like infomaniak_manage_service_redirections would be more appropriate. There are no clear usage or exclusions.

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

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

The description discloses the two-phase commit behavior, which is crucial for correct invocation and goes beyond what annotations provide. With destructiveHint=true and readOnlyHint=false already set, the description adds the state-changing nature and the confirmation token requirement. It doesn't mention irreversibility or specific side effects, but the two-phase protocol is substantial added context.

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

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

Three short sentences, each adding distinct value: purpose, process, and prerequisite. No fluff or repetition of schema fields. The description is front-loaded with the core purpose and remains highly readable.

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

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

With an output schema present and full parameter documentation, the description covers purpose, process, and precondition adequately. The two-phase commit workflow is hinted but not fully detailed (e.g., how to obtain the confirmation_token), but the schema's token description and output schema likely fill this gap. Complete enough for tool selection and basic 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 covers both parameters with clear descriptions (100% coverage), so the baseline is 3. The description adds context for the 'confirmation_token' by mentioning 'two-phase commit', which clarifies why the token is needed. This goes slightly beyond the schema's note about 'apply phase' and provides workflow context.

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 ('Create') and resource ('short URL') with a clear target ('long target'). It distinguishes itself from siblings like infomaniak_list_short_urls and infomaniak_short_urls_quota by indicating it creates rather than lists or checks quota. The 'Two-phase commit' adds process clarity.

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 to check quota with infomaniak_short_urls_quota when uncertain about headroom, which is a helpful prerequisite. It doesn't explicitly contrast with alternative create or list tools, but the create purpose is self-evident. Missing an explicit 'when not to use' or alternative comparison.

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 indicate readOnlyHint=false and destructiveHint=true, and the description adds important behavioral context: the two-phase commit, the requirement for a confirmation token, and that creation only happens on the second call. This goes beyond the annotations and does not contradict 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?

The description is two concise sentences. The first clearly states the action, and the second explains the necessary two-phase flow, with no redundant 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 description captures the essential two-phase workflow and is supported by an output schema and annotations. However, it omits prerequisites and alternative tool references, so it is slightly above minimum viability but not fully comprehensive.

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

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

Schema description coverage is 0%, and the description only mentions confirmation_token, without explaining hosting_id, fqdn, directory, or environment. It fails to compensate for the lack of parameter documentation, providing almost no semantic value for most 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 tool creates a new site on Infomaniak web hosting, with a specific two-phase commit. It does not explicitly differentiate from sibling tools like infomaniak_provision_site_full, so it lacks sibling distinction.

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 usage guidance by explaining the two-phase commit: first call returns a plan with confirmation_token, second call with same params + token creates the site. However, it does not mention when to use this tool versus alternatives or any exclusions.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description goes further by explaining the fallback to no HTTPS or default cert and the two-phase commit behavior. This adds context about what happens after deletion and the safety mechanism of a planning phase. It doesn't disclose every consequence (e.g., potential downtime) but provides useful transparency 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 every word adds value. It explains the outcome, the two-phase commit, and the planning benefit without fluff. Structure is clear 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 destructive nature and two-phase flow, the description captures the essential context: what happens, how to preview, and that a new cert can be requested later. An output schema is present, so return values are covered elsewhere. The description lacks explicit prerequisites (e.g., hosting_id/site_id), but those are in the schema. Overall, it is complete for an agent to understand the tool's role.

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 covers all parameters (100% coverage) with descriptions for site_id, hosting_id, and confirmation_token. The description does not add parameter-specific details beyond the schema, but it does reinforce the two-phase flow involving confirmation_token. Since the schema already provides thorough explanations, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Delete the SSL certificate of a site.' It uses a specific verb and resource, and the fallback behavior ('will fall back to no HTTPS or Infomaniak's default cert') distinguishes it from certificate provisioning tools like infomaniak_request_certificate. The name and description together leave no 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?

The description explains the two-phase commit process: 'The plan pulls the current certificate status so the caller can see what is about to be removed.' This tells the agent that a first call (without confirmation_token) generates a plan, and a second call executes. It also implies the alternative for re-adding a certificate ('until a new one is requested'), though it doesn't explicitly name infomaniak_request_certificate in the description. No exclusions are stated, but the context is sufficient for an agent to know when to use 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?

The description goes beyond the annotations by specifying the exact destructive impact ('database content (tables, rows) is wiped') and irreversibility ('cannot be recovered without an Infomaniak backup'). It also discloses the two-phase commit behavior, adding meaningful context to the destructiveHint and readOnlyHint 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 (two sentences) and front-loaded with the purpose, followed by the critical warning. Every word adds value: the action, the two-phase process, the access restriction, and the destructive consequence.

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 complexity (two-phase commit, destructive, three parameters), the description covers all necessary aspects: the process, the warning, and the access requirement. An output schema exists, so return values need not be explained. The description is complete for an agent to decide when and how to invoke the tool.

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

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

The input schema already provides 100% coverage with detailed descriptions for all three parameters, including guidance on discovering hosting_id and the correct format for database_name. The description adds little beyond the schema, just mentioning two-phase commit which is already reflected in the confirmation_token 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's action with a specific verb ('Delete') and resource ('MariaDB database'). It distinguishes this tool from sibling delete tools like delete_site or delete_mailbox by specifying the exact resource type.

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 useful context for usage: 'Two-phase commit' informs the agent that a two-step confirmation process is required, and 'manager-private API' indicates restricted access. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it falls short of a 5.

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

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

The description adds significant behavioral context beyond the annotations: it discloses the two-phase commit nature and explicitly states 'Existing files are not deleted,' which is crucial for a destructive action. This goes beyond the basic readOnlyHint=false and destructiveHint=true annotations, giving the agent a clear picture of side effects and safety 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 extremely concise: three short sentences, each carrying essential information. The main action is front-loaded in the first sentence, followed by critical behavioral notes. No unnecessary words or repetition, making it highly efficient for an agent to parse.

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 schema (100% param coverage), output schema presence, and annotations covering destructive/idempotent/readOnly hints, the description fills remaining gaps: the two-phase commit workflow and file preservation. It provides enough context for an agent to select and correctly invoke the tool, including understanding the need for a token and the non-destructive nature regarding files.

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 itself does not add parameter-level details; all parameter semantics are already in the schema (e.g., confirmation_token purpose, login format). The description's mention of two-phase commit relates to the confirmation_token but is already elaborated in the schema, so no additional value beyond the structured fields.

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: 'Revoke a hosting user (FTP / SSH access).' This is a specific verb and resource, and it distinguishes from siblings like infomaniak_create_hosting_user and infomaniak_list_hosting_users. It also adds the key nuance of two-phase commit and file preservation, clarifying the scope of the action.

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

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

The description implies the usage context (revoking access) and even hints at the two-phase commit procedure. However, it does not explicitly name alternatives or when not to use this tool, such as pointing to infomaniak_create_hosting_user for creating users. The two-phase commit is mentioned in the description but fully detailed in the schema, which slightly reduces the guidance value.

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

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

Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses two-phase commit behavior and explicitly warns that all stored emails are deleted, adding valuable context not captured 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?

Three short, high-impact sentences: purpose, two-phase commit, and warning. Every sentence earns its place with zero waste.

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

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

Given the destructive nature and two-phase commit, the schema compensates with detailed parameter descriptions (e.g., confirmation_token, verification steps) and an output schema exists. The description is brief but sufficient when combined with structured 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?

The description itself contains no parameter details, but schema coverage is 100% with rich descriptions for each parameter, so the baseline of 3 applies. No added value from the description, but no gap either.

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 'Delete a mailbox' with a specific verb and resource, and the warning about deleting all stored emails distinguishes it from related mailbox operations like purging spam or emptying trash.

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

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

No guidance is given on when to use this tool vs alternatives, nor any prerequisites. 'Two-phase commit' hints at a workflow but does not explain the plan/execute flow or recommend verifying with infomaniak_list_mailboxes beforehand (though the schema does provide this).

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 adds the critical behavioral trait 'Two-phase commit' beyond what annotations provide. Annotations already indicate destructive and idempotent hints, so the bar is lower, but the two-phase process is essential context not present in annotations. This helps the agent understand the tool requires an extra confirmation step.

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 exactly two sentences with no filler. It front-loads the purpose ('Delete a mail redirection') and immediately follows with the essential two-phase commit caveat. Every word earns its place; it is concise and well-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?

Given the tool's simplicity and the rich schema (all parameters explained, output schema present), the description is adequate. It captures the core purpose and the unique two-phase behavior. The schema fills in the remaining details about token handling and discovery steps, making the definition 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?

Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail; it does not mention mail_hosting_id, name, or confirmation_token. The schema descriptions are comprehensive, so the definition remains clear, but the description provides no extra semantic value for 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 action ('Delete a mail redirection') with a specific verb and resource. It distinguishes itself from sibling tools like infomaniak_create_redirection or infomaniak_manage_service_redirections by naming the delete operation and adding the 'Two-phase commit' note, which uniquely identifies this tool's behavior.

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

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

The description implies usage (when you want to delete a mail redirection) but does not explicitly state when to use versus alternatives or exclude other tools. The schema provides some guidance via parameter descriptions (e.g., 'List existing rules with infomaniak_list_redirections'), but the description itself lacks direct usage direction.

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

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

Beyond annotations (destructiveHint=true), the description discloses that deletion also 'wipes the site directory on the FTP backend after a short grace period' and that the first call is a non-destructive preview. This is significant behavioral context not in 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 purpose, and efficiently adds essential procedure and warning without padding.

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

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

Despite being a destructive, two-phase operation, the description covers the action, the phase flow, and the consequence (directory wipe with grace period). Output schema exists, so return values need not be described. This is complete for the tool's complexity.

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

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

Schema descriptions for all three parameters are already detailed (e.g., confirmation_token explains phase usage). The tool description repeats the token flow but adds no new parameter-level semantics, so it relies on 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 opens with a specific verb+resource: 'Delete a site from an Infomaniak web hosting.' It also clarifies the two-phase commit nature, distinguishing it from single-call tools like infomaniak_delete_site_alias or infomaniak_delete_database.

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 explains the two-phase procedure: first call returns a plan with token, second call with same params + token performs the delete. This gives clear when-to-call context. It does not explicitly name alternative tools or exclusion criteria, so not a 5.

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

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

Annotations already flag the tool as destructive, but the description adds valuable behavioral details: 'Two-phase commit' and the post-condition that the Apache vhost will no longer respond. It also states the main FQDN exclusion. This goes beyond the bare destructive flag.

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, front-loaded with the primary purpose. Every sentence adds distinct information: action, exclusion, commit behavior, consequence, and access level. No filler.

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

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

The description covers the main effect and constraint, and an output schema exists to describe returns. However, 'Two-phase commit' is mentioned but not explained, and there is no mention of the confirmation_token parameter or that list_site_aliases should be used first. This leaves gaps for a destructive operation.

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

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

Schema description coverage is only 25% (only alias has a description). The description reiterates the alias constraint but does not clarify hosting_id, site_id, or confirmation_token. With low schema coverage, the description should compensate, but it does not explain the remaining 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 states a specific action: 'Remove one alias FQDN from a web hosting site', which clearly identifies the verb and resource. It also distinguishes itself from siblings by noting the main FQDN cannot be removed, differentiating it from list/add alias tools.

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

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

The description provides clear context: it is for removing an alias from a hosting site, explicitly excludes the main FQDN, and notes the operation is 'Manager-private'. It does not explicitly name sibling tools as alternatives, but the scope is sufficiently 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 flag destructiveHint=true and readOnlyHint=false; the description adds the critical two-phase commit behavior, explaining that the first call plans and the second with token actually creates. This is valuable beyond 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?

Two sentences, first states purpose, second explains the phased behavior. Zero 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 non-idempotent, mutating tool with a two-phase protocol, the description captures the essential workflow. The zone prerequisite is mentioned in the description and reinforced in schema; output format is covered by 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 rich descriptions. Description adds the cross-phase constraint that all params must be identical except the token, which clarifies how confirmation_token interacts with other 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?

Description uses specific verb 'Create' with resource 'DNS record' and scope 'Infomaniak-managed zone'. The two-phase commit detail distinguishes this create tool from update/delete/list siblings.

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

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

Provides clear context: use to create a DNS record on a managed zone, and outlines the two-phase procedure. Does not name sibling alternatives explicitly, but the verb and resource make the intended use unambiguous.

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

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

Annotations already convey destructive hint and non-read-only. The description adds significant behavioral detail: the two-phase commit process, including the plan preview and confirmation token. This context is not present in annotations and helps the agent understand the deletion is not immediate, requiring a second call. It does not cover token expiry or failure modes, but the core behavior is transparent.

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

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

Two sentences, front-loaded with the primary purpose, followed by the two-phase explanation. Every word adds value—no fluff. The structure is clear and easy to parse.

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 and annotations, the description covers the essential workflow: delete operation with two-phase commit, preview, and token. It doesn't explicitly mention prerequisites like zone ownership, but the schema's zone description includes that. It is sufficiently complete for a destructive tool with good annotations and 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 coverage is 100%, and each parameter has a detailed description (zone, record_id, confirmation_token). The description adds minimal parameter info beyond referencing the token from the first phase, which the schema already explains. Baseline of 3 applies because the schema handles parameter semantics well.

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: 'Delete a DNS record from an Infomaniak-managed zone.' It uses a specific verb and resource, and the two-phase commit explanation further distinguishes it from simple delete tools. It is easily differentiated from sibling tools like infomaniak_dns_create_record and infomaniak_dns_update_record.

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

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

The description implies when to use the tool (to delete a DNS record) and provides the two-phase workflow, which is a key usage guideline. It does not explicitly mention alternatives or exclusions, but the purpose is clear. The schema reference to infomaniak_dns_list_records for obtaining record_id also guides usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by explaining the tool returns all records on the zone and that the input must be a root domain, not a subdomain. It does not contradict annotations.

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

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

The description is two sentences with no filler. The key action and example are front-loaded, and each sentence earns its place by defining scope and clarifying the required input format.

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

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

For a single-parameter listing tool with a robust output schema and annotations covering safety and idempotency, the description adequately covers the essential context. It states what the tool lists, the required input type, and the constraint against subdomains, leaving no significant gap for an agent to misuse it.

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

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

Schema description coverage is 100% and already describes the zone parameter as 'Zone (root domain), e.g. example.com'. The description reinforces the root-domain requirement but does not add substantive new parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists every DNS record on an Infomaniak-managed zone, using a specific verb ('List') and resource ('DNS record on a zone'). It distinguishes the tool from DNS mutation siblings like infomaniak_dns_create_record and infomaniak_dns_update_record by focusing on enumeration, and gives a concrete example.

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

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

The description provides clear usage context by instructing the agent to use the root domain and explicitly warns against using a subdomain. It does not name alternative tools for exclusions, but the second sentence provides actionable guidance on how to invoke 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?

The description discloses a crucial behavioral trait: the two-phase commit process. It explains that the first call previews changes and returns a token, while the second call applies them. This goes well beyond the annotations (which only indicate readOnly=false, destructive=true, idempotent=true) and adds critical context for the agent to understand the tool's state-changing workflow.

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 exceptionally concise: two sentences, front-loaded with the tool's purpose, followed by the two-phase mechanism. Every word earns its place with no redundancy or filler.

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

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

For a mutation tool with two-phase commit, 7 parameters, and an output schema, the description captures the essential workflow and the meaning of the confirmation_token. The existence of an output schema covers return values, and the required parameters (zone, record_id) are self-evident from the schema. The explanation is sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the confirmation_token's role by mentioning 'same params + token' in the two-phase commit, which is valuable. However, other parameters (ttl, type, source, target) are not elaborated; the description only generically says 'one or more fields' rather than listing them. This is adequate but not comprehensive.

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 precisely: 'Update one or more fields of a DNS record.' This clearly identifies the tool's purpose with a specific verb and resource, and distinguishes it from sibling tools like infomaniak_dns_create_record and infomaniak_dns_delete_record. The mention of 'one or more fields' adds scope.

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

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

The description conveys clear usage context: it is for updating existing DNS records, and the two-phase commit explains the process. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe repeated reads. The description does not add behavioral context beyond stating it returns the definition. No side effects or auth requirements are mentioned, which is acceptable given the annotations.

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

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

The description is a single, well-structured sentence that succinctly conveys the tool's purpose and the content of its output. No superfluous words.

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

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

Given the presence of an output schema and clear annotations, the description is largely complete. It captures the essential function and could be improved by noting the format of the returned definition, but it is adequate.

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

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

The schema covers 100% of the single parameter 'tool' with a description. The tool description does not add additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Returns the full definition of a specific tool' and lists the components (description, annotations, parameters, output shape). It distinguishes itself from siblings, as it is a meta-tool for obtaining information about other 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?

Usage context is implied by the description (useful for learning about a tool), but there is no explicit guidance on when to use it versus alternatives or when not to use it. The sibling tools are all action-oriented, so the purpose is clear, but no exclusions are mentioned.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, which covers the safety profile. The description adds valuable behavioral context beyond that: it returns a specific ID set and the full site object, and it 'short-circuits on the first match,' explaining the performance behavior. It does not disclose edge cases like no-match behavior, but it is transparent enough given 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 with no wasted words. It front-loads the core purpose and return value, then provides usage guidance and performance rationale. Every sentence contributes useful 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 that an output schema exists and the input schema is fully described, the description covers the remaining context: when to use the tool, what it returns, and how it compares to alternatives. It is complete 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 description coverage is 100%, so the baseline is 3. The description adds the high-level purpose and return fields, but the parameter semantics (domain type, optional account_id restriction) are already documented in the schema. No additional meaning is provided that is not in the input schema.

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

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

The description uses a specific verb and resource: 'Locate a domain (e.g. broz.be) in the Infomaniak account tree.' It clearly states what it returns and explicitly distinguishes itself from sibling tools by positioning it as a prerequisite for tools requiring hosting_id and site_id, and by contrasting it with the more expensive list_hostings + list_sites approach.

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 guidance: 'Use this BEFORE any tool that requires hosting_id + site_id ... when you only know the domain name.' It also names the alternative (calling list_hostings + list_sites) and explains the efficiency advantage, making the right invocation context clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive behavior, so the description needs less. It adds valuable context with the 'Manager-private' access restriction and clarifies the support tier value (premium=2). Enumerating the returned fields also enhances transparency beyond what annotations offer.

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

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

The description is a single, information-dense sentence that front-loads the purpose with 'Full organization detail.' Every listed field is relevant, and there is no redundant wording or filler.

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

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

For a simple read-only getter with one parameter, existing output schema, and rich annotations, the description sufficiently covers the tool's function and data scope. Minor gaps like explicit usage alternatives and return-format details are acceptable because the output schema handles format and the sibling list implies scope.

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 provides a complete description for account_id, including how to discover it (via infomaniak_list_organizations), achieving 100% schema description coverage. The tool description adds no parameter-specific information, but that is unnecessary given the schema's thoroughness.

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 it retrieves 'Full organization detail' and enumerates specific data fields (legal entity, billing addresses, VAT, locale, timezone, etc.). It unambiguously identifies the resource as the account/organization and distinguishes itself from sibling tools targeting other resources (domains, drives, VPS).

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

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

The description implies this is the comprehensive org-detail tool via 'Full organization detail,' but does not explicitly state when to use it over alternatives like infomaniak_list_organizations or infomaniak_get_account_resources. No exclusions or alternative recommendations are provided, making usage guidance only implicit.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint, reducing the burden. The description adds value by detailing the specific return fields (provisioning state, type, validity flags, timestamps, etc.), providing behavioral context beyond annotations.

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

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

The description is a single sentence that front-loads the main purpose and lists features. It is efficient with no wasted words, though the list of fields makes it slightly long.

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, the description need not explain return values, but it does so helpfully. However, it omits how to obtain the required IDs (e.g., from list hostings/sites) and does not address error cases like missing certificates. Adequate but not fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It only implies that hosting_id and site_id identify a site on a web hosting, but does not define them clearly or indicate how to obtain them. This is insufficient for a tool with only two 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 it returns the full SSL certificate detail for one site on a web hosting, and lists many specific fields. It distinguishes well from sibling tools like infomaniak_request_certificate and infomaniak_delete_certificate.

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

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

The description implies usage for retrieving certificate details but does not explicitly state when to use this tool versus alternatives like infomaniak_list_sites or infomaniak_get_domain. No prerequisites or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful context by listing what 'full detail' includes (disk usage, application, permissions, backups), giving the agent a concrete sense of the returned information. 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 a single, front-loaded sentence with a parenthetical that adds value without clutter. Every word contributes to purpose and expected return content.

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

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

For a simple read-only get operation with a clear output schema and strong annotations, the description is mostly sufficient. It could be slightly richer by referencing sibling tools or clarifying prerequisites, but the available schema and annotations fill most gaps.

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

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

Schema description coverage is only 50%, with hosting_id lacking any description and database_name getting a helpful description. The tool description does not add meaning for either parameter beyond calling the target 'a specific database', so it fails to compensate for the missing hosting_id semantics.

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

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

Description uses a specific verb ('Get') and a clear resource ('full detail of a specific database'), adding concrete detail categories in parentheses. It clearly distinguishes itself from sibling tools like infomaniak_list_databases and infomaniak_get_database_user.

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

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

The description implies the tool is for one specific database rather than a list, but it does not explicitly state when to use it versus alternatives such as infomaniak_list_databases. The schema's reference to infomaniak_list_databases provides some context, but the description itself offers no direct exclusions or alternative guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, making the safe read nature clear. The description adds valuable context about what the detail includes (applications, permissions, link to phpMyAdmin), going beyond the annotations. It does not contradict annotations.

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

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

A single sentence that is concise, front-loaded with the verb 'Fetch', and contains no filler. Every word 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 read-only get tool, the description provides sufficient context: what the tool returns and the resource type. Output schema covers return structure, and annotations cover safety. The only minor gap is the lack of parameter details, but that is a separate dimension and not critical for overall completeness.

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

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

Schema covers 50% of parameters (user_name has a description, hosting_id does not). The description does not compensate for the undocumented hosting_id; it only mentions 'single MariaDB-level user' which implicitly relates to user_name but not to hosting_id. No additional parameter meaning is provided beyond the schema.

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

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

The description clearly states the action ('Fetch') and the resource ('detail of a single MariaDB-level user'), and specifies the type of details returned ('applications, permissions, link to phpMyAdmin'). It distinguishes from siblings by emphasizing 'single' user as opposed to listing tools like infomaniak_list_database_users.

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

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

The description implies when to use this tool: when you need details of a single MariaDB-level user. It does not explicitly mention alternatives or exclusions, but the 'single' scope provides clear context relative to list tools. No misleading guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds some context by specifying the categories of information returned, but it does not go beyond that to disclose potential error behavior, prerequisites, or other non-obvious traits. This is mild added value over the annotations.

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

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

The description is a single, well-formed sentence that front-loads the action and resource, followed by a concise parenthetical list of included details. Every word is informative and there is no redundancy or unnecessary elaboration.

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

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

For a simple single-parameter read-only tool, the description provides sufficient context about what data is returned (DNS management status, DNSSEC, IDN, errors). The output schema exists, so return values need not be described. The only notable gap is the lack of relationship clarification with the sibling infomaniak_get_domain_full, which is not critical for basic 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 has one parameter with a clear description ('The domain name, e.g. example.com'), so schema coverage is 100%. The tool description does not add any additional parameter semantics beyond what the schema already provides, which justifies the baseline score 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 uses a specific verb ('Get') and resource ('domain'), and lists the information categories covered (DNS management status, DNSSEC, IDN, errors). This clearly indicates what the tool does, but it does not explicitly distinguish it from the sibling tool infomaniak_get_domain_full, so it misses the full differentiation.

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

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

The description implies usage for retrieving detailed domain information but provides no explicit guidance on when to use this tool versus alternatives like infomaniak_get_domain_full or infomaniak_get_domain_resources. No exclusions or alternative tool mentions are present, making the usage context only implicit.

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

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

Annotations already cover read-only/idempotent safety, so the description adds value by listing the specific data categories returned and the manager-level access requirement. No contradictions with annotations.

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

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

Description is a single efficient sentence that front-loads the purpose and uses a concise list of included data. Every item is specific and non-redundant.

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

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

With a rich output schema present, the description covers all necessary behavioral context: input formats, included data, and access requirements. It is fully sufficient for selecting and invoking the tool.

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

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

The single parameter 'domain' is fully described in the schema (100% coverage); the description only briefly reiterates ID/FQDN acceptance without adding format or discovery details beyond what the schema provides.

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

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

Description clearly states it returns 'Full domain detail' and enumerates specific fields (auth_code, transfer_status, DNS health, etc.), distinguishing it from simpler domain tools like infomaniak_get_domain. The verb+resource+scope is 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?

It states the accepted input forms (domain_id or FQDN) and notes 'Manager-private' access, giving clear context for invocation. It does not explicitly name alternative tools or exclusions, but the scope is evident from the detailed field list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the manager-private API context and the specific data fields returned, which goes beyond the annotation-provided safety profile. No contradictions exist, though more detail on response behavior would have improved it.

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

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

Two sentences, front-loaded with the tool's purpose and full detail fields, followed by a distinguishing note about the sibling tool. Every sentence earns its place with no 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 a simple read-only tool with one parameter and an output schema, the description covers purpose, return content, use case, and access-level differentiation. It is sufficiently complete for an agent to select and invoke 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 single parameter drive_id is fully described in the input schema with a hint to discover via infomaniak_list_drives. The description adds no parameter-specific semantics, but since schema coverage is 100%, 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 it retrieves full kDrive detail, listing specific fields (name, total size, used size, timestamps, maintenance flag) and explicitly distinguishes from infomaniak_list_drives by API access level. It identifies a specific verb and resource with concrete scope.

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

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

The description indicates usefulness for storage usage monitoring and explicitly contrasts with infomaniak_list_drives (public Bearer API vs manager-private), offering clear guidance on when to use this tool. It doesn't exhaustively cover when not to use it, so it falls slightly short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by detailing the specific data categories returned and the 'Manager-private' access level, but it does not disclose other behavioral aspects like rate limits or authentication requirements.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and then lists the exact scope of returned data. Every listed item is informative and there is no fluff, though the sentence is long and could be slightly more structured with separators.

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

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

Given the presence of an output schema and comprehensive annotations, the description adequately covers the tool's purpose, usage context, and data scope. The only notable gap is the lack of parameter clarification, but this is partially offset by the schema and the tool's straightforward 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?

The schema description coverage is 50%, with only mailbox_name having a description. The tool description adds no information about either parameter, leaving mail_hosting_id entirely unexplained. The agent must rely on external context or other tools to understand that parameter, so the description does not compensate for the schema gap.

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

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

The description begins with 'Full mailbox detail' followed by a comprehensive enumeration of specific attributes (auto-responder, aliases, redirections, security flags, filters, etc.), making it unmistakably clear that this tool retrieves an exhaustive mailbox snapshot. The scope distinguishes it from narrower siblings like get_mailbox_info or get_mailbox_security, even though those alternatives are not explicitly named.

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 'Useful for mailbox audits and onboarding flows', providing clear context for when to employ this tool. It also adds a 'Manager-private' access restriction. However, it does not mention alternative tools or when not to use it, so it lacks explicit exclusions.

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

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

Annotations already declare read-only and idempotent, so the bar is lower. The description adds that it hits only the corresponding endpoints in parallel, revealing efficiency and conditional behavior. 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, front-loaded with purpose, each sentence has a distinct role: purpose, field selection, replacement statement. No filler.

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

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

With output schema and rich annotations, the description is sufficient: it names the three sections, explains field behavior, and provides migration context from old tools. No critical missing info.

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 parameters are already fully documented. The description only restates the 'subset' concept and parallel behavior, adding minimal semantic 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?

States 'Read mailbox metadata in one call' with a specific verb and resource. Explicitly distinguishes from siblings by naming the replaced trio and the three metadata sections (aliases, signatures, backups).

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 guidance to use this instead of the v0.9 trio, and explains how to select subsets via the fields argument. Doesn't discuss alternatives like get_mailbox_full, but the replacement context gives a clear when-not.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds meaningful context about returned data (MX/SPF/DKIM/DMARC health check, quotas) and access restrictions, which goes 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?

Two sentences, front-loaded with the most important information, and every word adds value. The structure is efficient and scannable.

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

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

Given the existence of an output schema and read-only annotations, the description adequately explains what the tool does, what it contains, and when to use it. No significant gaps are apparent for a simple one-parameter getter.

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

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

The input schema has 100% coverage; the parameter description explains what mail_hosting_id is and how to discover it. The tool description does not add parameter-specific details beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns 'Full mail hosting detail' and enumerates specific content (diagnostic_dns, quotas, admin user, etc.), distinguishing it from list_mail_hostings and other mailbox-specific tools. The verb 'get' is implied by the name, and the resource scope is explicit.

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

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

The description provides a clear use case ('Use this for mail-config sanity checks') and notes access level ('Manager-private'). It does not explicitly mention alternatives or when not to use, but the context is sufficiently clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond those: it reveals that the tool acts on the currently authenticated user/account, requires the SASESSION cookie, and is manager-private, plus what current_account_id means. This enriches transparency 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?

Three sentences front-load the core purpose and then pack useful details (returned fields, usage guidance, auth requirement) into tight phrasing. No filler or redundancy; every clause adds 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 an output schema present, the description doesn't need to enumerate return types. It covers the purpose, usage context, and auth prerequisite, making it complete for a zero-parameter identity tool with strong annotations.

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

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

The input schema has zero parameters and 100% schema coverage, so the baseline is 4. The description has no parameter semantics to add because there are none; it instead describes the rich output surface, which is appropriate for a no-arg profile tool.

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

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

The description opens with a specific verb+resource: 'Get the identity of the currently-authenticated Infomaniak user.' It enumerates returned fields (name, email, language, country, timezone, current_account_id, security posture) and explicitly frames its role as confirming which user/account the MCP acts on behalf of, distinguishing it from sibling tools like get_my_security or list_organizations.

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 usage directive: 'Use this first to confirm which user + account the MCP is acting on behalf of.' It also states a prerequisite (requires SASESSION cookie, manager-private). It does not discuss when not to use or name alternatives, so it stops short of full exclusion guidance.

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