Skip to main content
Glama
Fireiscoolsolo

Canvas LMS MCP – Remote Edition

Mark All Entries Read

mark_all_entries_read

Set every entry in a Canvas discussion topic to read to clear your unread counts; only your read status changes.

Instructions

Mark every entry in a discussion topic as read for you. Only affects your unread counts.

Input Schema

NameRequiredDescriptionDefault
topic_idYesDiscussion topic ID (numeric string). Get it from list_topics.
course_idYesCanvas course ID, a numeric string such as "12345". Get it from list_courses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.3
    • changedInput schema / properties / course_id / description
      Previous value: -"Canvas course ID"New value: +"Canvas course ID, a numeric string such as \"12345\". Get it from list_courses."
    • changedInput schema / properties / topic_id / description
      Previous value: -"Canvas ID (numeric string)"New value: +"Discussion topic ID (numeric string). Get it from list_topics."
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely useful blast-radius context ('only affects your unread counts'), but it does not say whether already-read entries cause errors, whether the call is repeatable, or what happens on a missing topic — notable given idempotentHint=false.

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?

Two short sentences with zero filler, and the scope-and-effect statement is front-loaded where an agent will read it before deciding to call.

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?

A simple two-parameter mutation with fully documented inputs and no output schema; the description covers what changes and whose state changes, which is the main thing an agent needs. It is slightly thin on error/failure behavior for a non-idempotent write, keeping it just under a 5.

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%: both course_id and topic_id carry inline descriptions and even point at list_courses / list_topics for discovery. The description adds no parameter-level meaning, so the baseline 3 for schema-complete tooling applies.

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 ('Mark ... as read') plus a precise resource and scope ('every entry in a discussion topic'), and the phrase 'every entry' implicitly distinguishes it from the single-entry sibling mark_entry_read. It does not name that sibling outright, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'for you' and 'Only affects your unread counts' give useful scoping context, implying this is a bulk personal-state update rather than a global change. However, it never states when to prefer this over mark_entry_read or mark_topic_read, so selection guidance is only implied.

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