Skip to main content
Glama

List New Quiz Items

list_new_quiz_items
Read-only

Lists every item in a Canvas New Quiz LTI in quiz order, returning IDs, positions, points, entry types, and full bodies with interaction and scoring data so correct answers are visible.

Instructions

List every item (question or stimulus) in a New Quiz (LTI), in quiz order, returning each item's id, position, points_possible, entry_type, and full entry body — including interaction_data and scoring_data, so the correct answer is visible in the result. Find the assignment_id with list_assignments or get_assignment, filtered on is_quiz_lti_assignment (not a Classic Quiz ID). Use get_new_quiz_item to refetch a single item by id, create_new_quiz_item to add one, update_new_quiz_item to change one, and delete_new_quiz_item to remove one. Fetches every page (100 per request) and fails with a 'Results are incomplete' error instead of silently truncating.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "course_id": "<course_id>",
      "assignment_id": "<assignment_id>"
    },
    "name": "list_new_quiz_items"
  }
}

Input Schema

NameRequiredDescriptionDefault
course_idYesThe Canvas course ID
assignment_idYesThe assignment ID of the New Quiz

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.18.15
    • addedInput schema / properties / assignment_id / anyOf
      Added value: +[
      +  {
      +    "exclusiveMinimum": 0,
      +    "maximum": 9007199254740991,
      +    "type": "integer"
      +  },
      +  {
      +    "pattern": "^[1-9][0-9]{0,18}$",
      +    "type": "string"
      +  }
      +]
    • removedInput schema / properties / assignment_id / type
      Removed value: -"number"
    • addedInput schema / properties / course_id / anyOf
      Added value: +[
      +  {
      +    "exclusiveMinimum": 0,
      +    "maximum": 9007199254740991,
      +    "type": "integer"
      +  },
      +  {
      +    "pattern": "^[1-9][0-9]{0,18}$",
      +    "type": "string"
      +  }
      +]
    • removedInput schema / properties / course_id / type
      Removed value: -"number"
  2. Changed1 schema field changedv1.18.11
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv1.18.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing pagination behavior (100 per request, fetches every page) and the failure mode ('Results are incomplete' error rather than silent truncation). It also reveals that interaction_data and scoring_data are included, making correct answers visible — non-obvious payload detail.

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 sentences, each with a distinct job: what is returned, how to obtain the required ID and which sibling to pick instead, and pagination/failure behavior. Return payload is front-loaded before alternatives, and no sentence is 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?

With no output schema, the description compensates by naming the returned fields (id, position, points_possible, entry_type, entry body with interaction_data and scoring_data) and the error condition. Nothing an agent needs to invoke or interpret this call correctly is missing.

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 both course_id and assignment_id are already documented, making 3 the baseline. The description adds real semantic constraint by specifying that assignment_id must be a New Quiz (LTI) assignment ID and not a Classic Quiz ID, which is the main ambiguity an agent would hit.

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 ('List every item (question or stimulus) in a New Quiz (LTI), in quiz order') and enumerates the returned fields, so an agent knows exactly what it gets. It also disambiguates from Classic Quiz tooling by noting the assignment must be a New Quiz (LTI) assignment, not a Classic Quiz ID.

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?

Gives explicit prerequisite routing: find assignment_id via list_assignments or get_assignment filtered on is_quiz_lti_assignment. It then names the four sibling alternatives and the exact conditions that select each (get for refetch by id, create to add, update to change, delete to remove).

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