RedHatLDAP-MCP

Overview Schema Source Related Servers Score Discussions Admin

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources or actions, but search_people and search_people_summary (and the two organization chart variants) are intentionally similar and could be confused. The descriptions clearly distinguish them by output detail and token usage, so misselection is unlikely but possible.
Naming Consistency4/5
Tool names consistently follow a verb_noun pattern (search_, get_, find_, test_). Minor inconsistencies exist between singular/plural forms like person vs people and synonym verbs like search vs find, but the overall pattern is predictable.
Tool Count5/5
12 tools is well-scoped for an LDAP directory server, covering people, groups, organizational hierarchy, locations, and connection testing. Each tool serves a clear purpose without unnecessary bloat.
Completeness4/5
The tool set provides strong read-only coverage of the corporate directory domain: people search and details, org charts, management chains, groups, and locations. Minor gaps like direct-reports lookup or dedicated group details are workable through existing tools.
Average 3.5/5 across 12 of 12 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure, yet it only restates the tool name. It reveals nothing about read-only behavior, required permissions, response format, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically short but is under-specified rather than concise. It contains no useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what 'person details' includes and how to invoke it correctly. The single tautological sentence is completely inadequate for an 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?
The input schema provides a clear description for the identifier parameter ('uid, email, or DN'), achieving 100% schema coverage. The tool description itself adds no parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Person Details' is a tautology that simply restates the tool name. It provides no verb, resource, or scope clarification beyond what the name already conveys.
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?
The description offers zero guidance on when to use this tool versus alternatives like search_people or get_person_details. No conditions, exclusions, or invocation context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention whether the tool is read-only, has side effects, permissions, or any limitations. Since the description is the only source of behavioral information, this is a significant gap.
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, short sentence that immediately conveys the tool's purpose without verbosity. It is appropriately concise, though it could include a bit more context without becoming wordy.
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?
While an output schema exists, the description fails to provide any context about how the tool fits into the broader set of siblings, what kind of results to expect (beyond 'locations' and 'people counts'), or when it should be preferred over alternatives. The lack of usage context makes it incomplete for an agent to decide when to invoke it.
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 schema covers 100% of parameters with the description 'Location search query', which gives basic meaning to the single parameter. This meets the baseline for a well-documented schema, but the description does not elaborate on expected format, examples, or potential values beyond 'query'.
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?
The description clearly states the verb 'Find' and the resource 'office locations' with 'people counts', making the primary purpose understandable. It does not explicitly distinguish it from similar tools like get_people_at_location, but it is specific enough to convey the core intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings, such as get_people_at_location or search_people. The description lacks any context about filtering, search behavior, or typical use cases, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no mention in the description of side effects (e.g., read-only, permissions, or rate limits), the agent lacks transparency about the tool's behavior. It is a search, but that is not explicitly stated as non-mutating.
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, clear sentence with no unnecessary words. It is concise and delivers the core purpose efficiently.
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 search tool, the description is adequate but lacks details about the output (e.g., what format the results take or what fields are returned). The existence of an output schema is indicated, but the description does not hint at it, leaving some context missing.
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 schema provides descriptions for both parameters ('Group search query' and 'Maximum number of results'), covering 100% of the parameters. The description adds no extra meaning beyond the schema, so it meets the baseline of 3.
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?
The description clearly states the verb 'search' and the resource 'groups' within a 'directory' context. It is not tautological and gives a specific action and target, though it does not differentiate from sibling tools like 'search_people'.
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. It does not mention that 'search_people' should be used for people or any other conditions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the operation is read-only, how results are ordered, whether pagination occurs, or any side effects. The simple verb 'get' suggests read-only, but this is not explicit.
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 a single concise sentence with no extraneous information, effectively conveying the tool's core function.
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?
For a simple tool, the description and schema provide adequate information for invocation. No output schema is present, but the rule exempts return-value explanation. Minor gaps like match semantics (exact vs. partial) prevent a perfect score.
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 descriptions cover both parameters (location and max_results) at 100% coverage, providing basic meaning. However, the descriptions are minimal ('Location name', 'Maximum number of results') and lack details on format, units, or constraints, aligning with the baseline score 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 'Get all people at a specific location' clearly states the action (get) and the resource (people at a location), distinguishing it from sibling tools that search people generally or retrieve individual details.
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 is provided on when to use this tool versus alternatives like search_people. The description implies location-based retrieval but does not state conditions for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no mention of side effects, permissions, or read-only nature, the description relies solely on the verb 'Get' to imply a safe operation. It does not explicitly disclose any behavioral traits such as whether it returns nested members or only direct members.
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 a single, straightforward sentence with no unnecessary words. It is concise and easy to parse.
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?
While the description is adequate for a simple retrieval, it does not mention what the returned members look like, whether the result is sorted, or any edge cases (e.g., group not found). The output schema exists but is not referenced in the description.
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?
The parameter group_name is described as 'Group name or DN', which clarifies the accepted format and adds value beyond the basic schema. This is helpful for selecting the correct identifier.
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 action ('Get') and the target ('all members of a specific group'), which distinguishes it from sibling tools like search_groups or get_person_groups. It is specific and unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives, such as search_groups or get_person_groups. There is no mention of use cases, prerequisites, or contrasting conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects, permissions, or limitations. It only says 'search', which implies a read-only operation, but does not explicitly state that it makes no modifications, nor does it mention any required auth or rate limits. This lack of explicit transparency is a gap.
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 concise and well-structured. It states the purpose in one sentence and then lists the supported search fields in a clean bullet list. There is no redundant or extraneous information, making it efficient and easy to parse.
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 that an output schema is indicated as present (though not shown), the description does not need to explain return values. It adequately covers what the tool does and the main input parameters. However, it lacks explicit usage context or constraints (e.g., whether partial matches are supported, or if certain fields require combinations), but this is minor given the tool's simplicity.
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?
The schema already provides basic descriptions for 'query' and 'max_results'. The description adds valuable meaning by enumerating what the query can contain (name, email, uid, employee ID, department), which enriches the understanding of the query parameter beyond the schema's generic text. This justifies a score above 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 the action ('Search for people') and the resource ('corporate directory'), and lists specific searchable fields (name, email, uid, employee ID, department). This distinguishes it from sibling tools like search_groups or find_locations by resource type.
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?
The description does not provide guidance on when to use this tool versus alternatives such as search_people_summary or get_person_details. It only lists search criteria, which informs the query parameter but not the choice between related tools. No 'use this when' or 'instead of that' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It mentions testing the connection and returning status, but does not specify whether the operation is read-only, if authentication is required, or what side effects (if any) may occur.
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 a single, clear sentence that effectively conveys the tool's purpose without unnecessary 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?
The tool has no input parameters and a simple output (connection status). The description sufficiently explains the purpose and result. Since an output schema exists, there is no need to describe return values in the description. Complexity is low, so the description is complete.
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 tool has no parameters, so there is nothing to describe. Given the schema coverage is high (all zero parameters documented), a 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?
Description clearly states the tool's function: testing the LDAP connection and returning its status. This is specific and distinct from sibling tools which handle search and retrieval of people, groups, and organizational data.
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?
Description does not explicitly state when to use this tool versus the sibling tools. While it is implied that this tool is for connectivity verification rather than data operations, no direct guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states that a hierarchical view is returned, which implies read-only behavior, but it does not disclose potential limitations like depth default behavior, cycle handling, or permission requirements. The description is adequate but not fully transparent.
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 concise, consisting of two clear sentences without redundancy or fluff. It efficiently conveys the tool's purpose and output, making it easy to parse quickly.
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?
The description provides a succinct overview of the output (hierarchical view) and the starting point (specific manager), which is sufficient for basic understanding. It does not elaborate on output format or edge cases, but given the simplicity of the tool, it is adequately complete.
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 covers 100% of parameters with descriptive names and descriptions (e.g., manager_id as 'uid, email, or DN', max_depth as 'Maximum depth to traverse'). However, the tool description itself adds no additional meaning beyond the schema, so the score aligns with the high-coverage 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 the tool's function: retrieving an organization chart starting from a specified manager and returning a hierarchical view. It is distinct from sibling tools like get_organization_chart_summary, which likely provides a summary, and find_manager_chain, which focuses on upward chains.
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 does not explicitly specify when to use this tool over its siblings. While the purpose is self-evident for fetching a full org chart, there is no guidance on scenarios such as comparing with get_organization_chart_summary or when max_depth should be adjusted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the burden of disclosing behavior. It indicates a read-only 'Find' operation, which is non-destructive. It does not mention edge cases (e.g., no managers found) or whether the result includes the person themselves, but for a simple query this is acceptable.
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 a single, concise sentence that conveys the essential purpose without any fluff or redundancy. It is well-structured and easily parsed.
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?
For a simple query with one fully described parameter and no output schema, the description plus schema is sufficient for an agent to understand what the tool does. It could optionally mention the output format, but that is not necessary for basic invocation.
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 fully describes the single parameter person_id as 'Person identifier (uid, email, or DN)', giving complete coverage. Since schema coverage is 100%, the baseline is 3. The description adds no extra semantic detail beyond the schema.
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 action ('Find') and the resource ('management chain for a person'), with a clarifying parenthetical ('all managers up to the top'). It is easily distinguished from sibling tools like get_person_details or get_organization_chart, which serve different purposes.
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 implies when to use the tool—when a user needs the full chain of managers rather than a single person's details or a full org chart. However, it does not explicitly mention alternatives or state 'use this instead of X when...', so it falls slightly short of full explicitness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the output shape ('hierarchical view with minimal person data: uid, name, title, department, country') and the benefit ('reduced token usage'). It does not mention error handling or edge cases, but for a read-only operation this is adequate. It adds value beyond the schema by explaining the lightweight nature.
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?
Two sentences with no fluff. The first sentence states the purpose and core benefit, the second describes the output and the ideal use case. Everything earns its place, and the most important information is front-loaded.
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 output schema exists and annotations are absent, the description adequately covers the tool's purpose, output fields, and use case. It doesn't mention pagination or limits on max_depth, but for a summary read tool this is a minor gap. Overall, an agent has enough information to call it correctly.
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 baseline is 3. The description does not add any details about parameters beyond what the schema already provides (manager_id as identifier, max_depth with default). It mentions 'depth' only implicitly through the hierarchical view, but no additional semantic enrichment is given.
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 a specific verb+resource: 'Get lightweight organization chart for reduced token usage.' It explicitly distinguishes itself from the sibling get_organization_chart by emphasizing 'lightweight' and 'minimal person data,' making its purpose unambiguous.
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?
It provides a clear context for use: 'Ideal for large organization charts where token usage is a concern.' This implies when to prefer it over the full chart, though it does not name the alternative tool explicitly or state when not to use it. The condition is direct enough for an agent to infer the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description indicates a read-only 'Get' operation but does not explicitly state side effects, permissions, or rate limits. The minimal description gives partial transparency, but more detail could be added.
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 a single, concise sentence that directly states the tool's function without unnecessary fluff. It is well-structured and easy to parse.
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?
Although there is no output schema, the description implies the response will contain groups. Given the simplicity of the operation, this is adequate, though explicit output format details could improve completeness.
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?
The single parameter 'person_id' has a description explaining accepted formats (uid, email, or DN), which adds meaning beyond the schema's type. This is clear and sufficient for the tool's purpose.
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 'Get' and the resource 'all groups that a person is a member of,' distinguishing it from sibling tools like get_group_members (which retrieves members of a group).
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 implies when to use the tool (to find groups for a given person), but does not explicitly compare it with alternatives like get_group_members. Still, the purpose is clear enough for an agent to infer the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns minimal person data and lists the fields, making the read-only nature of a search implicit. However, it does not explicitly state that no data is modified or mention any side effects, which would have earned 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core purpose stated first and supporting detail second. There is no redundancy or extraneous information, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is self-contained: it states the return fields, the use case, and the difference from full-detail search. It does not mention pagination, errors, or explicit tool selection, but the simplicity of the operation and the provided schema make it sufficient for correct 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?
The schema already fully describes both parameters ('query' and 'max_results'), so the baseline is 3. The description adds no extra semantic detail beyond restating the purpose, though it does clarify the return format.
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 the tool searches for people and returns lightweight summaries, explicitly contrasting with 'full details' to distinguish it from the sibling search_people. The verb 'Search' and resource 'people' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit usage condition: 'Ideal when you need to search many people but don't need comprehensive information.' This directly tells the agent when to choose this tool over alternatives, and the contrast with 'full details' reinforces the selection logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

RedHatLDAP-MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![RedHatLDAP-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/jlaska/RedHatLDAP-MCP/badges/card.svg)](https://glama.ai/mcp/servers/jlaska/RedHatLDAP-MCP)

Score Badge

Copy to your README.md:

[![RedHatLDAP-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/jlaska/RedHatLDAP-MCP/badges/score.svg)](https://glama.ai/mcp/servers/jlaska/RedHatLDAP-MCP)

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/jlaska/RedHatLDAP-MCP'

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