How do I use ldapdomaindump MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ldapdomaindump MCP Server Enumerate users and groups on internal.corp.local with domain admin" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

ldapdomaindump MCP Server

by schwarztim

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

ldapdomaindump MCP Server

A Model Context Protocol (MCP) server that provides AI assistants with access to ldapdomaindump, a powerful Active Directory LDAP enumeration tool commonly used in penetration testing and security assessments.

Overview

This MCP server enables AI assistants to perform Active Directory reconnaissance by enumerating:

Domain Users - Account names, descriptions, last logon times, password expiry, account status
Domain Groups - Group memberships, descriptions, nested groups
Domain Computers - Computer accounts, operating systems, DNS hostnames
Domain Trusts - Trust relationships, directions, and types
Password Policies - Lockout thresholds, password requirements, fine-grained policies

Related MCP server: PentestMCP

Architecture

The server executes commands on a remote Kali Linux host via SSH, making it ideal for setups where the AI assistant runs on a different machine than the pentesting environment.

┌─────────────┐      SSH      ┌─────────────┐      LDAP      ┌─────────────┐
│  MCP Host   │ ────────────> │    Kali     │ ─────────────> │   Domain    │
│  (Claude)   │               │   Linux     │                │ Controller  │
└─────────────┘               └─────────────┘                └─────────────┘

Prerequisites

Kali Linux host with SSH access configured
ldapdomaindump installed on Kali:
```
pip install ldapdomaindump
```
SSH key-based authentication to the Kali host
Node.js 18+ on the MCP host

Installation

git clone https://github.com/schwarztim/sec-ldapdomaindump-mcp.git
cd sec-ldapdomaindump-mcp
npm install
npm run build

Configuration

Environment Variables

Variable	Description	Default
`KALI_HOST`	SSH hostname or alias for Kali	`kali`
`LDAP_OUTPUT_DIR`	Directory on Kali for output files	`/tmp/ldapdomaindump`

SSH Setup

Ensure you have SSH key-based access to your Kali host:

# Add to ~/.ssh/config
Host kali
    HostName 192.168.1.100
    User root
    IdentityFile ~/.ssh/kali_key

Claude Desktop Configuration

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "ldapdomaindump": {
      "command": "node",
      "args": ["/path/to/sec-ldapdomaindump-mcp/dist/index.js"],
      "env": {
        "KALI_HOST": "kali",
        "LDAP_OUTPUT_DIR": "/tmp/ldapdomaindump"
      }
    }
  }
}

Available Tools

`ldapdomaindump_dump`

Perform a full LDAP domain dump - enumerates all objects and outputs HTML, JSON, and greppable files.

`ldapdomaindump_users`

Enumerate domain users with attributes like SAM account name, display name, last logon, and account status.

`ldapdomaindump_groups`

Enumerate domain groups and their memberships.

`ldapdomaindump_computers`

Enumerate domain computers with OS information and DNS hostnames.

`ldapdomaindump_trusts`

Enumerate domain trust relationships.

`ldapdomaindump_policies`

Get domain password policies including lockout thresholds and complexity requirements.

`ldapdomaindump_read_output`

Read previously generated output files from the Kali host.

`ldapdomaindump_ldd2pretty`

Convert JSON output to enum4linux-like readable format using ldd2pretty.

`ldapdomaindump_check`

Verify ldapdomaindump installation and SSH connectivity.

Usage Examples

Full Domain Dump

Use ldapdomaindump_dump with:
- hostname: 10.10.10.1
- username: CORP\jsmith
- password: Password123

Enumerate Users Only

Use ldapdomaindump_users with:
- hostname: dc01.corp.local
- username: CORP\enumuser
- password: EnumPass!
- useSsl: true

Pass-the-Hash Authentication

Use ldapdomaindump_dump with:
- hostname: 10.10.10.1
- username: CORP\administrator
- password: aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
- authType: NTLM

Output Files

ldapdomaindump generates several output files:

File	Description
`domain_users.json`	All user accounts
`domain_groups.json`	All groups and memberships
`domain_computers.json`	All computer accounts
`domain_trusts.json`	Domain trust relationships
`domain_policy.json`	Password and lockout policies
`domain_users_by_group.json`	Users organized by group (with `--grouped-json`)
`domain_computers_by_os.json`	Computers organized by OS (with `--grouped-json`)

Security Considerations

This tool is intended for authorized security assessments only
Credentials are passed via command-line arguments - ensure your Kali host is secure
Output files may contain sensitive information - clean up after assessments
Large domains may cause high load on domain controllers when using DNS resolution

