It is Monday morning, and a learning administrator at a mid-sized company has a familiar list. Forty new hires start this week. Each one needs a Totara account, an enrolment in the mandatory compliance course, membership in the right audience, and a line manager who can see their progress. Then three managers have sent separate emails, each asking whether someone on their team has finished last quarter’s certification.
None of this is hard work. All of it is slow. Each task is a few clicks, a search, a confirmation screen, and then the same thing again. Across a week, that adds up to hours spent operating the system instead of improving the learning that runs on it.
The administrator already uses an AI assistant for drafting emails and summarising policy documents. The obvious question is why that assistant can’t do the clicking too. Why can’t she write “enrol this week’s new starters in Data Protection Essentials and tell me who’s already been enrolled” and get a correct answer from the live system?
The answer is that, until recently, there was nothing in between. There was no safe, standard way for an AI assistant to talk to Totara. Totara MCP, an open-source server built by the Edly team, is an early attempt to fill that gap.
The quiet gap in enterprise learning stacks
Over the last two years, AI assistants have moved from novelty to everyday tool in most organisations. They live in code editors, chat apps and desktop clients. But in enterprise learning, they have mostly stayed on the edge of the platform. They can write course descriptions and quiz questions. They can’t see who is enrolled in what, and they can’t take action.
The usual workarounds each have a cost:
| Approach | What it offers | Where it breaks |
| Copy-paste between the LMS and a chatbot | No setup | Slow and error-prone, and the AI never sees live data |
| Custom scripts against the LMS API | Precise automation | Needs a developer for every new task, and scripts pile up without anyone maintaining them |
| Bespoke AI integrations per vendor | Polished experience in one tool | Ties you to one assistant, and every new AI client needs its own connector |
| A standard protocol layer (MCP) | One connector that any compatible assistant can use | Only as good as the tools it exposes and the permissions behind them |
The last row is where the field is heading. Totara has not yet released an official MCP server of its own [VERIFY: confirm Totara’s public position on a planned official MCP server before publishing this line], so the layer is still missing for Totara customers today.
What MCP is, in plain terms
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, for connecting AI assistants to outside systems. A useful comparison is a universal power adapter. Instead of every AI tool needing its own custom plug for every piece of software, the software exposes one MCP “server”, and any MCP-compatible assistant can plug into it.
An MCP server publishes a set of named tools, for example “list courses” or “enrol a user”. Each tool comes with a description of what it does and what information it needs. The assistant reads those descriptions, decides which tool fits the request, asks for any missing details, and calls it. The server does the actual work against the real system and sends back a short, structured result.
The important point for decision-makers is that the AI never gets free access to the database. It can only do what the server’s tools allow, and only within the permissions the server itself has.
What Totara MCP does
Totara MCP is a small Python package, built by the Edly team and published on PyPI under the MIT licence, that acts as this MCP server for Totara. It talks to Totara only through its external GraphQL API, the official, versioned interface Totara provides for integrations. It does not use the older REST web services and it never touches the database directly.
Version 0.2.0 (released 22 October 2026) exposes 24 tools across nine areas of the platform:
| Area | What an assistant can do |
| Users | List users, look one up, create a new user |
| Courses | List courses, check completion status for a learner |
| Enrolment | Enrol, unenrol, and check whether someone is enrolled |
| Audiences | List audiences, check membership, add a member |
| Job assignments | List job assignments and look one up by job or by user |
| Organisations and positions | Browse and look up the organisational hierarchy |
| Programmes | List programmes and look up programme details and groups |
| Certifications | List certifications and look up certification details and groups |
| Seminars | List the seminars inside a course |
Taken together, these cover a lot of the routine operational questions an L&D team handles every day. Who in the Lahore office hasn’t completed onboarding? Which programmes changed this month? Is this person in the right audience? Those can now be asked in plain language and answered from live data.
It is just as useful to be clear about what Totara MCP does not do. It does not create courses. It is not a hosted service. It runs as a small local process next to the AI client, on the user’s own machine. The project describes itself as an early-stage MVP, built to grow with more tools as more Totara workflows need them.
The design choices that make it safe to use
The most interesting thing about Totara MCP is not how many tools it has. It is the set of restraints built into how those tools behave. Anyone who has watched an AI assistant confidently invent a username will see why these matter.
Totara’s permissions stay in charge. The server signs in with an OAuth 2.0 client credentials client set up by a Totara administrator. That client is linked to a specific Totara user, and every action is limited to what that user is allowed to do. If the linked account can’t enrol learners, neither can the AI. Governance stays where it already lives, inside Totara’s own role and capability system.
The AI is not allowed to make things up. When creating a user, the server insists on four real values: username, email, first name and last name. If any are missing, it does not let the assistant fill the gaps. It pauses and shows the human a form to supply them. If the client can’t show that form, the call fails with a clear list of missing fields, and no user is created. Cancelling the form also creates nothing.
Passwords never pass through the conversation. New accounts are always created with a password generated by Totara and emailed straight to the user. Neither the human nor the AI ever sees or types one.
Write actions wait for a human request. Changes such as unenrolling someone or adding them to an audience are meant to run only when the user has explicitly asked for that change. The tools also refuse ambiguous calls. An enrolment needs exactly one way of identifying the user and exactly one way of identifying the course.
Credentials never ship with the package. The site address and OAuth credentials live in each user’s local configuration. The published package contains none of them.
None of this makes the system foolproof, and responsible teams will still start with a test site and a narrowly scoped API account. But these are the right defaults, and they reflect a sound instinct: let AI do the operating, and keep humans in charge of authority.
Getting started
For a team that wants to try it, setup is short. A Totara administrator creates an API client under Development → API and links it to a suitably permissioned user. The person using the AI client then installs uv, a fast Python package runner, and adds an entry like this to their MCP configuration (for Cursor, ~/.cursor/mcp.json):
{
“mcpServers”: {
“totara”: {
“type”: “stdio”,
“command”: “uvx”,
“args”: [“totara-mcp”, “–transport”, “stdio”],
“env”: {
“TOTARA_BASE_URL”: “https://your-totara.example.com”,
“TOTARA_CLIENT_ID”: “your-client-id”,
“TOTARA_CLIENT_SECRET”: “your-client-secret”
}
}
}
}
After the MCP connection reloads, the assistant can see the Totara tools. Cursor is the documented client, but because MCP is an open standard, other MCP-compatible assistants should be able to use the same server [VERIFY: confirm which other clients have been tested, e.g. Claude Desktop]. The package needs Python 3.15 or later, which uvx can download automatically. On the Totara side, it relies on the external GraphQL API, available from Totara 17 onwards [VERIFY: README states Totara 17+, internal note says Totara 20+; confirm which minimum version to publish].
What this means for different readers
For L&D leaders and CLOs, this is a signal more than a finished product. Routine administration is starting to move from screens to conversations. That raises a new question for your team: which tasks should an AI be allowed to do, under whose authority, and with what audit trail? Starting that conversation now, on a test site, is cheap.
For Totara platform owners and administrators, it is a practical tool you can try this week. Read-only questions, such as listing programmes, checking completions and browsing the hierarchy, are a low-risk place to start and often the most time-consuming in practice.
For CIOs and security teams, the architecture is worth noting. Totara MCP uses only the official GraphQL API, authenticates through a dedicated OAuth client, runs locally, and inherits Totara’s own permission model. That is an integration pattern you can review, not a black box.
For EdTech product teams, it shows that open, protocol-based connectors are becoming expected. An LMS that can’t be reached by AI assistants will increasingly feel like an LMS without an API did a decade ago.
Built in the open
Totara MCP was built by the Edly engineering team, with Naveed Masood Butt as lead developer, and is published under the MIT licence. It comes out of Edly’s day-to-day work implementing and extending Totara for enterprise clients. Anyone can install it, read how it works, and extend it. It comes with an automated test suite that simulates Totara rather than calling a live site, covering authentication, token refresh, error handling and the exact request each tool sends. That is a sign of engineering discipline that matters more in early tools than their feature count.
It is also honest about being early. The project calls itself an MVP, and the tools reflect what real Totara workflows have needed so far. Feedback from teams running it against their own sites will shape what comes next.
Back to Monday morning
Go back to the administrator with forty new starters. With Totara MCP connected, her Monday looks different. She asks her assistant to check which of this week’s starters already have accounts. She confirms the details for the ones who don’t, because the system asks her instead of guessing. She has everyone enrolled in compliance training and added to the right audience, then pulls a completion summary for the three managers who emailed. Every action runs through her organisation’s own Totara permissions. Every new account gets a password she never sees.
The work is the same. The clicking is gone. That is what this missing layer was for.
Need Totara to do more for your organisation?
Totara MCP is one example of what the Edly team builds for Totara every day. Whether you need custom integrations with your HR or business systems, tailored workflows, reporting, or AI-enabled learning operations, our Totara specialists can design and deliver a solution that fits how your organisation actually works.
From AI-powered integrations to custom workflows and automation, Edly helps you unlock more from your Totara platform. Talk to Our Totara Experts
