Skip to main content
Glama
oliverhruby

EduPage MCP Server

download_attachment

DestructiveIdempotent

Saves any authenticated school attachment — homework, message, or event files — to a local directory as raw bytes, refusing login pages and avoiding overwrites.

Instructions

Download one attachment from the school to disk. Writes: creates a local file.

Saves any authenticated attachment — homework material, message and event attachments alike, which is what get_timeline puts in additional_data.attachements and get_homework_material lists — as the raw response bytes, never overwriting (a ' (1)', ' (2)', ... suffix is appended instead). School pages are not attachments: an HTML or login page is refused rather than written out. Because the bytes go to disk untouched, this is the only tool that returns a binary attachment intact; custom_request refuses one.

Args: url: Absolute attachment URL, or a school-relative path such as '/elearning/ruqjzfpv?z%3A…' — the exact form get_timeline(category='recent') returns in additional_data.attachements — resolved against the school origin. Any authenticated attachment URL works, not just homework: message and event attachments included. The request is authenticated with the school's session. dest_dir: Directory to save into, created when missing. Defaults to <tempdir>/homework (e.g. .../AppData/Local/Temp/homework). filename: Save under this name instead of the server-suggested one. Directory components and characters illegal on the filesystem are stripped, so the file always lands directly inside dest_dir. subdomain: School whose session authenticates the request (defaults to the active subdomain).

Returns: dict: {'saved_to', 'bytes', 'source_url', 'name'}.

Notes: - The only tool in this server that writes to disk, and the only one excluded from the read-only e2e suite — call it only on request. - Verified live 2026-10-02: a bad or expired attachment token is a plain HTTP 404, and a school page fetched without a session answers HTTP 200 with the login page. Both raise instead of writing a file, so a saved attachment is always real bytes. - The name comes from content-disposition when the server sends it, otherwise from the URL path. - Bounded by the library session's 5 s request timeout (Edupage(request_timeout=5)), so very large attachments can fail.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
dest_dirNo
filenameNo
subdomainNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses non-overwriting with a ' (1)', ' (2)' suffix, that bytes are written raw and unmodified, that bad/expired tokens return HTTP 404 while an unauthenticated school page returns HTTP 200 with a login page (and both raise rather than write), and the 5 s request-timeout ceiling. That is exactly the destructive/auth/failure context an agent cannot get from the readOnly/destructive/openWorld hints.

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-loaded with the core action and the write warning, then cleanly sectioned into Args/Returns/Notes. It is long and repeats itself somewhat (the 'any authenticated attachment, not just homework' point appears twice), but nearly every sentence carries operational information.

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?

Despite having no output schema, it lists the returned dict keys ({'saved_to','bytes','source_url','name'}) and covers defaults, filename derivation from content-disposition, error modes, and a timeout limitation. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (only titles, no descriptions), so the description carries the full burden and does so for all four parameters: `url` (absolute vs. school-relative path with the exact form `get_timeline` returns), `dest_dir` (default `<tempdir>/homework`, auto-created), `filename` (illegal characters stripped, always lands directly in `dest_dir`), and `subdomain` (defaults to the active subdomain).

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?

Specific verb + resource: 'Download one attachment from the school to disk. Writes: creates a local file.' It explicitly distinguishes itself from siblings by being the only tool that returns a binary attachment intact, noting that `custom_request` refuses one and pointing at `get_timeline`/`get_homework_material` as the sources of valid URLs.

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

Usage Guidelines4/5

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

Gives a real gating rule ('the only tool in this server that writes to disk ... call it only on request') and clarifies that school/login pages are not valid input, which steers the agent away from misuse. It stops short of an explicit when-to-use-X-instead-of-Y routing statement, but the contrast with `custom_request` supplies most of that context.

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