Troubleshooting

SSH Connection Failed

# Test SSH connectivity
ssh kali "echo 'Connected'"

# Verify ldapdomaindump is installed
ssh kali "which ldapdomaindump"

Authentication Errors

Verify username format: DOMAIN\username or username@domain.local
Check password/hash format for NTLM authentication
Try SIMPLE auth type if NTLM fails

No Output Files

Check if the output directory exists and is writable
Verify LDAP connectivity from Kali to the domain controller
Review stderr for authentication or network errors

ldapdomaindump - The underlying Python tool
BloodHound - AD attack path analysis
ldd2bloodhound - Convert output to BloodHound format

License

MIT License - See LICENSE for details.

Disclaimer

This tool is provided for educational and authorized security testing purposes only. Users are responsible for ensuring they have proper authorization before using this tool against any systems. Unauthorized access to computer systems is illegal.

Available Tools

9 tools

ldapdomaindump_checkA

Check if ldapdomaindump is installed and accessible on the Kali host via SSH.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses the tool's behavior: checking installation and SSH accessibility. No annotations provided, but the description is sufficient for a simple read-only check.

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

Conciseness5/5

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

Single sentence, front-loaded with action and resource, no wasted words.

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

Completeness5/5

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

For a parameterless check tool, the description is complete, providing enough context given sibling tools and no output schema.

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

Parameters4/5

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

No parameters exist, and with 0 parameters, the baseline is 4; the description adds no param info, which is acceptable.

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

Purpose5/5

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

The description clearly states the verb 'Check' and the resource 'if ldapdomaindump is installed and accessible on the Kali host via SSH', distinguishing it from sibling dump/read tools.

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

Usage Guidelines3/5

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

No explicit guidance on when to use vs alternatives, though the purpose implies it is a prerequisite check before other ldapdomaindump tools.

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

ldapdomaindump_computersB

Enumerate domain computers. Returns computer accounts with OS info, hostnames, and descriptions.

ParametersJSON Schema

Name	Required	Description
`hostname`	Yes	Domain controller hostname or IP
`username`	Yes	Username in DOMAIN\username format
`password`	Yes	Password or NTLM hash
`authType`	No	Authentication type
`useSsl`	No	Use LDAPS connection
`resolveDns`	No	Resolve computer hostnames to IP addresses
`outputDir`	No	Output directory

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided; description only states basic action and return values. Does not disclose side effects (likely read-only), authentication requirements (though schema includes credentials), rate limits, or output format details. Minimal behavioral context.

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

Conciseness5/5

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

Single sentence with no wasted words. Front-loaded verb and resource, immediate understanding. Appropriate length for its purpose.

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

Completeness2/5

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

Complex tool with 7 parameters and no output schema, yet description is only one sentence. Does not explain authentication flow, output directory role, or full return shape. Missing critical context for effective use.

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% for all 7 parameters; description adds no parameter-specific information beyond what 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.

Purpose5/5

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

Clearly states verb 'enumerate' and resource 'domain computers', lists return fields (OS info, hostnames, descriptions), and distinguishes from sibling tools like ldapdomaindump_users and ldapdomaindump_groups.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives like ldapdomaindump_dump. Usage context is implied by tool name and sibling structure, but no when-not-to-use or prerequisite information.

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

ldapdomaindump_dumpB

Perform a full LDAP domain dump - enumerates users, groups, computers, trusts, and policies. Outputs HTML, JSON, and greppable files.

ParametersJSON Schema

Name	Required	Description
`hostname`	Yes	Domain controller hostname or IP address (e.g., '10.10.10.1' or 'dc01.corp.local')
`username`	Yes	Username for authentication in DOMAIN\username format (e.g., 'CORP\jsmith')
`password`	Yes	Password or NTLM hash (LM:NT format) for authentication
`authType`	No	Authentication type (default: NTLM)
`outputDir`	No	Output directory on Kali (default: /tmp/ldapdomaindump)
`useSsl`	No	Use LDAPS (SSL) connection (default: false)
`resolveDns`	No	Resolve computer DNS hostnames to IPs (may cause high DC load)
`groupedJson`	No	Enable grouped JSON output for users_by_group and computers_by_os

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It mentions output formats but lacks details on potential network load, required privileges, time consumption, or any side effects. The tool likely performs read-only operations, but this is not explicitly stated.

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

Conciseness4/5

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

The description is a single sentence that efficiently conveys the tool's purpose. It is front-loaded with the key action and outputs. However, it could be slightly expanded without losing conciseness to improve completeness.

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

