Skip to main content
Glama
jseook11

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

Download File

eclass_download_file

Download lecture files to the MCP server's local disk/cache and return local_path and file_id records, not file content. Use the returned file_id with eclass_file_handoff to open files when needed.

Instructions

[네트워크] 강의 파일을 MCP 서버 로컬 디스크/캐시에 다운로드합니다. 이 도구는 ChatGPT에 파일 본문을 전달하지 않고 local_path/file_id 같은 서버 측 기록만 반환합니다. ChatGPT가 파일을 읽어야 하면 반환된 file_id로 eclass_file_handoff를 호출해 공개 /files/ URL을 발급하고, 그 URL을 브라우징으로 직접 열어야 합니다. 과목과 원본 ID가 일치하는 캐시 파일은 건너뜁니다. acquisition_policy/downloadable을 함께 전달하세요. 동영상/interactive/미확인/잠김은 정상 제외 상태로 반환하며 실제 실패만 isError=true와 JSON error_code/retryable을 반환합니다. 동영상은 eclass_download_video를 사용하세요.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes다운로드 URL (courseresource 파일은 null 허용 — Playwright로 다운로드)
typeNo자료 유형. ExternalTool은 LTI 런치 후 실제 파일을 찾습니다. mp4/video/m3u8 계열은 파일 도구에서 거부되며 eclass_download_video 대상입니다.
sourceNo
file_idYesCanvas 파일 ID
course_idYes강의 ID
unlock_atNo
asset_kindNo
module_nameNo
display_nameYes저장할 파일명
downloadableNo
external_urlNo
locked_for_userNo
resolution_reasonNo
acquisition_policyNo
is_playright_requiredNois_playwright_required의 이전 오탈자 별칭. 둘 중 하나면 런치 경로를 탑니다.
is_playwright_requiredNotrue면 eclass3 래퍼 URL이어도 ExternalTool LTI 런치로 처리합니다.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNo
statusNo
file_idYes
messageNo
skippedNo
strategyNo
retryableNo
error_codeNo
local_pathNo
size_bytesNo
next_actionNo
display_nameYes
failure_kindNo
handoff_noteNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Adds substantial behavior beyond the sparse annotations: cached files matching course+original ID are skipped, video/interactive/unresolved/locked items are returned as normal exclusion states rather than errors, and only real failures set isError=true with error_code/retryable. This is rich. A minor gap remains around what local_path/file_id actually contain and permission needs.

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?

Front-loads purpose and scope in the opening sentence, then layers the handoff workflow, cache rule, and error semantics. Dense but every clause carries operational weight; slightly verbose but not padded.

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?

An output schema exists, so return values need not be detailed, yet the description still explains the returned records and error contract well. For a 16-param tool the main residual gap is per-parameter meaning, but the workflow and behavioral model are complete enough to invoke correctly.

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?

With 16 parameters and only 44% schema description coverage, the description compensates for some: it explains the acquisition_policy/downloadable pairing and the file_id's role in handoff. But many parameters (source, unlock_at, module_name, resolution_reason, external_url, locked_for_user, asset_kind) receive no explanation in either schema or description, leaving real gaps.

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 (download a lecture file to the MCP server's local disk/cache) and immediately clarifies the crucial scope distinction: it does NOT deliver the file body to ChatGPT, only server-side records like local_path/file_id. It explicitly distinguishes itself from eclass_download_video and routes reading through 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?

Explicitly names when to use each alternative: use eclass_file_handoff with the returned file_id to get a public /files/<token> URL when ChatGPT needs to read the file, and use eclass_download_video for videos. It also states prerequisites (pass acquisition_policy/downloadable together) and the cache-skip condition.

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