Skip to main content
Glama
alpadalar

ActiveDirectoryMCP

by alpadalar

remove_group_member

Removes a specified member from an Active Directory group after validating membership, ensuring accurate group access control.

Instructions

Remove a member from a group.

Removes specified member from group membership.

Example:

  • remove_group_member(group_name="Sales Team", member_dn="CN=John Smith,OU=Users,DC=company,DC=com")

Validates membership before removal.

Input Schema

NameRequiredDescriptionDefault
member_dnYesDistinguished name of member to remove
group_nameYesGroup name to remove member from

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior3/5

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

No annotations exist, so the description bears the full burden. It does disclose one real behavioral trait, 'Validates membership before removal', but omits whether a non-member causes an error, whether the operation is idempotent, what permissions are required, and whether removal is reversible.

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

Conciseness3/5

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

The example and validation note are useful and front-loaded, but the first two sentences say the same thing twice ('Remove a member from a group' / 'Removes specified member from group membership'), wasting space.

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

Completeness3/5

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

For a simple two-parameter mutation with full schema coverage, the description is close to sufficient, but with no annotations and no output schema it should say more about error behavior and permissions before an agent can call it confidently.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented, giving a baseline of 3. The worked example does add useful format context by showing a concrete DN string, but no constraints (e.g. DN syntax rules, escaping) are elaborated.

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

Purpose4/5

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

States a specific verb and resource: remove a member from a group. An agent can distinguish it from add_group_member and get_group_members without opening the schema, though it never names those siblings explicitly.

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

Usage Guidelines2/5

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

No guidance on when to use this versus alternatives such as modify_group, and no stated prerequisites (required permissions, whether the caller must be an owner). Usage is only implied by the tool name.

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