PLATO MCP Server

Overview Schema Source Related Servers Discussions Admin

download_course_file

Read-only

Download course files from PLATO to save locally or retrieve inline, enabling offline access and viewing of course materials.

Instructions

Download a course file (the fileurl from get_course_contents).

Running locally (stdio, e.g. Claude Code/Desktop): saves the file to save_path on this machine and returns the saved path -- save_path is required in this case.

Running as a remote/hosted server (streamable-http, e.g. reached via a Claude.ai web/mobile Connector): this server's own disk is not reachable by you, so do NOT pass save_path -- it will be rejected. Instead the file is fetched here and returned inline as base64 content for you to decode and present, unless it's too large, in which case a direct authenticated download URL is returned instead (that URL embeds a live PLATO access token: do not share it or a chat transcript containing it).

Only common course-material extensions are allowed (pdf, office docs, images, zip, txt); local downloads over the configured size limit are rejected.

Input Schema

Name	Required	Description	Default
`file_url`	Yes	The `fileurl` value from get_course_contents.
`save_path`	No	Local filesystem path to save to. Required when running locally (stdio); must be omitted when running remotely over HTTP.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, it discloses local disk behavior, remote inline base64 or URL fallback, token sensitivity, rejection behavior for `save_path`, and extension/size limits. These are important operational traits for an agent invoking the tool correctly.

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 front-loaded with the core action, then structured by execution mode. Despite its length, each section carries necessary operational guidance rather than redundant explanation.

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?

Given the output schema and annotations, the description supplies the missing environment-dependent behavior, fallback handling, token warning, and file restrictions. An agent has enough information to call it correctly in either local or remote contexts.

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?

Schema coverage is 100%, so the schema already documents both parameters. The description still adds practical semantics by tying `file_url` to `get_course_contents` and emphasizing that remote calls must omit `save_path` because it will be rejected.

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?

The description gives a specific verb and resource: "Download a course file," and explicitly ties `file_url` back to `get_course_contents`, which distinguishes it from sibling retrieval tools.

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?

It clearly explains when to use each mode: local/stdio versus remote/hosted, including the exact `save_path` rule for each case. It also states allowed file types and size-limit constraints.

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

Deploy Server