Completeness2/5

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

Given the complexity (8 parameters, full dump), the description is too sparse. It omits details about output format interpretation, performance implications, or prerequisites. No output schema is provided, so the description should offer more context.

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?

The input schema has 100% description coverage, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides. It does not explain parameter interdependencies or special cases.

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

Purpose5/5

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

The description uses specific verbs and resources: 'perform a full LDAP domain dump', enumerates users, groups, computers, trusts, and policies. It clearly distinguishes from sibling tools like ldapdomaindump_users and ldapdomaindump_groups by indicating it is a full dump.

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

Usage Guidelines3/5

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

The description implies usage for comprehensive enumeration via 'full LDAP domain dump' but does not explicitly state when to use this tool over siblings or when not to use it. No alternatives 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.

ldapdomaindump_groupsB

Enumerate domain groups and their memberships. Returns group names, descriptions, and member lists.

ParametersJSON Schema

Name	Required	Description
`hostname`	Yes	Domain controller hostname or IP
`username`	Yes	Username in DOMAIN\username format
`password`	Yes	Password or NTLM hash
`authType`	No	Authentication type
`useSsl`	No	Use LDAPS connection
`outputDir`	No	Output directory

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description lacks behavioral details such as side effects (e.g., it is read-only), authentication requirements, or output format beyond basic return types. It does not contradict annotations (none exist) but fails to add essential context.

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

Conciseness5/5

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

The description is extremely concise: two short sentences with no wasted words. It front-loads the action and return values, making it easy to scan.

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

Completeness2/5

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

Given 6 parameters (3 required), no output schema, and no annotations, the description is too brief. It does not cover setup, output structure, or how to interpret member lists, leaving significant gaps for an AI agent.

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 baseline is 3. The description does not add meaning beyond the schema; it simply restates the tool's purpose without explaining parameters like hostname or authType.

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

Purpose5/5

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

The description uses a specific verb ('Enumerate') and resource ('domain groups and their memberships'), and clearly distinguishes from sibling tools like ldapdomaindump_users or ldapdomaindump_computers by focusing on group membership.

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 is provided on when to use this tool versus alternatives (e.g., ldapdomaindump_users for users). The description does not include context or exclusions.

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

ldapdomaindump_ldd2prettyB

Convert ldapdomaindump JSON output to enum4linux-like readable format using the ldd2pretty utility.

ParametersJSON Schema

Name	Required	Description	Default
`outputDir`	No	Directory containing the JSON files from ldapdomaindump

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states conversion to readable format, without disclosing side effects, output destination, or any required permissions/authentication. Behavioral details are minimal.

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

Conciseness5/5

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

Single sentence, 15 words, front-loaded with the action and resource. No redundant information.

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?

Adequate for a simple one-parameter conversion tool, but lacks explanation of the output format or destination. With no annotations or output schema, slightly more context would improve completeness.

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% with the single parameter 'outputDir' having a clear description. The tool description does not add extra meaning 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.

Purpose5/5

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

Tool description clearly states it converts ldapdomaindump JSON output to a readable format, specifying the resource and action. It distinguishes well from sibling tools like ldapdomaindump_dump (which likely produces the JSON) and ldapdomaindump_read_output.

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 tool over alternatives; it only implies it is used after obtaining ldapdomaindump JSON output. No explicit when-not or alternative suggestions.

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

ldapdomaindump_policiesA

Get domain password policies and fine-grained password policies (PSOs). Returns lockout thresholds, password length requirements, etc.

ParametersJSON Schema

Name	Required	Description
`hostname`	Yes	Domain controller hostname or IP
`username`	Yes	Username in DOMAIN\username format
`password`	Yes	Password or NTLM hash
`authType`	No	Authentication type
`useSsl`	No	Use LDAPS connection
`outputDir`	No	Output directory

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral traits. It indicates a non-destructive read operation and returns specific policy details. However, it lacks disclosure of authentication behavior, error conditions, or potential side effects (e.g., network requirements). The description is minimal but adequate.

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

Conciseness5/5

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

The description is two sentences long, efficiently stating the purpose and return value. It is front-loaded with the main action and immediately useful information. No wasted words.

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?

Given the tool's complexity (6 parameters, 3 required, no output schema, no annotations), the description provides the essential purpose and return value but lacks context on how to use the parameters, connection behavior, and error handling. It is adequate for a simple tool but could be more complete for an LDAP interaction tool.

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?

