This MCP server enables AI tools to interact with the eKursy (Moodle-based Polish university) platform, providing access to student academic data and course materials:
Get User Profile (get_user_profile): Fetch the authenticated student's profile information, including their USOS number.
List Courses (list_courses): Retrieve a full list of all courses the student is enrolled in.
Get Course Content (get_course_content): Access detailed content for a specific course, including page sections, presentations, lecturer names, assignments, and files.
Get Course Grades (get_course_grades): Fetch the hierarchical gradebook for a specific course.
Resolve Material Link (resolve_material_link): Download and parse internal university files (PDFs, images) by specifying a resource ID and kind (e.g., resource, assign).
Resolve Proxy (resolve_proxy): Download and parse internal university proxied content (PDFs, images, URLs, etc.) using a proxy page fragment path.
Provides tools for accessing student profile information, course lists, course grades, page contents, and course materials (PDF/images) from the eKursy (Moodle-based) platform.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ekursy-mcp-py show my grades for this semester"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ekursy-mcp-py)A Model Context Protocol (MCP) server written in Python using FastMCP, which integrates with the ekursy-zero Rust scraper to expose student profile information, course lists, course grades, page contents, and course materials (PDF/images) from the eKursy platform to AI tools.
Before running the server, ensure you have:
Git installed on your system.
Docker installed on your system
Python installed on your system
Related MCP server: Canvas LMS MCP
If you dont use antigravity this won't work for you. See manual methods below or ask your AI agent
This repository includes a cross-platform setup script that automatically initializes git submodules, prompts you for credentials to create the .env file, and configures the Gemini / Antigravity integration file for you.
Windows: Run scripts\setup.bat (Double-click or run in terminal: .\scripts\setup.bat)
macOS / Linux: Run ./scripts/setup.sh (or bash scripts/setup.sh)
The script will configure MCP in Antigravity and start the server in docker. You only need to restart Antigravity and this MCP server should work
If you prefer not to use the setup script:
git submodule update --init --recursiveAnd manually create a .env file in the root directory:
MOODLE_USERNAME="your.email@student.put.poznan.pl"
MOODLE_PASSWORD="your_moodle_password"
MCP_TRANSPORT="streamable-http" # optional: defaults to streamable-http when running using docker compose, set to stdio to run locallyThis runs both the ekursy-zero scraper backend and ekursy-mcp-py server together. The scraper remains private and isolated inside the container network (ports are not exposed to the host).
By default, Docker Compose runs the MCP server in streamable-http mode. If you need to configure the transport type, you can set MCP_TRANSPORT in your .env file (e.g., MCP_TRANSPORT=stdio or MCP_TRANSPORT=streamable-http).
When running via Docker Compose, the host's ./downloads directory is mounted to /app/downloads in the container.
The environment variable HOST_DOWNLOADS_DIR is set in docker-compose.yml as ${PWD}/downloads.
When an MCP tool calls save_resource (e.g. download PDF or images), the file is saved inside this volume. The server uses HOST_DOWNLOADS_DIR to report the exact absolute host path back to the MCP caller so you know exactly where to locate the file on your machine.
Run the following command:
docker compose up --buildThe MCP server will start on HTTP port 6969 (if using streamable-http mode). You can verify it by reaching the MCP endpoint:
http://localhost:6969/mcp
To run the server locally using the standard stdio transport:
uv run src/main.pyNote: By default, running the script directly uses stdio transport. You can force it to run as a local HTTP server by setting the MCP_TRANSPORT environment variable: MCP_TRANSPORT=streamable-http uv run src/main.py (which runs on port 6969 or the port specified in PORT).
To manually connect this Python MCP server to your Antigravity environment:
Locate the configuration file on your system (e.g., C:\Users\Marcin\.gemini\config\mcp_config.json or config.json).
Add a new server entry inside the mcpServers object.
Add the following snippet to your configuration block:
{
"mcpServers": {
"ekursy-mcp-py": {
"serverUrl": "http://localhost:6969/mcp"
}
}
}Note: Ensure the MOODLE_API_BASE env variable points to the scraper service instance (e.g. http://localhost:8080 if running ekursy-zero locally/standalone).
If you prefer to run the server locally using the standard input/output (stdio) transport:
Add the following snippet to your configuration block (make sure to replace C:\\path\\to\\ekursy-mcp-py with the absolute path to your cloned repository, and update the environment variables):
{
"mcpServers": {
"ekursy-mcp-py-stdio": {
"command": "uv",
"args": [
"run",
"src/main.py"
],
"cwd": "C:\\path\\to\\ekursy-mcp-py",
"env": {
"MOODLE_USERNAME": "your.email@student.put.poznan.pl",
"MOODLE_PASSWORD": "your_moodle_password",
"MOODLE_API_BASE": "http://localhost:8080",
"MCP_TRANSPORT": "stdio"
}
}
}
}Note: Ensure the MOODLE_API_BASE env variable points to the scraper service instance (e.g., http://localhost:8080 if running ekursy-zero locally/standalone). The MCP_TRANSPORT is optional and defaults to stdio when running locally.
Get the detailed page fragments and sections for a specific course (including presentations, lecturer names, assignments, and other files).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The internal unique course identifier string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Fetch the hierarchical gradebook for a specific course.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The internal unique course identifier string. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Fetch the authenticated student's profile information and USOS number.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get a list of all courses the student is enrolled in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Download and parse internal university files (PDFs, Images) - resource.
| Name | Required | Description | Default |
|---|---|---|---|
| resourceId | Yes | Unique id of the resource | |
| kind | Yes | Resource type selections (e.g., 'resource', 'assign') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It mentions download and parse actions but omits key traits: whether it's read-only, authentication needs, error handling, or if parsing alters state. This leaves significant gaps for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Download and parse'). It is efficient, though the trailing '- resource' adds minor clutter without improving clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and two required parameters, the description is insufficient. It lacks details on return format, failure modes, and setup prerequisites, leaving the agent with incomplete context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds context about file types (PDFs, Images), which loosely relates to resourceId, but offers no additional clarity on ‘kind’ beyond the schema’s examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads and parses internal university files (PDFs, Images), which distinguishes it from sibling tools like get_course_content (listing) and list_courses. However, the purpose is slightly vague due to the appended '- resource' suffix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_course_content or resolve_proxy. The description lacks any when-to-use or when-not-to-use context, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download and parse internal university proxies (PDFs, Images, URLs etc).
| Name | Required | Description | Default |
|---|---|---|---|
| proxyPath | Yes | Path of the proxy page fragment |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_course_contentget_course_gradesget_user_profilelist_coursesresolve_material_linkresolve_proxyScored across 6 tools
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.
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.
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.
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.
Model Context Protocol server for Studex tools, notifications, and profile integrations
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Your personal data for AI — Telegram, bank, courses, Zoom & more, scoped to you.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
