Das LMS als MCP — artim/dev

Das LMS spricht MCP. Ein Sprachmodell bekommt damit dieselben Endpunkte wie eine Anwendung — nur als Werkzeuge, und begrenzt auf das, was die Rolle des angemeldeten Kontos hergibt.

Was daran neu ist

Ein MCP-Server pro Rolle wäre der naheliegende, falsche Weg gewesen: drei Adressen, drei Freigaben, und bei jeder Rollenänderung ein Umzug. Es gibt deshalb einen Server. Er zeigt jedem, was er darf:

Rolle in der Akademie	Werkzeuge
`student`	`lms_me` — eigene Kurse, eigener Fortschritt, eigene Abgaben und Quizze, eigene Termine
`trainer`	dazu `lms_courses`, `lms_students`, `lms_assignments`, `lms_code_reviews`, `lms_quizzes`, `lms_calendar`
`admin`	dazu `lms_admin` — Akademien, Rollen, Freigabe der Lesson-Apps
`shop_admin`	dazu `lms_shop` — Produkte und Bestellungen

Die Zuordnung entsteht nicht hier, sondern im LMS: beim Ausstellen des Tokens engt es die erbetenen Scopes auf die ein, die die Rollen des Kontos decken. Der Devhub schreibt genau diese Freigabe ins Token — und der MCP zeigt nur Werkzeuge, für die ein Scope im Token steht. Ein Schüler sieht die Trainer-Werkzeuge deshalb nicht; er bekommt sie nicht erst am Endpunkt abgewiesen.

Verbinden

Im Projekt die API LMS MCP freischalten und ein Konto der Akademie verknüpfen (Konsole → Projekt → OAuth).
Die Adresse des Servers eintragen:

https://api.artim-industries.com/mcp/<projekt-id>/lms

Mehr braucht ein Client nicht. Von dieser Adresse aus findet er allein den Weg: /.well-known/oauth-protected-resource/… nennt den Anmeldedienst, /.well-known/oauth-authorization-server/… seine Endpunkte, und dort registriert er sich selbst (RFC 9728, RFC 8414, RFC 7591). Der Nutzer sieht danach den gewohnten Consent-Screen von artim/dev und dahinter die Anmeldung des LMS.

In Claude Code etwa:

claude mcp add --transport http artim-lms https://api.artim-industries.com/mcp/prj_a7f3/lms

Der Weg der Anmeldung

Zwei OAuth2-Strecken hintereinander, und keine davon ist neu erfunden:

MCP-Client ──(1) OAuth2 + PKCE──▶ artim/dev ──(2) OAuth2/OIDC──▶ LMS
                                      │                            │
                                 Consent-Screen              Anmeldung + Rollen

Client → artim/dev. Der Client registriert sich dynamisch, schickt den Nutzer auf /v1/oauth/authorize, holt sich hinterher unter /v1/oauth/token seinen Bearer. PKCE mit S256 ist Pflicht.
artim/dev → LMS. Zwischen Consent und Code meldet sich der Nutzer beim LMS an — dessen Spring Authorization Server unter /oauth2/authorize, /oauth2/token und /userinfo. Aus dem sub und der gewählten Akademie stellt das LMS dann den Token aus, mit dem der Devhub die Aufrufe später weiterreicht.

Der Client sieht von der zweiten Strecke nichts. Er hält einen Bearer, der 30 Tage gilt und über /v1/oauth/token mit grant_type=refresh_token verlängert wird. Wird dem Konto im LMS eine Rolle genommen, engt die Verlängerung die Scopes mit ein — die Werkzeuge verschwinden dann beim nächsten tools/list.

Ein Aufruf

Ein Werkzeug je Bereich, die Operation als Parameter — so wie bei den anderen Produkten:

{
  "name": "lms_assignments",
  "arguments": {
    "operation": "abgabe-bewerten",
    "courseId": "crs_1a9f",
    "id": "asg_7c21",
    "submissionId": "sub_9e04",
    "grade": 18,
    "feedback": "Sauber gelöst, Randfall fehlt.",
    "approved": true
  }
}

Welche Operationen ein Werkzeug kennt, steht in seiner Beschreibung — und ausführlich in der Referenz dieses Produkts. Kontingent, Protokoll und Enterprise-Sperre gelten am MCP wie am Gateway; er ist dieselbe Tür, nicht eine daneben.

Was der MCP nicht kann

Es gibt keine Sandbox: die Bereiche des LMS sind OAuth-only, und ein Sandbox-Key erreicht sie nicht. Wer ausprobieren will, legt eine eigene Akademie an und arbeitet darin.