Skip to main content
Glama
chrischall

canvas-parent-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

canvas_list_conversations

Read-only

List Canvas inbox conversations with optional filters for scope (unread, starred, archived, sent) and context codes (course, group, user).

Instructions

List Canvas inbox conversations. Optional scope (unread/starred/archived/sent) and filter (array of context codes).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact removes the avatar URLs Canvas attaches to user objects (avatar_url, avatar_image_url); "full" returns Canvas's payload untouched. Link fields (url, html_url, preview_url) survive both rungs. No field projection: this server passes Canvas's payload through verbatim and has no verified record of which of its fields a caller needs.
scopeNo
filterNoArray of context codes (course_X, group_X, user_X).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changedv1.5.4
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact removes the avatar URLs Canvas attaches to user objects (avatar_url, avatar_image_url); \"full\" returns Canvas's payload untouched. Link fields (url, html_url, preview_url) survive both rungs. No field projection: this server passes Canvas's payload through verbatim and has no verified record of which of its fields a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. Addedv1.2.5

TDQS

C2.7/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context of its own: no pagination behavior, no default view, no note that it returns a conversation collection while canvas_get_conversation returns one, and no auth or rate-limit hints.

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, front-loaded with the purpose and no filler. Nothing is wasted, though the second sentence could have spent its words on the undocumented `view` parameter rather than repeating enum values.

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

Completeness2/5

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

There is no output schema, so the description must carry return-shape information, yet it says nothing about the response format (compact vs full), pagination, or ordering. Combined with the missing sibling differentiation and the ignored `view` parameter, it is under-specified for a list endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema coverage, the schema already documents `filter` and the complex `view` parameter in detail. The description merely restates the `scope` enum values (already in the schema) and briefly echoes `filter`, while completely omitting `view`, the parameter with the richest semantics.

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 clear verb+resource: 'List Canvas inbox conversations.' The plural 'List' plus the resource distinguishes it implicitly from the singular sibling canvas_get_conversation, but it never names that sibling or any other, so the differentiation is left to inference.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of the sibling canvas_get_conversation for retrieving a single thread, and no indication of when unread/starred/archived/sent scopes matter. The description simply enumerates optional parameters.

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