Input schema has 100% coverage with descriptions for all 6 parameters. The tool description does not add extra meaning beyond the schema, nor does it need to because the schema is sufficient. Baseline score of 3 applies.

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

Purpose5/5

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

Description clearly states the tool's purpose: 'Get domain password policies and fine-grained password policies (PSOs)'. The verb 'Get' and specific resources (password policies, PSOs) distinguish it from sibling tools that focus on other aspects like computers, groups, or users.

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 tool versus alternatives. The description does not mention prerequisites, context of use, or when not to use it. For an LDAP tool, usage instructions (e.g., when to use with other ldapdomaindump tools) would be helpful.

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

ldapdomaindump_read_outputA

Read previously generated ldapdomaindump output files from Kali. Use after running a dump to retrieve specific results.

ParametersJSON Schema

Name	Required	Description
`outputDir`	No	Directory containing the dump output (default: /tmp/ldapdomaindump)
`fileType`	No	Type of files to read (default: json)
`fileName`	No	Specific file to read (e.g., 'domain_users.json')

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so the description carries the full burden. It discloses the read operation but provides no details about edge cases (e.g., missing directory, file not found), potential side effects, or performance implications. This is minimal transparency.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the action and purpose, with no redundant information. Every sentence earns its place.

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?

Given complexity (3 params, no output schema, no annotations), the description covers purpose and basic usage but lacks detail on return format ('retrieve specific results' is vague) and how it relates to sibling tools for specific output types.

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 description coverage is 100%, so the schema already documents all three parameters. The description adds no extra semantic value beyond what the schema provides (e.g., default values, enum options). Baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool reads previously generated ldapdomaindump output files from Kali, specifying both the action (read) and the resource (ldapdomaindump output files). It distinguishes from sibling tools like ldapdomaindump_dump which generates outputs.

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

Usage Guidelines4/5

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

The description gives explicit usage context: 'Use after running a dump to retrieve specific results.' This tells the agent when to use the tool but does not mention alternatives or when not to use it.

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

ldapdomaindump_trustsB

Enumerate domain trusts. Returns trust relationships between domains including trust direction and type.

ParametersJSON Schema

Name	Required	Description
`hostname`	Yes	Domain controller hostname or IP
`username`	Yes	Username in DOMAIN\username format
`password`	Yes	Password or NTLM hash
`authType`	No	Authentication type
`useSsl`	No	Use LDAPS connection
`outputDir`	No	Output directory

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It mentions returning trust relationships but fails to disclose authentication requirements, side effects, or what happens on failure. It is a read operation but does not confirm safety.

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

Conciseness4/5

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

The description is a single sentence with no wasted words, efficiently conveying the tool's purpose. However, it lacks structure (e.g., separate sections) which could improve readability.

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

Completeness4/5

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

Given the high schema coverage and the straightforward nature of the tool (enumeration), the description provides adequate context. It indicates the return type (trust relationships) and key attributes (direction, type), satisfying completeness for a simple lookup tool.

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 the input schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline of 3.

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

Purpose5/5

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

The description clearly states 'Enumerate domain trusts' with a specific verb and resource, and details the return values (trust direction and type). This effectively distinguishes it from sibling tools that enumerate other LDAP objects.

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 is provided on when to use this tool versus alternatives (e.g., ldapdomaindump_check, ldapdomaindump_computers). The description lacks context about prerequisites or when enumeration is appropriate.

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

ldapdomaindump_usersB

Enumerate domain users only. Returns user accounts with attributes like name, description, last logon, password expiry, etc.

ParametersJSON Schema

Name	Required	Description
`hostname`	Yes	Domain controller hostname or IP
`username`	Yes	Username in DOMAIN\username format
`password`	Yes	Password or NTLM hash
`authType`	No	Authentication type
`useSsl`	No	Use LDAPS connection
`outputDir`	No	Output directory

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It mentions return attributes but does not clarify authentication requirements, side effects (e.g., LDAP queries), data volume, or error behavior.

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

Conciseness4/5

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

Single, clear sentence. Efficient but could benefit from bullet points or more structure to separate context from usage.

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

Completeness2/5

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

Six parameters, no output schema, and no annotations. The description omits output format, pagination, prerequisites (e.g., credentials), and error handling.

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 baseline is 3. The description does not add meaning beyond the schema other than stating the general purpose of enumeration.

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

Purpose5/5

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

