Skip to main content
Glama
enesjakozh
sdi2200262

eClass MCP Server

by sdi2200262
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

eClass MCP 서버

특징

  • 인증 : UoA의 CAS SSO 인증 시스템을 통해 eClass에 로그인하세요.

  • 과정 관리 : 등록된 과정 목록 검색

  • 세션 관리 : 도구 호출 간에 인증된 세션을 유지합니다.

  • 상태 확인 : 인증 상태 확인

Related MCP server: mcpUPB

프로젝트 구조

이 프로젝트는 더 나은 유지 관리를 위해 모듈형 아키텍처를 따릅니다.

지엑스피1

설치

UV를 사용하여 서버를 설치합니다(권장):

# Clone the repository
git clone https://github.com/yourusername/eClass-MCP-server.git
cd eClass-MCP-server

# Install dependencies
uv sync --dev --all-extras

또는 pip로 설치하세요.

pip install -e .

구성

다음 구성으로 루트 디렉토리에 .env 파일을 만듭니다(또는 제공된 example.env 파일을 복사하여 이름을 바꿉니다).

ECLASS_URL=https://eclass.uoa.gr
ECLASS_USERNAME=your_username
ECLASS_PASSWORD=your_password

모든 자격 증명은 .env 파일에 제공해야 합니다. 서버는 자격 증명을 매개변수로 허용하지 않습니다.

용법

단말기

진입점 스크립트를 사용하여 서버를 실행합니다.

python run_server.py

또는 모듈로:

python -m src.eclass_mcp_server.server

커서

설정 -> MCP로 이동합니다. Add new MCP server 클릭합니다.

  • 에이전트가 서버의 용도를 알 수 있도록 고유하면서도 적절한 이름을 선택하십시오(예: "eClass Server").

  • "유형"에서 command 옵션을 선택하세요

  • 명령 입력에 다음을 추가합니다: python /path/to/eclass-mcp-server/run_server.py

이 명령은 MCP 클라이언트를 server.py 에 있는 메인 서버 진입점과 연결하는 run_server.py 스크립트를 실행합니다.

클로드 데스크탑

Claude Desktop과 함께 사용하려면:

  1. 클로드 데스크톱 열기

  2. 설정 > 서버로 이동하세요

  3. 다음 세부정보로 새로운 서버를 추가하세요.

    • 이름: eClass MCP

    • 명령어: run_server.py 스크립트 경로

  4. 서버 추가를 클릭하세요

  5. Claude와 채팅할 때 드롭다운에서 서버를 선택하세요

도구

서버는 MCP 클라이언트와 함께 사용할 수 있는 다음 도구를 제공합니다.

로그인

SSO 인증을 사용하여 eClass에 로그인하세요.

{
  "random_string": "any_value"
}

코스를 얻으세요

등록된 과목 목록을 검색합니다(먼저 로그인이 필요합니다).

{
  "random_string": "any_value"
}

로그아웃

eClass에서 로그아웃합니다.

{
  "random_string": "any_value"
}

인증 상태

현재 인증 상태를 확인하세요.

{
  "random_string": "any_value"
}

테스트

이 프로젝트에는 기능을 검증하기 위한 테스트 스크립트가 포함되어 있습니다.

# Run all tests
python -m src.eclass_mcp_server.test.run_all_tests

# Run specific tests
python -m src.eclass_mcp_server.test.test_login
python -m src.eclass_mcp_server.test.test_courses

MCP 클라이언트 사용 예

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
import asyncio

async def run_agent():
    server_params = StdioServerParameters(
        command="python /path/to/eclass-mcp-server/run_server.py",
    )
    
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            # Initialize the session
            await session.initialize()
            
            # Login to eClass
            login_result = await session.call_tool("login", {
                "random_string": "dummy"
            })
            print(login_result)
            
            # Get courses
            courses_result = await session.call_tool("get_courses", {
                "random_string": "dummy"
            })
            print(courses_result)
            
            # Logout
            logout_result = await session.call_tool("logout", {
                "random_string": "dummy"
            })
            print(logout_result)

