This server lets AI agents read and monitor your LMS Polinema courses, assignments, materials, and deadlines.
List enrolled courses for the current semester
List all active assignments, optionally filtered by course
Get detailed assignment info: instructions, attachments, submission status, due date, and time remaining
List course materials like slides, documents, and folders
Check deadline summaries across all courses
Works with MCP-compatible clients (Claude Code, Cursor, Antigravity) using automated SIAKAD→SLC→Moodle authentication
Provides tools for interacting with the LMS Polinema Moodle instance, enabling agents to list courses, view assignments and materials, and check deadlines.
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., "@lms-polinema-mcp what assignments are due this week?"
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.
An MCP server for LMS Polinema. Gives AI agents access to your courses, assignments, deadlines, and materials.
Works with Claude Code, Cursor, Antigravity, or any MCP-compatible client.
Polinema does not allow direct Moodle logins with student credentials. Authentication flows through an institutional single sign-on chain: SIAKAD (academic portal) → SLC (SPADA gateway) → LMSSLC (Moodle).
On first run, auth.py authenticates via SIAKAD (NIM and password) using HTTP requests (httpx), exchanges tokens through SLC, and captures the authenticated MoodleSession. Session cookies are saved to ~/.lms_polinema/. When a session expires, the server re-authenticates automatically in the background without requiring browser binaries.
Related MCP server: Canvas LMS MCP
Tool | Parameters | Returns |
| - | Enrolled courses for the current semester |
|
| Assignments, optionally filtered by course |
|
| Instructions, attachments, submission status |
|
| Material links and metadata (slides, jobsheets, folders) |
| - | Deadline summary across all courses |
Requires Python 3.11+ and uv.
git clone https://github.com/hafidzrafi/lms-polinema-mcp.git
cd lms-polinema-mcp
uv syncRun once to set up credentials:
uv run auth.pyCredentials are stored as plaintext JSON at ~/.lms_polinema/credentials.json (0600 permissions).
Add to your MCP client config:
{
"mcpServers": {
"lms-polinema": {
"command": "uv",
"args": ["run", "--directory", "/path/to/lms-polinema-mcp", "lms-polinema-mcp"]
}
}
}Or use the virtualenv directly:
macOS / Linux: .venv/bin/python -m lms_polinema_mcp.server
Windows: .venv\Scripts\python.exe -m lms_polinema_mcp.server
Settings can be overridden via environment variables or a .env file:
Variable | Default | Description |
|
| Request timeout (seconds) |
|
| Course list cache lifetime |
|
| Session validation cache lifetime |
|
| SIAKAD portal URL |
|
| Moodle URL |
See .env.example for the full list.
All data is retrieved by scraping HTML. The Moodle Web Services API is disabled on this instance.
All operations are currently read-only; assignment submission is not supported.
lms_list_materials returns resource links and metadata, not downloaded file contents.
Courses without an active Moodle link configured by the lecturer will return moodle_id: null.
Sessions expire after ~30 min idle. Re-auth happens automatically in the background.
SSL verification is disabled for lmsslc.polinema.ac.id and slc.polinema.ac.id due to a missing intermediate CA.
This project is an independent open-source utility for academic productivity and is not officially affiliated with or endorsed by State Polytechnic of Malang (Polinema).
MIT License - Hafidz Rafi' Rabbani
Return deadline summary for all active assignments across all enrolled courses.
| 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 carries the full burden of behavioral disclosure. It states that the tool 'returns' a summary, implying a read-only operation, but it does not explicitly confirm that there are no side effects or mention any permissions or constraints. For a zero-parameter query tool, this is adequate but lacks explicit reassurance about its read-only nature.
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, efficient sentence that front-loads the action ('Return') and immediately specifies the scope. There is no redundant wording or extraneous detail. It is concise and well-structured for quick parsing by an 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?
For a tool with no parameters and no annotations, the description is largely complete. It specifies the exact output (deadline summary) and the scope (all active assignments across all enrolled courses). However, it does not elaborate on the summary's format or content (e.g., whether it includes due dates, course names, or sorting), which might be relevant depending on the output schema. Given that an output schema exists, this gap is minor.
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 schema fully covers the parameter surface (100% coverage). The description adds no parameter information because none exists. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description does not need to elaborate further.
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's function: returning a deadline summary for all active assignments across all enrolled courses. The verb 'Return' and resource 'deadline summary' are specific, and the scope is unambiguous. This distinguishes it from siblings like lms_list_assignments (which likely lists assignments without a summary) and lms_get_assignment_detail (which focuses on one assignment).
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 when to use the tool (when you need a deadline summary), but it does not explicitly state when not to use it or mention alternative tools. There is no contrast with sibling tools like lms_list_assignments or lms_list_courses. The usage context is implied rather than stated, leaving the agent to infer based on the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return complete assignment details including instructions, attachments, and submission status.
| Name | Required | Description | Default |
|---|---|---|---|
| assignment_id | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| title | Yes | |
| due_date | No | |
| attachments | No | |
| description | Yes | |
| assignment_id | Yes | |
| last_modified | No | |
| grading_status | No | |
| time_remaining | No | |
| submission_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns details but doesn't disclose whether this is a read-only operation, whether it requires specific permissions, what happens if the assignment_id is invalid, or whether submission status is real-time or cached. For a tool with no annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the main purpose and lists the key content areas. No wasted words, though it could add a brief usage note without becoming bloated.
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?
The tool has a simple input schema (one required parameter) and an output schema, which reduces the burden on the description. However, with no annotations and no usage guidance, the description is only minimally viable. It covers what the tool returns but not when to use it or any behavioral caveats.
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 description coverage is 0%, so the description must compensate for the undocumented assignment_id parameter. The description mentions 'assignment details' but doesn't explain how assignment_id is used, its format, or any constraints beyond the schema's integer type. The agent must infer that assignment_id identifies the target assignment.
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 uses a specific verb ('Return') and resource ('assignment details'), and lists the key content areas: instructions, attachments, and submission status. It is clear what the tool does, though it doesn't explicitly distinguish itself from siblings like lms_list_assignments beyond the 'detail' implication.
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 this is for fetching a single assignment's full details, as opposed to listing assignments. However, it doesn't explicitly state when to use this tool versus lms_list_assignments or lms_check_deadlines, leaving the agent to infer the distinction from the word 'detail'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all active assignments, optionally filtered by specific course_id.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that only active assignments are returned and that course_id is an optional filter, which is useful. However, it does not define 'active', mention pagination, ordering, authentication, or other behavioral traits an agent might need to anticipate.
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?
A single front-loaded sentence with no filler. Every word contributes meaning, and the optional filter behavior is stated immediately after the primary purpose.
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 list tool with one optional parameter and an output schema, the description covers the core invocation need. It could be more complete with pagination or a note on the 'active' definition, but nothing essential to selecting or calling the tool is missing.
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 0%, so the description must compensate. It adds meaning by explaining that course_id is an optional filter ('optionally filtered by specific course_id'), which the schema does not convey. However, it does not describe where the course_id comes from, value expectations, or behavior when omitted, leaving some semantic gaps.
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 uses a specific verb and resource ('Return all active assignments') and clearly distinguishes this from siblings like lms_get_assignment_detail by emphasizing 'all active' rather than a single detail. The optional course_id filter adds useful scope without ambiguity.
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 this is the tool for listing active assignments and optionally narrowing by course, but it does not explicitly say when to prefer it over siblings such as lms_get_assignment_detail or lms_check_deadlines. There is clear context, but no explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all enrolled academic courses for the current semester from SPADA portal.
| 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, the description carries the behavioral burden. It clearly signals a non-mutating retrieval ('Return') and identifies the external SPADA portal as the source, but it does not disclose authentication requirements, failure behavior, or pagination. This is acceptable for a simple read-only list operation, yet some behavioral gaps remain.
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?
A single sentence that front-loads the action and resource, and adds only the scoping context needed: current semester and source portal. Every phrase earns its place; there is no 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?
At low complexity, with no parameters and an output schema available, the description covers what an agent needs to invoke the tool. It could have added a note on result format or authentication, but the output schema fills the main return-shape gap. It is complete enough though not exhaustive.
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?
There are zero parameters and the input schema covers 100% of them, so the baseline is 4. The phrase 'all enrolled' reinforces that the tool takes no filtering parameters, which is consistent with the empty schema.
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 opens with the action verb and exact resource, 'all enrolled academic courses,' then scopes to current semester and the SPADA portal source. This clearly distinguishes it from sibling tools like lms_list_assignments and lms_list_materials.
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 use whenever the agent needs a list of enrolled courses for the current semester, but it gives no explicit guidance on when to prefer alternatives or what to use for assignments, materials, or deadlines. There are no exclusions or condition-based routing, so guidance is adequate but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all educational material items (slides, documents, folders) for a specific course.
| Name | Required | Description | Default |
|---|---|---|---|
| course_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It does convey that this is a read-only listing operation returning all materials, which is useful. However, it does not disclose pagination, ordering, or permission requirements, though the output schema may cover return structure.
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 focused sentence: action, resource, and scope are front-loaded, and parenthetical examples clarify item types without adding waste.
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 one-parameter listing tool, the description covers what is returned and the target course, and the output schema can provide return-field details. It is complete enough for invocation, though it assumes course_id is obtained elsewhere.
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 schema coverage is 0% and the only parameter is a bare 'course_id' integer. The description partially compensates by linking the tool's purpose to 'a specific course,' letting the agent infer that course_id identifies the target course. It does not name course_id explicitly or add format/example details.
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 opens with a specific verb ('Return') and a concrete resource ('educational material items'), with examples of item types and a clear scope ('for a specific course'). It is readily distinguished from sibling tools that list courses, assignments, or deadlines.
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 phrase 'for a specific course' clearly establishes the context for using this tool: retrieve materials for one course. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can select it over the siblings.
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.0lms_check_deadlineslms_get_assignment_detaillms_list_assignmentslms_list_courseslms_list_materialsScored across 5 tools
Each tool maps to a distinct resource or action: courses, assignments, assignment details, materials, and deadlines. There is no overlap in purpose, and the descriptions clearly differentiate them.
All tools follow a consistent verb_noun pattern with the 'lms' prefix recommended for MCP servers caterpillar walking. The only minor deviation is 'lms_check_deadlines' which uses a verb that is semantically different from 'list' or 'get', but it still matches the pattern.
With 5 tools, the server is well-scoped for an LMS portal integration. Each tool provides essential functionality without redundancy, covering the primary needs of listing and retrieving data.
The tools cover read-only operations for courses, assignments, materials, and deadlines. Missing are mutating operations like creating or submitting assignments, and there is no tool for listing modules or grades, which are common in LMS platforms. However, the core browsing workflow is supported.
Connect any AI agent to 1,000+ apps and 27,000+ actions through one remote MCP server (OAuth).
Your AI agent builds interactive block-based courses over MCP; take them at learnwithagents.app.
Give AI agents identity, scoped access, trusted context, and verifiable actions through MCP.
Let AI agents query data and act across all your business apps via MCP.
