[389-users] Re: [ANN] LDAP Assistant MCP v0.2.0 - AI-Powered 389 DS Diagnostics

On Mon, Jan 5, 2026 at 6:34 PM William Brown <wbrown@suse.de> wrote:

That's the intention. And generally, I don't plan it any time soon as it's the least desired feature. Reindex and fixup tasks? That might be sooner, but still it'll be guarded with the switch with the default to 'false'.

Even then, LLM's have been shown to bypass and avoid developer implemented limits. I'd be very hesitant about this. For example, a reindex task takes your instance temporarily offline. What if the LLM decides a reindex is needed before you gave it consent? What if it reindexs all your systems in parallel rather than one at a time? Even this is potentially an outage in the making.

Your concern is valid... If those ever get implemented, they'd need explicit confirmation flows, not just a feature flag. But that's a bridge to cross later, if at all.

 

 

- Privacy mode - Set LDAP_MCP_EXPOSE_SENSITIVE_DATA=false to anonymize output

Privacy should be the default IMO, especially given how LLMs may harvest data. 

It is default to not provide any sensitive data to LLM. It can be turned off for cases (ideally) when the model is local, for example.

Okay, it wasn't clear in how you wrote it. 

Yeah, I can see it now. It was the afternoon of December 31st, if that excuses my mistake. :D 

 

Honestly? I don't think we should have MCP anywhere near 389-ds. I know that you will have worked a lot on this, and I'm sure there was a "business reason" your employer probably wanted you to implement this for.

But as I have said - LDAP is a high value, important, and critical piece of infrastructure in many environments. If LDAP stops - the business stops. 

To have an MCP/LLM trying to "summarise and advise" about how one of the most critical pieces of software in an environment works seems like a recipe for disaster.

As a former sysadmin, I would not want MCP anywhere near systems. Systems require insight, understanding, and thought to manage. Systems do not need "statistically plausible sentence generators". 

There are many ways we can make LDAP and 389-ds easier and more accessible to administrators, to assist them with understanding the state of their systems. But MCP/LLMs are not it. 

I appreciate the thoughtful feedback, and I think you raise valid concerns about AI and critical infrastructure. But I'd push back a bit on the framing here.

This isn't about having an LLM "advise" on how to run your directory service, or make autonomous decisions about your topology. It's a read-only diagnostic wrapper around lib389.

Think about what the tool actually does - it calls healthcheck, parses replication status, looks for unindexed searches in logs (not LLM parses, lib389 parses, - LLM gets only the 'yes or no' answer - and more if sensitive is off), gives monitor output. These are things you'd do yourself with dsconf or by reading documentation. The MCP layer just lets you ask "are there any unindexed searches?" instead of remembering the exact incantation to grep the logs or which dsconf subcommand to use. lib389 does the job and we are making sure it's correctly implemented. The human still sees the output (and MCP logs for the exact lib389 output). The human still decides what to do. The human still runs dsconf or edits dse.ldif themselves. Nothing writes to the directory.

You're right that LDAP is critical infrastructure. You're right that LLMs make mistakes. But there's a difference between "AI agent manages your LDAP topology" and "natural language interface to lib389 that returns diagnostic information." This is the latter.

The concern is that the diagnostic information may be *altered* or *misrepresented*. This isn't just "calling healthcheck" - it's calling healthcheck with a transformation layer in between that *can* and *will* alter that output. And that transformation layer is a "statistically plausible sentence generator" so your framing of how you make a request can cause that data to be altered. 

And that's the problem - if the LLM tells you what you want to hear, or alters the data, it may mask a critical or important detail in it's output. This prevents the human from being able to intervene, investigate, and understand the situation.

If your concern is that sysadmins will blindly trust LLM output without verification - that's a valid concern, but it's also true of any documentation, any Stack Overflow answer, any vendor support response. The tool surfaces information; it doesn't replace the judgment needed to act on it. That judgment was always required - with or without MCP. For experienced admins who understand what they're looking at, I think it can be a useful convenience.

As an experienced admin, this would be a hinderance - not a convenience. I would forever be doubting if the surfaced information is truthful or not. 

There are better ways we can surface information about 389-ds to promote transparency and understanding for our admins and users. Again, in my view, this is not it. 

I don't think it's a hindrance - let me describe the workflow I have in mind.

You're investigating an issue. You ask the model to check something (replication status, healthcheck, performance metrics, etc.) across the whole topology. It makes the lib389 calls, gathers the data, and presents you with a graph or table giving you a basic picture of the issue you're investigating. Then you go to dsconf and confirm what you're seeing. (I might add dsconf commands to the output that would produce the same result, where such commands are available.) The admin still does the real work - the MCP layer just gets you to the starting point faster.

About plausibility: the key thing is that we have the lib389 data. It's accurate data from the server. Just to make my point - ask any modern LLM to remember a number, then add 200 to it. It'll get it right 99.99% of the time. That's essentially what this does: user asks a question, lib389 gathers accurate data, LLM represents those accurate numbers in a more digestible format. With current tech, there's arguably less chance of error than an unfocused administrator parsing raw output after a night with no sleep.

And to be clear - with that information, the admin should do nothing except go to their server with dsconf and continue the investigation there. This doesn't replace that step; it accelerates getting to the specifics of it. In some cases it might save hours, not just minutes.

For something simple? No need for the LDAP MCP Assistant. For more complex and specific cases? Can an admin go through the topology manually with dsconf, collect reports, gather attributes, and juggle through all that information for their specific case? Of course they can. Will it be tedious? Probably. We (389 DS devs) might cover some situations where that initial information representation saves time, we might not. But for the cases where it does help, MCP saves a lot of initial kickstarter time for the investigation.

The tools will be tested and tuned, and the docs will advise caution. The MCP goal in general is to help engineers design tools that are as precise (hence helpful) as possible. From my testing, I think it provides enough benefit to be used as a helper tool - a "junior admin" you ask for simple tasks, who may save you time in complex data-gathering situations.

Regards,

Simon

-- 
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia