One connector URL per connection
Your organization can hold several Moodle connections, and each one has its own connector URL: the organization's subdomain, plus the connection's slug in the path.
https://<your-organization>.slxd.app/mcp/lmsmcp/<connection>
If you work in a personal workspace rather than a shared organization, the URL carries no subdomain:
https://lmsmcp.slxd.app/mcp/lmsmcp/<connection>
You don't need to build the URL by hand: the panel shows it with a copy button on the connection's page, under Connector URL, and in the connections list in Organization → Moodle. If you were provisioned from the plugin, it also arrives by email alongside your key.
Which URL you point the assistant at is what decides which Moodle it talks to. A key belongs to one connection, so presenting it against a different connection's URL is refused.
It speaks the standard MCP Streamable HTTP transport, so any compliant client can connect. Per-client instructions are in Client setup.
Two ways to authenticate
Pick whichever fits your client. If you use ChatGPT or Claude — the most common case — the first route is for you.
Sign in with your Moodle (OAuth) — recommended
This is the route for ChatGPT and Claude (both claude.ai in the browser and Claude Desktop), and the recommended one whenever your client supports it. Add the connector URL as a remote MCP connector; the first time you connect, a browser window opens — choose Sign in with your Moodle, log in on your own Moodle and approve.
From there the assistant is bound to your identity and roles in Moodle. There is no key to copy, store or email, so there is nothing that can leak. Re-authorizing, or revoking the underlying key, cuts the connection.
An MCP key
For clients that accept a token (Cursor, Claude Code, scripts, CI): send the key as a Bearer header. Owners and admins mint keys in Organization → Moodle → MCP keys, choosing the connection the key is for, and the plugin can email one to each provisioned user. The value is shown once.
What happens on every call
Whichever route you took, the MCP server resolves the connection from the URL and executes Moodle web-service functions against that site, with your stored token and roles. Authentication is checked on every request, so a revoked, suspended or expired credential is cut off on its very next call — there's no session to expire.
Every call, direct or routed through the gateway tools, goes through the same hardened Moodle client (SSRF-pinned connections, request timeout and a streaming response-size cap) and the same role gate. What a key may do is covered in Keys & permissions.
No client? Use the panel
The panel's AI chat uses the same tool catalog with no client setup at all, which is useful for confirming a connection works before you configure anything. The chat talks to Moodle as the MCP key you select as its identity, so it answers about that key's connection.