An AI Assistant That Can Use Moodle, Safely
Most of the AI a college sees is a chatbot sitting beside its systems. The useful version sits above them: an assistant that can look up a student, see what they have and have not submitted, find the grading queue for a module, and set up next term’s courses, using Moodle’s own web services and nothing else. We built that connector, and we run it against our own Moodle sites first.
A short list of named tools, not a login
The connector speaks the Model Context Protocol, the open standard that lets AI tools such as Claude call named functions. It sits in front of Moodle’s REST web services and exposes a curated set of tools. There is no generic pass-through: if a tool is not on the list, the assistant cannot do it.
The read tools let an assistant look up a student by username, email or ID number and see their enrolled courses and completion; see submission status for every assignment a student is enrolled in; list a course’s assignments, overdue assignments and the grading queue; summarise forum activity and a learner’s recent activity; and check that the site is healthy.
Writes, with the brakes on
A second tier of tools can change Moodle: create categories, courses, cohorts and users, enrol users and add cohort members. Each one is built so that a mistake is hard to make and easy to see. Every write runs as a dry run by default, so nothing changes until a person asks for the real run. Writes are idempotent: asking twice for the same course by its shortname creates it once. The assistant uses the names people use (shortname, username, ID number) and the connector resolves them to Moodle ids. Each write tool has to be switched on per college, and most start with reads only. Every executed write produces a structured audit line with secrets removed.
Moodle stays in charge
The connector is a control plane; Moodle remains the source of truth for permissions and data. Each college is a tenant with its own API keys, its own allow-list of tools and its own Moodle service token. That token is a normal web-service user with only the functions and capabilities the college enables, never a site administrator. A missing or wrong key is refused before any tool runs, and a tool that is not on the allow-list is refused at the tool layer. Timeouts, retries and error mapping are handled centrally, and the logs record function names and durations, never tokens. It runs in AWS in Ireland in the same way as our other services.
The same pattern for student systems
Moodle was the first. We have built the same kind of connector for the student systems we run, so an assistant can answer a question that spans several of them: programme details, course enrolments and a financial summary from the student record; accounts, applications and cases from Salesforce; and a governed query tool for staff who already have that access. Each tool reads from the system of record at the moment it is asked; nothing is copied into the assistant. Our own website has a connector too, which is how this site was rebuilt by an AI agent.
What it looks like in use
A programme administrator opens Claude with the college’s connector attached and types a question. “Which of my second-year students have not submitted anything in three weeks?” comes back as a list with the tool calls that produced it. “Set up the September intake courses from this spreadsheet” comes back as a dry run to check before it runs for real. Each answer shows where every number came from.
Where to start
A read-only tenant against a copy of your Moodle takes days, not months, and answers the questions that matter: whether staff use it, which questions it answers well, and which tools you would switch on next. That is the first step in our AI Readiness Assessment. We run this connector against our own Moodle sites first, which is how we know where the edges are. You can read more about how we use AI at Inneall.