MIREA Lecture Assistant MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_statusA | Read application version and scanner state without logging in or submitting anything. |
| get_settingsA | Read non-secret settings and their validation schema. No credentials or email codes. |
| get_scheduleA | Read cached schedule, without refreshing websites or opening lectures. |
| get_subject_rulesB | Read AUTO/ASK/IGNORE rules for subjects in the cached schedule. |
| update_settingsA | Apply only settings listed by get_settings. Requires explicit app-side write permission and no unsaved UI edits. Ask the user first. Changes take effect in the running app. |
| set_subject_ruleA | Set AUTO/ASK/IGNORE for an existing subject, only at user's request and with app-side permission. AUTO affects future lecture opening; never change attendance rules silently. |
| check_healthA | Is the app working right now? Returns verdict "ok" or "problem", each problem with repair actions, the current pair, and a network check (MIREA sites, internet, VPN) when something is wrong. Call this first; if ok, nothing else is needed. |
| wait_and_checkC | Wait 0–120 seconds (a repair takes a minute or so), then check_health again. |
| repairA | Start one repair from a problem's actions: retry_login, refresh_schedule, reopen_lecture, restart_browser or start_scanner. Needs the user's «Разрешить ИИ чинить приложение» permission in the app. Check the result with wait_and_check. |
| get_recent_problemsA | Latest warnings and errors of the app's log: time, level, module, event name only. |
| get_attendance_historyC | Recent QR events and the pairs where attendance was marked (no QR contents). |
| get_vpn_helpA | How to let MIREA and MTS Link bypass the user's VPN, with ready files; also shows the instructions in the app. Use when check_health says vpn_suspected. |
| report_fixA | Finish a repair round: 3–6 lines in Russian on what was wrong, what you did and whether it helped. The app removes personal data and sends it to the developer. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| duty_check | One check-and-repair round of MIREA Lecture Assistant. |
| setup_lecture_watch | Schedule checks at +5 and +20 minutes of every pair today. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target clearly distinct actions: health check, repair lifecycle, logs, schedule, settings, attendance, and subject rules. Some boundaries are naturally close—check_health, get_status, and get_recent_problems all relate to app health—but descriptions distinguish their scope well.
The set mostly follows a predictable snake_case verb_noun pattern: get_*, set_*, update_*, check_health, wait_and_check, report_fix. There are minor deviations like the single verb 'repair' and the compound 'wait_and_check', but the convention remains readable and consistent overall.
With 13 tools, the server is well-scoped for a lecture assistant covering diagnostics, repair, settings, schedule, attendance, and subject rules. Each tool appears to earn its place without obvious redundancy or bloat.
The surface covers the important lifecycle: health check, repair initiation, waiting, reporting, logs, VPN help, schedule/settings/status reads, and subject-rule read/write. Minor gaps remain—e.g., no deletion or listing of all subject rules separately—but core workflows are well supported.