Skip to main content
Glama
markrz-0

ekursy-mcp-py

by markrz-0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

eKursy MCP Server

A remote Model Context Protocol server that exposes a student's eKursy profile, courses, grades, deadlines, forums, and course materials. It uses FastMCP over Streamable HTTP, the bundled ekursy-zero Rust service, and invite-only GitHub OAuth.

Each GitHub identity maps to its own Moodle credentials in SQLite. Credential fields are encrypted with Fernet authenticated encryption before being written to disk. OAuth tokens and MCP tool calls never contain the university password.

Production endpoint

The production MCP URL is:

https://mk.uni.markrz0.dev/mcp

OAuth discovery and callback routes are served on the same origin. The Docker port is bound only to 127.0.0.1; nginx is the public TLS endpoint.

Related MCP server: geo-explorer-mcp

Production prerequisites

  1. Create a GitHub OAuth app at https://github.com/settings/developers.

  2. Set its homepage URL to https://mk.uni.markrz0.dev.

  3. Set its authorization callback URL to https://mk.uni.markrz0.dev/auth/callback.

  4. Copy .env.example to .env, fill the GitHub client ID/secret, and independently generate both OAUTH_JWT_SIGNING_KEY and CREDENTIAL_ENCRYPTION_KEY with openssl rand -hex 32.

  5. Keep .env mode 600 on the server.

OAUTH_ALLOWED_GITHUB_USERS is only a bootstrap list. On that user's next authenticated request, the server records their immutable numeric GitHub ID with no Moodle credentials. New users must be invited with the admin command below.

Never rotate CREDENTIAL_ENCRYPTION_KEY while the SQLite database contains credentials. Losing it makes those credential records unrecoverable.

Deploy

git submodule update --init --recursive
docker compose up --build -d
docker compose ps
docker compose logs --tail=100 ekursy-mcp

The SQLite account database and OAuth state use a named Docker volume, so they survive container recreation and are not stored in the Git checkout.

To install nginx and obtain the certificate on Ubuntu, copy deploy/install-nginx.sh to the VPS and run:

sudo bash ~/install-ekursy-nginx.sh you@example.com

The script validates nginx before every reload and lets Certbot add the TLS and HTTP-to-HTTPS configuration.

On the prepared VPS deployment, enter the GitHub OAuth credentials without putting the secret in shell history, start the containers, and then install TLS:

bash ~/finish-ekursy-deploy.sh
sudo bash ~/install-ekursy-nginx.sh you@example.com

Connect from ChatGPT

Add a custom MCP server/plugin with the server URL https://mk.uni.markrz0.dev/mcp and OAuth authentication. Complete the GitHub authorization as an invited account. Then install the resulting plugin and use it from the conversation in which you create the scheduled task.

The first account listed in OAUTH_ALLOWED_GITHUB_USERS is bootstrapped on its next request. Ask the connector to run create_account_setup_link, open the returned browser link, and enter your Moodle credentials there.

Add a friend

Invite their GitHub account from the VPS. The command resolves the login to GitHub's immutable numeric user ID before storing it:

cd /home/saell/ekursy-mcp
docker compose exec ekursy-mcp /app/.venv/bin/python src/admin.py invite THEIR_GITHUB_LOGIN
docker compose exec ekursy-mcp /app/.venv/bin/python src/admin.py list

Your friend then adds https://mk.uni.markrz0.dev/mcp in ChatGPT and completes GitHub OAuth. In ChatGPT they ask the connector to run create_account_setup_link, open the returned short-lived one-time link in a browser, and enter their own Moodle credentials. The server validates and encrypts them directly; they do not pass through ChatGPT.

Disable or re-enable access without deleting the encrypted record:

docker compose exec ekursy-mcp /app/.venv/bin/python src/admin.py disable THEIR_GITHUB_LOGIN
docker compose exec ekursy-mcp /app/.venv/bin/python src/admin.py enable THEIR_GITHUB_LOGIN

Each Moodle login has an isolated server-side session. Tool calls resolve the authenticated GitHub ID to exactly one database record before accessing Moodle.

The exact availability of custom MCP servers and scheduled tasks depends on your ChatGPT plan and workspace policy.

Local development

Initialize the scraper submodule, copy .env.example to .env, configure the OAuth settings, and install dependencies with uv:

git submodule update --init --recursive
uv sync --frozen
docker compose up --build

Run tests with:

python -m unittest discover -s tests -v

Available Tools

6 tools
get_course_contentB

Get the detailed page fragments and sections for a specific course (including presentations, lecturer names, assignments, and other files).

