MCP server for 389 Directory Server health diagnostics, log analysis, and SOS-report investigation
The server has 3 visible tools with mixed quality. All three have substantive descriptions (100-150 chars, well above the 10-char minimum), but only 2 of 3 have explicit input schemas visible in the provided source. Naming follows verb_noun convention (list_, describe_, whoami). Descriptions clearly state WHAT each tool does and WHEN to use it. However, input parameter descriptions are minimal or missing entirely, and output schemas are not documented. The whoami tool's input schema is present but lacks description on the server_name parameter. Error handling guidance is absent, no recovery instructions for common failures. Overall quality is above-average for community servers but falls short of production grade due to missing parameter details and undocumented output structures.
Show the stored connection settings (hostname, port, SSL, base DN, auth method) for a configured OpenLDAP server. Reads configuration only — does not contact the server. Uses the default server when ``server_name`` is omitted.
List all configured servers with their connection modes. Returns each server's name, mode (live/offline/archive), and key properties. Use this to discover which server name to pass to other tools — especially archive and offline tools that require a non-live server.
Verify credentials by binding to the OpenLDAP server and returning the authenticated identity (LDAP Who Am I). Performs a live bind; supports simple and SASL EXTERNAL auth only (other methods raise an error). Uses the default server when ``server_name`` is omitted.
list_servers tool lacks any input schema definition in visible source; no parameters documented or structured.
Parameter descriptions missing or absent. For both describe_connection and whoami, the server_name parameter has minimal or no guidance on format, valid values, or default behavior. This leaves LLMs guessing whether to pass a hostname, a config label, or an ID.
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract fields if they do not know what fields the response contains. list_servers should document the structure of server objects (name, mode, properties). describe_connection should document connection settings fields. whoami should document the identity response format.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
No error recovery guidance. Descriptions do not explain what to do if a tool fails (e.g., 'If server_name is invalid, call list_servers first to see available servers'). This forces LLMs to guess when recovering from errors.
whoami tool name is ambiguous to LLMs unfamiliar with LDAP terminology. 'Verify credentials' or 'check identity' would be clearer for multi-domain agent use; a pure LDAP tool can keep whoami, but should add '(LDAP Who Am I)' to the description to disambiguate.