Proposal: AI-Configurable Course Management

[Mtze]

Motivation

Setting up a course in PROMPT requires navigating multiple pages, understanding the phase system, connecting phases correctly in the phase graph, and configuring each phase individually. For new instructors, this is a steep learning curve. Even for experienced users, it's repetitive work — especially when similar courses are set up every semester.

By exposing PROMPT's management capabilities through the Model Context Protocol (MCP), an AI assistant could guide instructors through course setup conversationally, ask the right questions, and configure everything on their behalf. This turns a multi-step, multi-page process into a natural dialogue.

Example Interaction

Instructor: "I need to set up a new software engineering practical course for next semester. 200 students, 15 teams, with interviews and a final assessment."

AI: "Got it. I'll create the course with an Application phase, Interview phase, Team Allocation, and Assessment. Do you need an Intro Course phase for onboarding? And should the assessment include peer and self-evaluation?"

Instructor: "Yes to the intro course, and yes to peer evaluation but not self-evaluation."

AI: "Done. I've created the course with 5 phases connected in sequence: Application → Interview → Intro Course → Team Allocation → Assessment. The assessment has peer evaluation enabled. Want me to configure the assessment competencies based on last semester's iPraktikum template?"

1. MCP Server for PROMPT Core

The core of this proposal is an MCP server that exposes PROMPT's course and phase management as tools and resources that any MCP-compatible AI client can use.

1.1 Tools (Actions)

Tools the AI can invoke to manage PROMPT:

Course Management

• create_course — Create a new course with name, semester tag, and metadata
• list_courses — List existing courses with their status
• archive_course / delete_course — Lifecycle management

Phase Management

• list_available_phase_types — Show all registered phase types with descriptions and their input/output DTOs
• add_phase_to_course — Add a phase of a given type to a course
• remove_phase_from_course — Remove a phase
• connect_phases — Create an edge in the phase graph (prerequisite relationship)
• connect_phase_data — Create a data dependency link between phase DTOs (e.g., connect Application's "score" output to Interview's "score" input)

Phase Configuration

• get_phase_configuration — Read current configuration of a phase
• update_phase_configuration — Update phase settings (dates, toggles, etc.)

User & Role Management

• list_course_members — List lecturers, editors, students
• add_course_member / remove_course_member — Manage course team

Navigation & Deep Linking

• get_link_to_view — Generate a deep link to a specific view in PROMPT (e.g., link to a course's phase settings, a student's application, or the phase graph configurator)
• get_link_to_student — Deep link to a specific student's participation or application details

1.2 Resources (Read-Only Context)

Resources the AI can read to understand the current state:

• courses — All courses with their phases and phase graph
• phase_types — Available phase types with their descriptions, required inputs, and provided outputs
• course_templates — Existing course configurations that can be used as reference
• phase_configurations — Current settings of each phase in a course

1.3 Prompts (Pre-Defined Workflows)

MCP prompts that encapsulate common workflows:

• setup_new_course — Guided course creation workflow that asks the right questions
• clone_course_for_new_semester — Copy a course structure to a new semester with updated dates
• review_course_configuration — Audit an existing course setup and suggest improvements

2. Built-In Helper Chat

In addition to the external MCP server, PROMPT should offer a built-in chat assistant in the instructor and admin interface. This chat helps users navigate, understand, and configure PROMPT without leaving the application.

2.1 Capabilities

• Answer questions about the course: "How many students have applied so far?", "Which phases are still missing a deadline?", "Show me the students who haven't been assigned to a team yet"
• Navigate the UI: "Where do I configure the application questions?", "Take me to the assessment settings for iPraktikum" — the chat responds with deep links to the respective views in PROMPT
• Configure on behalf of the user: "Set the application deadline to March 15th", "Enable auto-accept for the application phase" — executes actions using the same MCP tools
• Explain features: "What does the phase graph do?", "How do score levels work?" — acts as contextual documentation

2.2 Security: User Impersonation