NameRequiredDescriptionDefault
idYesThe internal unique course identifier string.

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must bear the full burden. It only states the basic function but does not disclose behavioral traits such as authentication requirements, read-only nature, or pagination behavior. The description is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no unnecessary words, achieving high conciseness. It is front-loaded with the core purpose. Slightly more structured formatting could improve readability for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, output schema exists), the description adequately covers what the tool does. It does not need to explain return values due to output schema. However, it omits mention of any filtering or pagination, which might be relevant for large courses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents the single required id parameter, and schema coverage is 100%. The description adds examples of output content but does not add extra meaning for the parameter beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'detailed page fragments and sections for a specific course', with explicit examples like presentations, lecturer names, assignments, and other files. It distinguishes from siblings such as list_courses and get_course_grades.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used for a specific course via the id parameter, but it provides no guidance on when to use alternatives like list_courses or get_course_grades, and no explicit when-not-to-use criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_course_gradesB

Fetch the hierarchical gradebook for a specific course.

NameRequiredDescriptionDefault
idYesThe internal unique course identifier string.

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks disclosure of behaviors such as rate limits, authentication needs, or what 'hierarchical' means in terms of data structure. The one-sentence description is insufficient for transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no extraneous information. It is appropriately concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple fetch tool with one parameter and an output schema, the description is minimally adequate but lacks context about what 'hierarchical' entails and does not explain the return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter 'id', and the description adds no new meaning beyond what the schema already provides. Baseline is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetch' and the resource 'hierarchical gradebook for a specific course'. It distinguishes from siblings like get_course_content (content) and list_courses (list).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives, no prerequisites or context provided. The description only implies that a course ID is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_profileA

Fetch the authenticated student's profile information and USOS number.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, permissions, rate limits, or side effects. It only states the action, leaving key behavioral context implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with only two sentences that efficiently convey the purpose. Every word earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, presence of an output schema, and zero parameters, the description is minimally adequate. However, it lacks usage guidelines and behavioral transparency, which would improve completeness for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to add parameter semantics. Baseline 4 is appropriate as the schema coverage is 100% and no parameter explanation is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetch' and the specific resource 'authenticated student's profile information and USOS number'. It distinctly differentiates from sibling tools like get_course_content or list_courses, which are about course-related data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving the current user's profile but provides no explicit guidance on when to use or not use this tool versus alternatives. No exclusions or alternative tool names are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_coursesA

Get a list of all courses the student is enrolled in.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states a basic list retrieval without detailing ordering, pagination, filtering, or any side effects. This lacks transparency, especially since the tool returns all enrolled courses with no parameters to limit results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no extraneous words. It efficiently communicates the core functionality, earning full points for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and a provided output schema, the description is mostly complete. However, it could mention that it returns only courses the user is enrolled in (already implied) and lacks any note on what the output structure is (though schema covers it). For a simple tool, this is adequate but not exemplary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the description does not need to explain parameter semantics. Baseline is 4 for no parameters, and the description adds no confusion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get' and resource 'list of all courses the student is enrolled in.' It distinguishes from sibling tools like get_course_content and get_course_grades by specifying the scope (enrolled courses), making it easy to understand its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. While the purpose is clear, the description does not mention any conditions, prerequisites, or scenarios where this tool is preferred over get_course_content or other siblings, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_proxyC

Download and parse internal university proxies (PDFs, Images, URLs etc).

NameRequiredDescriptionDefault
proxyPathYesPath of the proxy page fragment

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must fully disclose behavioral traits. It mentions 'download and parse' but omits critical details such as whether the tool is read-only, side effects, authentication requirements, or rate limits. The description is insufficient for an agent to understand full implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence and front-loads the action, but it is overly terse. It could be expanded to include necessary details without becoming verbose, balancing brevity with clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description should explain return values and parsing behavior. It does not specify what 'parse' entails or the format of the result, leaving the agent without enough context to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter described. The tool description adds general context that the path refers to a proxy page fragment, but does not elaborate on format constraints or usage beyond the schema. Baseline value of 3 is appropriate as the schema already documents the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states the tool downloads and parses internal university proxies and lists file types, clearly indicating the resource and action. While it distinguishes from siblings like 'resolve_material_link', the term 'proxies' could be ambiguous without further context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as 'resolve_material_link' or 'get_course_content'. The description does not provide context for appropriate invocation or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv0.1.0
    • First observedget_course_content
    • First observedget_course_grades
    • First observedget_user_profile
    • First observedlist_courses
    • First observedresolve_material_link
    • First observedresolve_proxy
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 6 tools

Disambiguation4/5

Most tools are clearly distinct, but resolve_material_link and resolve_proxy have overlapping purposes (both download and parse internal files), which could cause minor confusion. Descriptions help distinguish them as one is for general materials and the other for proxies.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case (e.g., get_course_content, list_courses, resolve_proxy). Verbs are appropriate and nouns are descriptive, making the naming predictable.

Tool Count5/5

Six tools is a well-scoped number for a university course management MCP server. Each tool serves a distinct purpose without unnecessary duplication, covering essential student operations.

Completeness4/5

The tool set covers core functionalities: course listing, content retrieval, grades, profile, and file downloads. Minor gaps exist (e.g., no assignment submission or mailbox tool), but the provided tools form a coherent and practical surface for accessing course information.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers