Related Servers

Most tools target a distinct object class plus action, and adjacent tools (find_users vs get_user vs get_by_dn, find_inactive_users vs find_stale_computers, is_disabled vs disabled_users) are explicitly cross-referenced in descriptions. The main soft spot is audit_admin_accounts, which is essentially get_privileged_groups(with_members=True, nested=True) wrapped in another tool, and search_ldap overlaps with the entire typed surface as an escape hatch.

The dominant pattern is verb_noun (find_users, get_group, list_gpos, get_ou_contents), but a large audit subset abandons verbs entirely for bare-noun or predicate phrasing: disabled_users, locked_users, password_not_required, not_delegated, never_expiring_accounts, group_members, user_groups. Predicate-named tools like password_not_required function as list queries, which reads oddly next to list_gpos. Still parseable, but three conventions coexist.

54 tools is far beyond a comfortable set; dozens are narrow single-purpose audit queries (kerberos_preauth_not_required, never_expires_password, find_users_without_email) that could collapse into a parameterized audit or search_ldap filter. The breadth reflects a genuinely large domain (users, groups, computers, OUs, GPOs, trusts, sites, FSMO, password policies), but the surface is too heavy for reliable tool selection.

Read-side coverage is excellent: nearly every AD object class and audit scenario has a dedicated query, plus search_ldap as a fallback. However, the surface is entirely read-only, so an agent that finds a stale or risky account has no path to disable, unlock, reset a password, or modify group membership, which is a notable dead end for an AD server.