if __name__ == "__main__":
    asyncio.run(run_agent())

AI 에이전트와의 통합

이 MCP 서버는 모델 컨텍스트 프로토콜(MCP)을 지원하는 AI 에이전트와 함께 사용하도록 설계되었습니다. 이를 통해 AI 시스템은 eClass와 직접 상호 작용하여 다음과 같은 기능을 구현할 수 있습니다.

  • 과정 정보 검색

  • 강좌 공지사항 확인

  • 강의 자료 접근

  • 과제 제출(향후 기능)

보안 고려 사항

  • 서버는 민감한 인증 자격 증명을 처리합니다.

  • 자격 증명은 인증에만 사용되며 영구적으로 저장되지 않습니다.

  • 세션 쿠키는 서버의 수명 주기 동안 메모리에 유지됩니다.

  • 서버는 작업을 수행하기 전에 세션 상태를 검증합니다.

  • 자격 증명이 포함된 .env 파일은 버전 제어에 커밋되어서는 안 됩니다(.gitignore에 포함됨).

특허

MIT 라이센스

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

Available Tools

4 tools
authstatusB

Check authentication status with eClass

ParametersJSON Schema
NameRequiredDescriptionDefault
random_stringYesDummy parameter for no-parameter tools

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the purpose without disclosing behavioral traits such as whether it requires authentication, what the response format is, or any rate limits. For a tool with zero annotation coverage, this is inadequate.

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 wasted words. It's appropriately sized and front-loaded, making it easy to understand immediately.

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 annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure, user details) or any behavioral context, which is necessary for an authentication-related tool with no structured data support.

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 schema description coverage is 100%, so the schema fully documents the single parameter. The description doesn't add any parameter information, which is acceptable since the schema handles it. With 0 parameters of real semantic weight (the parameter is a dummy), a baseline of 4 is appropriate.

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?

The description clearly states the tool's purpose as 'Check authentication status with eClass', which is a specific verb ('Check') and resource ('authentication status') combination. It doesn't explicitly distinguish from siblings like 'login' or 'logout', but the purpose is unambiguous.

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 like 'login' or 'logout'. The description states what it does but offers no context about when it should be invoked or what scenarios it addresses.

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

get_coursesB

Get list of enrolled courses from eClass

ParametersJSON Schema
NameRequiredDescriptionDefault
random_stringYesDummy parameter for no-parameter tools

TDQS

B3.1/5.0
Behavior2/5

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 mentions retrieving a list but doesn't specify whether this requires authentication, what format the list is in, if there are rate limits, or any error conditions. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.

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, efficient sentence with no wasted words. It's front-loaded with the core purpose ('Get list of enrolled courses from eClass'), making it easy to understand immediately. Every word earns its place without redundancy.

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 no annotations, no output schema, and a simple read operation, the description is incomplete. It lacks details on authentication requirements, return format, error handling, or any behavioral context. For a tool that likely interacts with an eClass system, this leaves too many unknowns for effective agent use.

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 one parameter (random_string) with 100% description coverage, indicating it's a dummy parameter for no-parameter tools. The description doesn't add any parameter details beyond the schema, but since this is effectively a zero-parameter tool (with a dummy parameter), the baseline is 4 as it doesn't need to compensate for schema gaps.

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?

