infomaniak_delete_hosting_user

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.