Clearly states it enumerates domain users and lists sample attributes. Differs from siblings like ldapdomaindump_computers and ldapdomaindump_groups by specifying 'users only'.

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 explicit guidance on when to use this tool vs alternatives. The sibling list implies differentiation, but no when-to-use or when-not-to-use conditions are provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv1.0.0May 27, 2026
- First observedldapdomaindump_check
- First observedldapdomaindump_computers
- First observedldapdomaindump_dump
- First observedldapdomaindump_groups
- First observedldapdomaindump_ldd2pretty
- First observedldapdomaindump_policies
- First observedldapdomaindump_read_output
- First observedldapdomaindump_trusts
- First observedldapdomaindump_users

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-27 19:45 across 9 tools

Disambiguation4/5

Most tools have clearly distinct purposes (check, dump, specific enumerations), but the full dump tool overlaps with the targeted enumeration tools (users, groups, computers, etc.). Descriptions help differentiate, but an agent might still be uncertain whether to use 'dump' vs. a specific tool.

Naming Consistency4/5

All tools share the 'ldapdomaindump_' prefix, and names are generally verb_noun or noun. However, mixed verb forms (e.g., 'check', 'dump', 'read_output') and the utility 'ldd2pretty' break strict consistency. Overall pattern is clear.

Tool Count5/5

9 tools is well-suited for an LDAP domain dump MCP server. Each tool addresses a distinct need without unnecessary bloat, covering installation check, full dump, specific enumerations, output conversion, and file retrieval.

Completeness5/5

The tool set covers the full lifecycle of LDAP domain reconnaissance: checking the tool, performing full or targeted dumps, converting output, and reading results. No obvious gaps exist given the read-only nature of the domain enumeration use case.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
27
emisarOAuth
dev.emisar
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Cloud Platforms Security Networking & Infrastructure
2354
STACKOAuth
io.github.getstack-run
Command your AI agents: verifiable passports, credential injection, full audit, revoke in 60s.
Security Autonomous Agents Agent Orchestration
2
browser-ssh
com.browserssh
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Shell Access File Systems
2

Related MCP Servers

BloodyAD MCP
Security Penetration Testing OS Automation
dcollaoa
A
license
Not graded
quality
C
maintenance
Enables Active Directory enumeration and abuse operations through the bloodyAD tool. Supports LDAP queries, user/group management, DNS operations, and security testing directly from AI assistants.
Updated a year ago (2025-09-27 14:27 UTC)
16
MIT
PentestMCP
Penetration Testing Security Command Line
YoussefSahnoun
A
license
C
quality
D
maintenance
Enables LLMs to perform Active Directory penetration testing using tools like NetExec, Bloodhound, Nmap, Certipy, and John the Ripper. Automates vulnerability discovery, attack path analysis, and documentation generation for security assessments.
Updated 10 months ago (2025-11-11 10:44 UTC)
26
6
MIT
john-the-ripper-mcp
Security Penetration Testing
schwarztim
A
license
A
quality
F
maintenance
Enables AI assistants to perform password security auditing using John the Ripper on a remote Kali system via SSH, supporting cracking, hash management, and session control.
Updated 4 months ago (2026-05-09 03:42 UTC)
12
MIT
theHarvester MCP Server
Penetration Testing Web Scraping
schwarztim
A
license
A
quality
F
maintenance
Enables AI assistants to perform domain reconnaissance using theHarvester OSINT tool, including email harvesting, subdomain discovery, DNS brute force, and Shodan integration, via SSH on a Kali Linux host.
Updated 4 months ago (2026-05-09 01:41 UTC)
8
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-ldapdomaindump-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

ldapdomaindump MCP Server

Overview

Architecture

Prerequisites

Installation

Configuration

Environment Variables

SSH Setup

Claude Desktop Configuration

Available Tools

ldapdomaindump_dump

ldapdomaindump_users

ldapdomaindump_groups

ldapdomaindump_computers

ldapdomaindump_trusts

ldapdomaindump_policies

ldapdomaindump_read_output

ldapdomaindump_ldd2pretty

ldapdomaindump_check

Usage Examples

Full Domain Dump

Enumerate Users Only

Pass-the-Hash Authentication

Output Files

Security Considerations

Troubleshooting

SSH Connection Failed

Authentication Errors

No Output Files

Related Tools

License

Disclaimer

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`ldapdomaindump_dump`

`ldapdomaindump_users`

`ldapdomaindump_groups`

`ldapdomaindump_computers`

`ldapdomaindump_trusts`

`ldapdomaindump_policies`

`ldapdomaindump_read_output`

`ldapdomaindump_ldd2pretty`

`ldapdomaindump_check`