The chat assistant must operate with exactly the same permissions as the user interacting with it. It impersonates the current user's session to prevent access leaks:

• All API calls made by the chat use the user's Keycloak token
• A lecturer can only query and modify their own courses — the chat cannot access courses the user doesn't have permissions for
• An admin's chat session has broader access, consistent with their role
• The chat must never expose data from other users' sessions or cache responses across users
• If the user lacks permission for a requested action, the chat should explain this rather than silently fail

2.3 Deep Linking

Both the MCP server and the built-in chat should be able to generate and present deep links to specific views in PROMPT:

• Link to a course's settings page
• Link to a specific phase's configuration
• Link to the phase graph configurator
• Link to a student's application or participation details
• Link to the assessment overview or results page

This allows the AI to answer navigational questions ("Where do I find X?") with a direct clickable link.

3. Phase-Level AI Configuration (Extensible)

In the long run, individual phases should be able to register their own AI-configurable capabilities. This makes the MCP server extensible without modifying the core.

3.1 Phase Tool Registration

Each phase can declare additional MCP tools that become available when the phase is part of a course. Examples:

Application Phase

• configure_application_questions — Set up application form questions (text, multi-select)
• set_application_deadline — Configure application open/close dates
• toggle_auto_accept — Enable or disable automatic acceptance of applicants
• get_application_statistics — Retrieve current application counts, acceptance rates, score distributions

Assessment Phase

• configure_assessment_schema — Set up categories, competencies, and proficiency level descriptions
• enable_evaluation_type — Enable/disable self, peer, or tutor evaluation
• set_assessment_timeline — Configure start and deadline dates

Team Allocation Phase

• configure_allocation_constraints — Set team size, skill distribution preferences
• import_tutors — Add tutors to teams

Interview Phase

• configure_interview_slots — Set up available time slots
• manage_interview_questions — Add/edit interview question pools

3.2 Registration Mechanism

Phases register their AI capabilities through a standardized extension point:

• Each phase declares its MCP tools, their parameters, and descriptions as part of its phase type registration (extending the existing initializeTypes.go pattern)
• The core MCP server dynamically discovers and exposes phase-specific tools when a phase is active in a course
• Tool descriptions should be detailed enough for the AI to understand when and how to use them without additional documentation

4. Authentication & Authorization

• The MCP server authenticates using the instructor's existing PROMPT credentials (Keycloak token)
• The built-in chat impersonates the current user's session — it can only do what the user can do
• All tool invocations are executed with the caller's permissions — the AI cannot do anything the instructor couldn't do manually
• Course-scoped tools respect course-level authorization (a lecturer can only configure their own courses)

5. Safety & Confirmation

Since AI-driven changes affect real course configurations:

• Destructive operations (delete course, remove phase, disconnect phases) should require explicit confirmation from the instructor before execution
• Batch operations (e.g., "set up the entire course") should present a summary of planned changes for approval before applying them
• Dry-run mode: The AI should be able to preview what it would create without actually making changes
• All changes made through the MCP server or chat should be logged with the acting user and an indication that the action was AI-assisted

6. Implementation Approach

Phase 1: Core MCP Server

• Implement the MCP server exposing course and phase management tools
• Read-only resources for course state and phase types
• Basic course setup workflow (create course, add phases, connect them)
• Deep link generation for all major views

Phase 2: Built-In Chat

• Integrate a chat assistant into the instructor/admin interface
• Connect it to the MCP server with user impersonation
• Support navigational questions, course queries, and basic configuration

Phase 3: Phase Tool Registration API

• Define the extension point for phases to register their own MCP tools
• Allow external phase developers to make their phases AI-configurable
• Dynamic tool discovery based on active phases in a course

[Mtze]

Potential IDP:

Objectives:

• Implement Privacy Preserving MCP Server for Core (Course Phase Configuration)
• MCP Configuration Interface/Abstraction for Phases to implement
• Chatbot implementation that uses the MCP to guide users