CAU eclass MCP (중앙대 이클래스)

Get Materials

eclass_get_materials

Read-onlyIdempotent

Fetch course material metadata from multiple eclass sources (modules, files, announcements) and merge results. Returns downloadable links and acquisition policies without downloading files.

Instructions

[네트워크] 강의 자료 목록/메타데이터를 가져옵니다 (모듈, 파일함, 강의자료실, 외부도구). 강의자료는 주차학습(modulebuilder), LearningX 강의자료실(courseresource), 공지 첨부(announcements), Canvas 모듈/외부 링크(modules/external)에 분산될 수 있으므로 한 source에서 자료를 찾았어도 다른 source를 생략하지 말고 결과를 합쳐 확인합니다. 같은 자료가 여러 source에서 발견되면 하나로 합치고 대표 source와 모든 출처 sources를 반환합니다. 제목만 같은 서로 다른 항목은 합치지 않습니다. 권장 1차 조회는 modulebuilder, courseresource, announcements, modules, external이며, Canvas 기본 파일함(files)은 Files 탭이 노출되거나 사용자가 명시적으로 요청한 경우에만 마지막으로 조회합니다. 중앙대 학생 계정에서 files 401은 권한 거부일 수 있으므로 토큰 만료로 보고 재로그인하지 않습니다. modulebuilder의 not_open placeholder URL은 제외합니다. Canvas 잠금 항목은 acquisition_policy=not_open으로 반환합니다. 모든 항목에 asset_kind/downloadable/acquisition_policy/resolution_reason/fingerprint를 반환하며 downloadable=true와 acquisition_policy=download인 항목만 파일 도구에 전달합니다. ExternalTool은 모듈명으로 분류하지 않으며 resolve_external=true이면 미확인 래퍼를 LTI로 추가 확인합니다. 이 도구는 파일 본문을 다운로드하거나 ChatGPT에 첨부하지 않습니다. 파일은 eclass_download_file/eclass_download_materials_batch로 MCP 서버 로컬 캐시에 받은 뒤, ChatGPT가 읽어야 하면 eclass_file_handoff로 공개 /files/ URL을 별도 발급해야 합니다. 반환값은 { ok, course_id, sources, materials, errors, warnings } JSON 객체이며, 일부 source 실패 시 성공한 자료와 실패 정보를 함께 반환합니다.

Input Schema

TableJSON Schema

Name	Required	Description
`sources`	No	가져올 소스. 생략 시 modulebuilder, courseresource, announcements, modules, external을 조회한다. files는 Files 탭이 보이거나 명시적 요청이 있을 때 마지막으로 별도 조회한다.
`course_id`	Yes	강의 ID
`resolve_external`	No	미확인 ExternalTool을 LTI로 확인합니다. 파일을 저장하지 않으며 동일 메타데이터의 비재시도 결과는 SQLite에 보존합니다.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`errors`	No
`sources`	No
`warnings`	No
`course_id`	No
`materials`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already indicate read-only, non-destructive, idempotent behavior, but the description adds substantial context beyond annotations: multi-source aggregation and merging rules, partial-failure return behavior, exclusion of not_open placeholders, acquisition_policy handling for locked Canvas items, ExternalTool classification and LTI confirmation, and an explicit no-download boundary.

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 purpose is front-loaded, followed by source priority, edge cases, no-download boundary, and downstream flow. It is long but mostly earns its space for a complex aggregation tool; however, some content repeats the schema descriptions and output shape despite an existing output schema.

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

Completeness5/5

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

Complete for a complex cross-source material metadata tool: it covers default and exceptional source handling, merging rules, partial failures, return shape, downstream file-tool boundaries, and important Canvas/Chung-Ang edge cases. No critical invocation context appears missing.

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 description coverage is 100%, and the input schema already explains sources defaults, files behavior, and resolve_external LTI confirmation. The description largely repeats those points and adds little parameter-specific format or syntax guidance, so the baseline of 3 is appropriate.

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?

States a specific verb and resource: fetching course material list/metadata, with source domains enumerated in parentheses. It distinguishes itself from sibling tools by explicitly saying it does not download file bodies or attach to ChatGPT, and routes download/attachment needs to eclass_download_file, eclass_download_materials_batch, and eclass_file_handoff.

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

Usage Guidelines5/5

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

Gives explicit source priority (modulebuilder, courseresource, announcements, modules, external), when to include files last (Files tab visible or explicit user request), and when not to treat files 401 as token expiry. It also states the downstream condition for passing items to file tools only when downloadable=true and acquisition_policy=download, and names alternatives for actual downloads.

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