The description clearly states the action ('Get list') and target resource ('enrolled courses from eClass'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools (authstatus, login, logout) which are unrelated authentication tools, so this distinction isn't needed but the purpose remains clear.

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 provides no guidance on when to use this tool versus alternatives. While the sibling tools are unrelated (authentication vs. data retrieval), there's no explicit mention of prerequisites like needing to be logged in or any context for usage. It simply states what it does without usage instructions.

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

loginB

Log in to eClass using username/password from your .env file through UoA's SSO. Configure ECLASS_USERNAME and ECLASS_PASSWORD in your .env file.

ParametersJSON Schema
NameRequiredDescriptionDefault
random_stringYesDummy parameter for no-parameter tools

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 carries the full burden of behavioral disclosure. It mentions authentication via SSO and .env file usage, but lacks details on what the tool actually does (e.g., establishes a session, returns tokens, handles errors) or behavioral traits like rate limits, side effects, or response format. For a login tool with zero 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.

Conciseness5/5

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

The description is two concise sentences that efficiently convey the core functionality and configuration requirement. It's front-loaded with the main action and wastes no words, making it easy to parse quickly.

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 complexity of a login operation (authentication, session management) with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after login (e.g., session persistence, return values, error handling), leaving gaps in understanding the tool's behavior and outcomes.

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 1 parameter with 100% coverage, describing it as a 'Dummy parameter for no-parameter tools.' The description doesn't add any parameter-specific information, which is appropriate since the tool likely doesn't require user-provided inputs. With high schema coverage and no meaningful parameters, a baseline of 4 is justified as the description doesn't need to compensate.

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?

The description clearly states the tool's purpose: 'Log in to eClass using username/password from your .env file through UoA's SSO.' It specifies the action (log in), target system (eClass), and authentication method (SSO with .env credentials). However, it doesn't explicitly differentiate from sibling tools like 'authstatus' or 'logout' beyond the obvious login/logout distinction.

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 context: it should be used to authenticate with eClass via SSO when credentials are stored in .env. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'authstatus' (which might check login state) or prerequisites beyond .env configuration. The guidance is somewhat implied but not comprehensive.

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

logoutB

Log out from eClass

ParametersJSON Schema
NameRequiredDescriptionDefault
random_stringYesDummy parameter for no-parameter tools

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Log out' implies session termination, it doesn't specify what gets invalidated, whether this affects other tools, if re-authentication is required afterward, or what happens on failure. The description lacks important behavioral context for a security-sensitive operation.

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 maximally concise with just three words that directly convey the tool's purpose. There's zero waste or unnecessary elaboration, and it's perfectly front-loaded with the essential information.

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?

For a security operation like logout with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after logout, whether the operation can fail, what state changes occur, or how this affects subsequent tool calls. The minimal description leaves critical behavioral questions unanswered.

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 100% description coverage, with the single parameter clearly documented as a 'Dummy parameter for no-parameter tools.' The description doesn't need to add parameter semantics since the tool conceptually requires no real parameters, and the schema adequately explains the dummy parameter requirement.

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?

The description clearly states the action ('Log out') and target system ('from eClass'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'login' or 'authstatus' beyond the obvious action difference.

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 provides no guidance on when to use this tool versus alternatives like 'authstatus' to check login state, or whether logout should follow certain workflows. It simply states what the tool does without context about appropriate usage scenarios.

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. 4 tool updates
    • First observedauthstatus
    • First observedget_courses
    • First observedlogin
    • First observedlogout
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

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct purpose with no overlap: authstatus checks authentication state, get_courses retrieves course data, login handles authentication, and logout terminates sessions. The descriptions clearly differentiate these functions, making tool selection straightforward for an agent.

Naming Consistency4/5

Three tools follow a consistent verb_noun pattern (get_courses, login, logout), while authstatus uses a compound noun. This minor deviation slightly reduces consistency, but the naming remains readable and intuitive overall.

Tool Count4/5

Four tools are reasonable for an eClass server focused on authentication and basic course access. It covers core authentication workflows and data retrieval, though it could be slightly expanded for a more comprehensive eClass integration.

Completeness3/5

The tools cover authentication and course listing well, but there are notable gaps for typical eClass functionality such as accessing course content, assignments, grades, or announcements. This limits the server's ability to support full eClass workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers