InforcerCommunity MCP: Ask Your AI Assistant About Your Inforcer Tenants
A while back I published the InforcerCommunity PowerShell module, which wraps the Inforcer REST API in cmdlets. This is the other half of that idea.
InforcerCommunity MCP connects an AI tool to the Inforcer REST API, so you can ask about your own tenant data in plain language:
“Which of my tenants are furthest from their baseline?”
“In Contoso, which policy controls password expiry?”
“Do all of my customers block legacy authentication?”
Your AI tool cannot normally see any of that, and this connects the two.
InforcerCommunity MCP was created by me for the community. It is an independent, community-driven project to make the Inforcer REST API easier to reach from the AI tools you already work in, and it is not owned, endorsed, or maintained by Inforcer.
Table of Contents
- What is an MCP server?
- What you can ask about your Inforcer tenants
- Finding a setting when you do not know the policy name
- Read-only by default
- Where your data goes
- Installing the InforcerCommunity MCP server
- MCP or the PowerShell module: which one do I use?
- Links
What is an MCP server?
MCP stands for Model Context Protocol. It is a standard way of giving an AI tool access to a system it would otherwise know nothing about. You install a small “program”, your AI tool discovers what it can do, and from then on it can fetch real data instead of guessing at it.
That is all this is, and on your side it is really just configuration: one block in your AI tool’s settings, pointing at something that speaks the Inforcer REST API on one side and MCP on the other. There is nothing to download by hand, and you never call it yourself. You ask your AI tool a question, it works out which part of the Inforcer REST API answers that question, and the answer comes back in the conversation.
It runs on your own machine. Your AI tool starts it when it launches and stops it when you close it, so there is nothing hosted and no address to connect to.
What you can ask about your Inforcer tenants
Most of what Inforcer holds is reachable: tenants, baselines, policies, alignment scores and details, users, groups, roles, secure scores, the activity log, reports and assessments.
Worth setting expectations on first: the MCP only supports what the Inforcer REST API supports. It is a wrapper, not a second source of data. If something is visible in the portal but has no API endpoint behind it, you cannot ask about it here either.
Within that, you never have to learn a command or look up an ID. Use tenant names like “Contoso” and ask for what you want:
| Ask something like | And you get back |
|---|---|
| “List my tenants and their alignment scores” | Every tenant with its baseline alignment percentage and its secure score |
| “Where does Contoso deviate from its assigned baseline?” | Each policy in that tenant that no longer matches its baseline, and what differs |
| “Show me Contoso’s Conditional Access policies” | The CA policies in that tenant with their state, conditions and grant controls |
| “Which policy in Contoso controls password expiry?” | The policy that actually holds that setting, and the value it is set to |
| “Who holds Global Administrator in Contoso?” | The members of that role, with their display names and sign-in names |
| “What licences does jane@contoso.com have?” | That user’s assigned licences, plus their groups, roles and devices |
| “What’s Contoso’s secure score, and is it improving?” | The current score out of its maximum, with the history behind it |
| “What changed in Contoso in the last 30 days?” | Activity log entries for that period, filtered by event type |
What makes it useful is that it hands your AI tool the actual numbers and policy data, not a pre-written answer. The tool does the interpreting, so a follow-up question about the same data gets you something genuinely different back rather than the same paragraph reworded.
Ask it to list your tenants with their alignment scores, and you get the numbers:
| Client | Baseline alignment | Secure score |
|---|---|---|
| Contoso | 91.5% | 412 / 600 |
| Fabrikam | 80.9% | 388 / 600 |
| Northwind | 57.9% | 301 / 600 |
Then ask which three you should review first, and it reasons over the data it already has: Northwind first, because 57.9% is the widest gap in the portfolio, then Fabrikam, which has drifted since its last alignment run. No second round of API calls, and no answer you could have written in advance.
It is also multilingual, and that comes for free rather than as a feature. Because what comes back is data rather than finished sentences, your AI tool answers in whatever language you asked in. A question in Dutch gets a Dutch answer. Policy names stay exactly as Inforcer reads them.
There are more examples, and the awkward cases, in the examples guide.
Finding a setting when you do not know the policy name
You do not need to know what a policy is called to find it. Describe the setting you are after and ask whether anything in the tenant configures it:
“Is there anything in Contoso that controls password expiry?”
“Which policy in Fabrikam blocks legacy authentication?”
Phrased that way, your AI tool searches inside the policy settings and comes back with whichever policy holds it, whatever name it happens to have.
That is the useful habit to get into, because policy names rarely describe what is inside them. A policy that turns off passkeys might be called anything at all. So if you search by name and get nothing back, the only thing you have learned is that no policy has that name - not that the setting is missing. Ask what a policy does rather than what it is called, and you get a real answer.
Read-only by default
The MCP ships read-only. Everything that could change something in a tenant is refused, so there is nothing you can accidentally reconfigure by phrasing a question badly.
There is also nothing to switch on today. The Inforcer REST API offers no way to change a client’s settings, so neither does this. The setting that would permit writes exists and is listed in the setup guide, but until the API grows those endpoints it does nothing - and enabling it would stay a human decision at a file on your own machine rather than something an AI tool could choose for itself.
Where your data goes
Nothing is hosted, and the only outbound calls are to the Inforcer REST API.
How your API key is stored depends on how you set it up. The VS Code one-click button hands it to VS Code’s own password store rather than writing it into a file, and it never reaches your browser history either. With the JSON block the key lives in your AI tool’s settings file, and the accounts file option exists for keeping it out of the file most likely to get synced between machines or pasted into a support ticket.
The part worth understanding is the path your client data travels, because there is no anonymisation anywhere along it. When you ask a question, the MCP calls the Inforcer REST API, Inforcer pulls the data from the tenant at that moment, and it comes back through the MCP into your AI tool’s context. From there it goes on to your AI provider and into your AI tool’s own saved conversation history on disk. Real tenant names, real user names, real email addresses, at every one of those hops.
The full detail, including what is not promised, is in SECURITY.md.
Installing the InforcerCommunity MCP server
You need two things: an Inforcer API key from the portal, and the region that key belongs to (uk, eu, us or anz). A key works in exactly one region, and the wrong region fails in a way that looks identical to a wrong key, so check that first if nothing works. It runs on every platform.
In VS Code it is a one-click button in the README. For Claude Code it is one command:
claude mcp add inforcer -s user \
-e INFORCER_API_KEY=your-api-key \
-e INFORCER_REGION=uk \
-- npx -y inforcercommunity-mcp@latest
For Claude Desktop, Cursor and more it is one block in the settings file:
{
"mcpServers": {
"inforcer": {
"command": "npx",
"args": ["-y", "inforcercommunity-mcp@latest"],
"env": {
"INFORCER_API_KEY": "your-api-key",
"INFORCER_REGION": "uk"
}
}
}
}
Then restart your AI tool, because it only reads its settings when it starts, and ask it to run inforcer_status. If that comes back with "state": "ok", you are done. Ask it to list your tenants and you should see them.
You do not have to maintain any of this. Because the config points at @latest, every new version I ship is picked up on its own the next time your AI tool starts, so fixes and newly supported endpoints arrive without you touching the file. Updates land at startup rather than mid-session, so if you have had the same session open for days, restart it to get the newest one.
Everything past that point lives in the repo: which AI tools are supported and where each one keeps its settings, the optional settings, the per-platform notes, and how to run two Inforcer accounts side by side are all in the setup guide.
MCP or the PowerShell module: which one do I use?
The MCP answers questions. The PowerShell module produces artefacts. Full tenant documentation, a side-by-side Intune comparison, a multi-tenant assessment matrix or a scheduled csv are all module jobs, and the MCP will tell you so rather than trying.
The rough rule: if the output belongs in a conversation, ask the MCP. If it belongs in a file you hand to somebody else, run the module.
Links
- GitHub: https://github.com/royklo/inforcercommunity-mcp
- PowerShell module: blog post and repo
Bugs and feature requests go in the issues. Issues are public, so never paste your key, and strip client names first. The most useful report you can send is a question that got a bad answer, because that almost always means a tool description is wrong.
Related
- InforcerCommunity: A PowerShell Module for the Inforcer REST API - the other half of this idea, for when you need a file rather than an answer.