Skip to main content
Glama
Sign In
vishalsachdev

Canvas MCP Server

by vishalsachdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Send Peer Review Followup Campaign

send_peer_review_followup_campaign

Analyze peer review completion analytics, preview urgent and gentle reminder recipients, then send targeted follow-ups only after educator approval.

Instructions

Complete workflow: analyze peer reviews and send targeted reminders.

Two-step by design. Call it without a confirmation_token to get the analytics plus a preview of who would receive urgent vs gentle reminders and a token; show that to the educator, and only after they approve it call again with the token to actually send. The token is void if the completion analytics shifted in between.

Input Schema

NameRequiredDescriptionDefault
assignment_idYesCanvas assignment ID
course_identifierYesCourse code or Canvas ID
confirmation_tokenNoToken from the preview call; omit to preview

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.8.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / assignment_id / description
      Added value: +"Canvas assignment ID"
    • removedInput schema / properties / assignment_id / title
      Removed value: -"Assignment Id"
    • addedInput schema / properties / confirmation_token
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Token from the preview call; omit to preview"
+}
    • addedInput schema / properties / course_identifier / description
      Added value: +"Course code or Canvas ID"
    • removedInput schema / properties / course_identifier / title
      Removed value: -"Course Identifier"
    • removedInput schema / title
      Removed value: -"send_peer_review_followup_campaignArguments"
    • removedOutput schema / title
      Removed value: -"send_peer_review_followup_campaignDictOutput"
  2. Changed1 schema field changedv1.0.0
    • addedInput schema / title
      Added value: +"send_peer_review_followup_campaignArguments"
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations (idempotentHint: false, destructiveHint: false), the description adds that the token becomes void if completion analytics shift, and that a preview must be shown to the educator for approval before sending. It could say more about the reminder channel, but this is strong additional context.

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 two tight paragraphs with zero waste, front-loading the workflow purpose and then the two-step mechanics. Every sentence earns its place.

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?

Given the complexity of a two-step, token-gated send operation, the description covers the critical workflow, token invalidation, and approval requirement. An output schema exists so return values need not be explained. Minor details like reminder delivery channel or error handling for a void token are omitted, but the definition is largely complete.

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 adds meaning beyond the schema by explaining that the confirmation_token is void if the completion analytics changed, which clarifies the token's lifecycle.

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 states a specific verb+resource: analyze peer reviews and send targeted reminders. The 'complete workflow' and 'two-step by design' framing distinguishes it from single-step siblings like get_peer_review_completion_analytics.

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?

It gives explicit usage instructions: call without confirmation_token to preview analytics and recipients, then call again with the token after educator approval. It does not name alternatives or when-not-to-use, keeping it from a 5.

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