Skip to main content
Glama
Sign In
vishalsachdev

Canvas MCP Server

by vishalsachdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Delete Announcement With Confirmation

delete_announcement_with_confirmation
DestructiveIdempotent

Delete a Canvas course announcement with a two-step flow: preview the target first, then confirm using the returned token.

Instructions

Delete an announcement. Two-step: preview first, then confirm with the token.

Permanent — Canvas may retain a recycle-bin copy depending on admin settings.

Input Schema

NameRequiredDescriptionDefault
announcement_idYesAnnouncement ID to delete
course_identifierYesCourse code or Canvas ID
confirmation_tokenNoToken from the preview call; omit to preview
require_title_matchNoOnly delete if title matches this string exactly

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.12.0
    • addedInput schema / properties / confirmation_token
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Token from the preview call; omit to preview"
+}
    • removedInput schema / properties / dry_run
      Removed value: -{
-  "default": false,
-  "description": "Verify but don't actually delete (default: False)",
-  "type": "boolean"
-}
  2. Changed1 schema field changedv1.10.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  3. Changed13 schema fields changedv1.8.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / announcement_id / description
      Added value: +"Announcement ID to delete"
    • removedInput schema / properties / announcement_id / title
      Removed value: -"Announcement Id"
    • addedInput schema / properties / course_identifier / description
      Added value: +"Course code or Canvas ID"
    • removedInput schema / properties / course_identifier / title
      Removed value: -"Course Identifier"
    • addedInput schema / properties / dry_run / description
      Added value: +"Verify but don't actually delete (default: False)"
    • removedInput schema / properties / dry_run / title
      Removed value: -"Dry Run"
    • addedInput schema / properties / require_title_match / description
      Added value: +"Only delete if title matches this string exactly"
    • removedInput schema / properties / require_title_match / title
      Removed value: -"Require Title Match"
    • removedInput schema / title
      Removed value: -"delete_announcement_with_confirmationArguments"
    • removedOutput schema / properties / result / title
      Removed value: -"Result"
    • removedOutput schema / title
      Removed value: -"delete_announcement_with_confirmationOutput"
    • addedOutput schema / x-fastmcp-wrap-result
      Added value: +true
  4. Changed1 schema field changedv1.0.0
    • addedInput schema / title
      Added value: +"delete_announcement_with_confirmationArguments"
  5. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is covered; the description earns credit for adding the two-step preview/confirm protocol and the nuance that deletion is permanent but Canvas may retain a recycle-bin copy depending on admin settings. That recycle-bin caveat is non-obvious behavior an agent could not infer from the annotations.

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?

Two short sentences with no filler; the core action and the gating two-step workflow are front-loaded, and the permanence warning is placed as a distinct trailing note. Slightly terse rather than padded — no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, four-parameter mutation tool with no output schema, the description covers the critical unknowns: the confirmation-token workflow and the true reversibility picture. It does not describe what the preview call returns or when require_title_match should be set, which leaves a modest gap for an agent designing the preview step.

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%, so the schema already documents announcement_id, course_identifier, confirmation_token and require_title_match. The description reinforces the token semantics ('preview first, then confirm with the token') but adds nothing about require_title_match or accepted identifier formats, so it sits at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Delete an announcement.' An agent knows immediately what the tool does. However, it does not distinguish this from the sibling tools bulk_delete_announcements and delete_announcements_by_criteria, leaving ambiguity about which delete path to take.

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?

'Two-step: preview first, then confirm with the token' gives an explicit operating procedure that governs how the call must be sequenced, which is real usage guidance. It stops short of stating when to prefer this single-item tool over the bulk-delete siblings, so no explicit exclusivity rule is given.

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

Deploy Server

Other Tools