Permanently removes a specified Active Directory user account and associated data after validating the username exists, enabling administrators to clean up redundant or unauthorized accounts.
Delete a user account from Active Directory.
Permanently removes user account and all associated data. Use with caution.
Example:
delete_user(username="jsmith")
Validates user existence before deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Username to delete |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose the most important traits: the deletion is permanent and cascades to associated data, plus existence validation occurs first. It omits permission/auth requirements and whether errors are returned for nonexistent users, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the destructive nature in two tight sentences, which is exactly the right ordering for a delete tool. The example block is mildly redundant for a single self-evident parameter, costing a point on economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with no output schema, the description supplies purpose, permanence, a precondition, and an example, which is essentially everything needed to invoke it correctly. Only permission/error semantics are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter and 100% schema coverage, the baseline is 3, and the worked example (delete_user(username="jsmith")) adds concrete call syntax beyond the schema's bare 'Username to delete'. It doesn't describe username format or domain-qualification, so it earns above baseline but not full marks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Delete a user account from Active Directory') and immediately clarifies permanence and scope ('Permanently removes user account and all associated data'), which differentiates it from enable_user/disable_user without naming them. An agent can distinguish this from disable_user purely from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use with caution' implies this is a high-stakes operation, and 'Validates user existence before deletion' gives a usable precondition. However, it never explicitly names the alternative (disable_user) or states when-not-to-use, so selection between delete and disable is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.