Skip to main content
Glama
Fireiscoolsolo

Canvas LMS MCP – Remote Edition

Get Topic

get_topic
Read-onlyIdempotent

Retrieve a Canvas discussion topic's prompt, author, posting rules, and unread count without loading replies; use it to inspect topic details read-only.

Instructions

Get one discussion topic: its prompt, author, posting rules and unread count, without the replies. Read-only. The prompt is fenced as untrusted text. Use get_full_topic_view to read the whole thread, or list_topics to find topic IDs.

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

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the prompt is 'fenced as untrusted text', which is a security-handling instruction not captured in structured fields, and it clarifies that replies are omitted. Minor gap: no mention of error behavior for invalid topic IDs.

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?

Three tight sentences front-load the core action and payload, then the exclusion, then the routing alternatives. No filler.

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?

No output schema exists, but the description enumerates the returned fields and their scope, and the untrusted-text fencing note covers the main correctness hazard. Nothing an agent needs to call this correctly is missing.

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% and both parameters document their source (list_topics, list_courses), so the schema carries the semantics. The description adds nothing about parameter format beyond that, which is the expected baseline.

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 and resource ('Get one discussion topic') and enumerates exactly what comes back (prompt, author, posting rules, unread count) plus the explicit exclusion of replies. An agent can distinguish it from get_full_topic_view and list_topics without opening any schema.

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?

Names both alternatives and the conditions that select them: get_full_topic_view for the whole thread, list_topics to find topic IDs. This is explicit when/when-not routing.

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