Skip to main content
Glama

PLATO MCP

by io.github.jin-1119
OverviewDiscussionsAdmin

download_course_file

Read-only

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

NameRequiredDescriptionDefault
file_urlYesThe `fileurl` value from get_course_contents.
save_pathNoLocal filesystem path to save to. Required when running locally (stdio); must be omitted when running remotely over HTTP.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the `readOnlyHint` and `openWorldHint` annotations: it explains the two return modes (saved path vs. inline base64 vs. authenticated URL), the token-bearing URL security risk, allowed file extensions, and local size-limit rejection. That is exactly the behavioral context an agent needs before invoking it.

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 description front-loads the purpose and then organizes behavioral details by environment. It is somewhat long, but the length is justified by the genuinely mode-dependent behavior and security warning; little is redundant.

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?

Covers all the complexity an agent needs: required parameter source, environment-specific `save_path` rules, three possible return shapes, extension constraints, size limits, and token-handling warnings. With an output schema present, no important behavioral gap remains.

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 schema already documents the local-required/remote-forbidden semantics of `save_path`. The description reinforces those constraints but adds no new parameter-level detail beyond what the schema provides, so the baseline for high coverage applies.

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 course file') and anchors the required `file_url` to its source in `get_course_contents`. This clearly distinguishes it from the sibling listing tool that only returns file metadata.

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?

Provides clear context for when to use it in each deployment mode (local stdio vs. remote HTTP) and explicitly says not to pass `save_path` remotely. It does not name alternative tools for related tasks, but the usage conditions for this tool itself are unambiguous.

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

All PLATO MCP toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources