Recently, I wrote about the Model Context Protocol (MCP) and how you can use it with Jan, and other open-source AI tools, and in that column I promised to give some more specific MCP examples. One of the most useful MCP tools for Microsoft 365 administrators is Lokka (https://www.lokka.dev), a free tool for working with Graph built by Microsoft’s Merill Fernando.
One of the biggest advantages of MCP tools is that they’re composable—you may not be familiar with the term, but if you’ve ever used a Linux shell or PowerShell by piping cmdlet output together, you’ve already experienced it. The original Unix shell tools were meant to be small, single-purpose tools that could be combined in useful ways; Jeffrey Snover explicitly tried to do the same thing with PowerShell, and that basic design pattern has carried over to MCP tools too. In this article, we’ll cover setting up Lokka and using it for basic queries, both by itself and in conjunction with other tools.
But First: What’s Lokka?
At its core, Lokka is a bridge between AI assistants and the Microsoft Graph API. If you’ve spent any time managing Microsoft 365, you know that Graph is the gateway to just about everything in your tenant—users, groups, SharePoint sites, Teams, Exchange, and more. The challenge has always been that working with Graph requires understanding REST APIs, authentication flows, and the right API endpoints. Lokka eliminates all that by letting you ask questions and make changes using natural language.
Think about the difference between two approaches. The traditional way is that you’d write a PowerShell script using the Microsoft Graph SDK (either on your own or with help from an AI), figure out the right cmdlets or API endpoints, handle authentication, parse the JSON response, and format the output. This would give you a script you could save and run later. With Lokka, you simply ask “Show me all SharePoint sites that haven’t been accessed in the last 90 days” and the AI figures out the right Graph calls to make and gives you the data. Once you develop a prompt that gives the results you like, you can store it and repeat it over again.
The beauty of this approach is that Lokka isn’t just for queries—if you grant it the appropriate permissions, it can also make changes to your tenant. For example, you can create security groups, update user properties, and modify SharePoint settings through natural language instructions. This is powerful stuff, which is why it’s critical to be thoughtful about the permissions we grant, but even without write permissions, Lokka can still be quite useful.
A Few Prerequisites
To run Lokka, you’ll need a few things. Start by installing Node.js version 22.10 or higher from nodejs.org if you don’t already have it.
Like many other MCP servers, Lokka needs to be hosted by an LLM-enabled tool of some form. You can use VSCode with GitHub Copilot, Claude Desktop, or Jan, which I described in my previous column.
Lokka must authenticate to Entra ID to make Graph queries. It supports three different modes: interactive authentication with MSAL (in which you’ll get a browser pop-up to authenticate, similar to the way that Graph Explorer works), app-based authentication (where you create a certificate or client secret and provide it to the local Lokka instance), or token-based authentication (where you capture a valid token and pass it to Lokka). The Lokka documentation covers setup for each of these three cases in detail.
You’ll need to configure your preferred LLM tool to use Lokka. Jan has a nice UI for this, or you can edit the claude_desktop_config.json file in Claude. Remember that you’ll need the application registration ID and Entra ID tenant ID (both available from the Entra portal), as well as the client secret or certificate data, to configure the LLM because Lokka expects those data items as environment variables.
Finally, you need to grant Lokka permissions as described in its documentation. If you’ve assigned Graph permissions for running scripts, Graph Explorer, and so on before, you’ll be familiar with this. For testing purposes, I strongly recommend using a development tenant and minimal permissions rather than your production environment. Microsoft offers free developer tenants through the Microsoft 365 Developer Program, and this gives you a safe sandbox to experiment without worrying about accidentally modifying production data.
Your First Queries
Once you’ve got Lokka installed and set with appropriate permissions, create a new chat and select your model. Before trying Lokka, let’s verify it loaded correctly. You should see Lokka-Microsoft listed among your available tools. Depending on your Jan version, this might appear in a tools panel, or you might see it when Jan requests permission to use a tool.
The first time you interact with Lokka, a browser window will open asking you to sign in to Microsoft and grant permissions. This is the delegated authentication flow I mentioned earlier. Review the permissions carefully—you’ll typically see requests for User.Read (to read basic user information) and potentially other scopes depending on what Lokka needs to do. Once you approve these permissions, the browser will redirect back to Jan, and you’re ready to go.
Let’s start with something simple: “Get all users in my tenant.” Jan will recognize that this requires calling Microsoft Graph, invoke the Lokka tool, and return a list of users. The response time will depend on your hardware and the size of your tenant, but even on modest hardware, you should see results within a reasonable timeframe.
Now let’s try something more specific for SharePoint: “Show me all SharePoint sites and their storage usage.” Lokka will query the appropriate Graph endpoint and format the results. This is already more convenient than hunting through the SharePoint admin center or writing a PowerShell script, but the real power emerges when you start chaining operations together.
Try this: “Which SharePoint sites are consuming more than 100GB of storage?” Notice what just happened—the AI understood your question, made the appropriate Graph call, and filtered the results. You didn’t need to know the specific Graph endpoint or how to filter the JSON response.
Troubleshooting
One of the joys of writing about AI is that most LLM-based tools dramatically simplify the troubleshooting process. Figure 1 is a great example: the LLM itself tells me what I did wrong and suggests exactly how to fix it. I look forward to a world in which I never see another stupid dialog that says “Oops, something went wrong” or tells me to report the error to my system administrator.

More to the point: Jan and Claude will both immediately throw errors if you misconfigure the parameters for Lokka, or if they’re not able to load the Lokka module. Assuming it loads, Lokka (and the LLM) should give you enough guidance to figure out what’s wrong.




@Paul:
I am running the same LLM “Jan-v1-4B-Q4_K_M” as you.
The output of “Get me 10 users in my tenant” is humanly unreadable (JSON):
“text”: “Result for graph API (beta) – get /users:\n\n{\n \”@odata.context\”: \”https://graph.microsoft.com/beta/$metadata#users\”,\n
\”@odata.nextLink\”: \”https://graph.microsoft.com/beta/users?$top=10\”value\”: [\n {\n \”id\”: \”xxxxx\”,\n \”deletedDateTime\”: null,\n \”accountEnabled\”: false,\n \”ageGroup\”: null,\n \”businessPhones\”: [],\n
How can I instruct the LLM to create a readable output like a formatted table?
Thanks.