PLATO MCP Server

Overview Schema Source Related Servers Discussions Admin

submit_assignment

Destructive

Submit assignment text and/or file attachments after previewing with dry_run=True, then confirm with dry_run=False to send the final submission to Moodle.

Instructions

Submit text and/or file attachments for an assignment. IRREVERSIBLE once dry_run=False.

Call with dry_run=True (default) first, show the preview to the user, and only call again with dry_run=False (same parameters) after they explicitly confirm. Provide text, file_paths/file_contents, or both -- whichever this assignment actually accepts (see get_assignment_detail).

file_paths works only when this server is running locally (stdio, e.g. Claude Code/Desktop) -- rejected with a clear error over a remote (streamable-http, e.g. a Claude.ai Connector) connection, mirroring download_course_file's own stdio-vs-remote split. file_contents works over either transport and is the only option remotely, since this server's disk is not reachable by you there.

Input Schema

Name	Required	Description
`text`	No	Plain-text submission content. Omit (empty string) for a file-only submission. Rejected if this assignment doesn't accept online text -- check get_assignment_detail's onlinetext_submission.enabled first.
`dry_run`	No	If True (default), only preview the submission without sending it. Call again with dry_run=False (same parameters) to actually submit it.
`course_id`	Yes	PLATO/Moodle numeric course id, e.g. from list_courses.
`file_paths`	No	Local filesystem paths to upload as file attachments. Only works when this server is running locally (stdio) -- rejected with a clear error over a remote/streamable-http connection (use file_contents there instead). Rejected if this assignment doesn't accept file submissions, exceeds its max file count/size, or uses a disallowed extension -- check get_assignment_detail's file_submission (enabled/max_files/max_size_bytes/allowed_extensions) first.
`assignment_id`	Yes	Assignment id, e.g. from list_assignments.
`file_contents`	No	File attachments as {filename, content_base64} -- works over either transport, and is the only way to attach files when this server is running remotely (streamable-http), since it has no local filesystem to read a path from there. Each file is capped at 5MB decoded, in addition to this assignment's own max file count/size/extension rules (see get_assignment_detail's file_submission).

Output Schema

Name	Required	Description	Default
`dry_run`	Yes
`message`	Yes
`preview`	Yes
`executed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructive=true, non-idempotent, non-readonly; the description adds real value beyond that by naming the exact irreversible step and the confirmation workflow that mitigates it. It also discloses a failure mode (remote transport rejects file_paths with a clear error) that annotations cannot express. Slight deduction because it doesn't mention grading/deadline side effects, but the safety profile is well covered.

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 the action and the irreversibility warning, then the workflow, then transport constraints — a sensible order. Slightly verbose in the parenthetical transport explanation, but every sentence carries operational meaning.

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 a mutation tool with an output schema, full annotations, and 100% schema coverage, the description supplies everything missing: confirmation protocol, reversibility, prerequisite lookup step, and transport-dependent behavior with the documented workaround.

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 baseline is 3; the description nevertheless adds a cross-parameter rule not stated per-field ('provide text, file_paths, or both — whichever this assignment accepts') and cross-references get_assignment_detail for acceptance checks. This is useful consolidation on top of rich schema docs, though most individual parameter detail is duplicated.

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+resource (submit text/attachments for an assignment) and immediately flags the defining trait (irreversibility once dry_run=False). No sibling tool submits assignment content, and the description makes that distinct scope obvious.

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 an explicit two-phase protocol (preview with dry_run=True, show user, re-call with dry_run=False after confirmation) plus a pointer to get_assignment_detail to decide which submission mode applies. Transport-based guidance ('file_paths only locally, file_contents remotely') tells the agent exactly which alternative to pick under which condition.

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

Deploy Server