Moodle plugin
What the plugin does
local_mcpconnector is the Moodle side of MoodleMCP. It links your site to the
panel over a signed API, creates role-scoped web services, and turns Moodle
tokens into revocable MCP keys for the users you choose.
It talks to the panel and to no other third party. It requires a MoodleMCP account: the plugin does nothing on its own.
Install
- Install the plugin from Site administration → Plugins → Install plugins
(upload the zip, or copy the directory to
<moodleroot>/local/mcpconnector) and complete the upgrade. - Open Site administration → Plugins → Local plugins → MCP Connector → License.
- Paste the panel URL, the license key, the panel secret and the MCP endpoint URL you got when you connected your site.
- Click Validate license. A green confirmation means the signature and the site URL both check out.
What it adds to Moodle
| Section | What it's for |
|---|---|
| License | Panel URL, license key, signing secret and MCP endpoint. |
| Services | The role-scoped web-service definitions and their allowed functions. |
| Users | Assign or remove a user from a service — this mints or revokes their key. |
| Keys | Per-user lifecycle: suspend, activate, revoke, regenerate + email, and reconcile status with the panel. |
| Settings | Per-role auto-sync and the key-delivery email template. |
Provision users
Under Users, assign a user to the service matching their role. The plugin mints a Moodle web-service token for them, sends it to the panel, and the panel returns an MCP key. The key value is emailed to the user and shown once — Moodle keeps only its last four characters and its status.
Turn on auto-sync for a role if you want every user holding that role to be provisioned automatically as they appear.
Revoke access
Suspending or revoking a key from the plugin propagates to the panel, and the key stops working on its next call. Deleting the Moodle user revokes it too. You can do the same from the panel side in Organization → Moodle → MCP keys — the two views reconcile.
What is sent to the panel
When you provision a user, the plugin sends their full name, their effective Moodle roles, and the web-service token minted for them; the key is emailed to their email address. The panel stores the token encrypted and the key hashed. The plugin's Privacy settings carry the machine-readable declaration.
Web-service tokens and MCP key values are never written to Moodle logs. Keys are delivered by email, so treat those mailboxes accordingly.
For plugin developers
Every plugin↔panel endpoint is signed and rate-limited per license:
| Endpoint | Purpose |
|---|---|
POST /api/moodle/verify | License and URL check from the plugin settings |
POST /api/moodle/keys | Register a token → MCP key (value returned once) |
POST /api/moodle/keys/list | Metadata-only listing (ids, last 4, status — never secrets) |
POST /api/moodle/keys/revoke | Revoke by key id (idempotent, terminal) |
POST /api/moodle/keys/suspend | Suspend or reactivate by key id |
The signature travels in a header:
x-panel-signature: t=<unix-seconds>,v1=<hex hmac_sha256(panelSecret, `${t}.${rawBody}`)>
- The signed payload is the raw request body, dot-joined after the timestamp — any body mutation invalidates the signature.
- Requests more than 300 seconds old (or ahead) are rejected, which closes the replay window.
- An unknown license and a bad signature both return
403 invalid_credentials, so the API can't be used to enumerate installs. - The plugin sends
x-panel-version: 2on every request, so the protocol can evolve without breaking older installs.
The plugin is GPL v3 or later; source and issues live at github.com/studiolxd/moodlemcp.