Submit Canvas assignments by uploading files, text, or links for a course and assignment. Defaults to a preview plan; use confirm=true to submit.
提交 Canvas 作业（写操作，需 Canvas API token）：上传文件 / 文本 / 链接。缺省只预检返回提交计划；confirm=true 才真正提交。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 链接提交地址（online_url）。 | |
| text | No | 文本提交内容（online_text_entry）。 | |
| files | No | 本地文件路径列表（online_upload 提交方式）。 | |
| course | Yes | 课程 id 或名称关键词。 | |
| confirm | No | true 时真正提交；缺省只预检。文件/文本/链接三选一。 | |
| assignment | Yes | 作业 id 或名称关键词。 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does well: it flags the tool as a write operation, states that a Canvas API token is required, and discloses the dry-run-by-default safety behavior. What it omits is the consequence side — whether a submission can be withdrawn or overwritten, and whether multiple submission types can be combined in one call beyond the '三选一' hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses, front-loaded with the operation and its write/auth characteristics, followed by the dry-run rule. No filler, and the most decision-relevant fact (nothing is submitted without confirm=true) is easy to spot.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essentials for a mutating tool with no output schema: what it writes, required auth, the safe-default gate, and the payload options. It does not describe what the pre-check plan contains or what a successful submission returns, which leaves a small gap for an agent deciding how to interpret the dry-run response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter including the file/text/url mapping and the confirm semantics. The description's only added meaning is the mutual-exclusivity framing ('三选一'), which is also repeated in the confirm field description, so it sits at the baseline rather than above it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('提交 Canvas 作业') and enumerates the three submission payload types (file/text/URL), which is more than a restatement of the name. It does not explicitly distinguish itself from the sibling canvas_upload (file upload to Canvas), so an agent could still hesitate between the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear operating rule: default is a dry-run that returns a submission plan, and confirm=true is required to actually submit. That is strong when-to-act guidance, but there is no statement of when NOT to use this tool (e.g., use canvas_upload for staging files, canvas_assignment_info for checking requirements) or how resubmission behaves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.