Skip to main content
Glama
AnonymousOnyx22

D2L BrightSpace MCP

Get Assignments

get_assignments
Read-only

Fetch assignments and quizzes for a specific course or all enrolled courses. Shows dropbox submissions and quizzes with due dates, status, and rubric info.

Instructions

Fetch assignments and quizzes for a specific course or all enrolled courses. Shows dropbox submissions and quizzes with due dates, status, and rubric info. Use this when the user asks about assignments, homework, what to submit, quizzes, or assignment details and rubrics.

Input Schema

NameRequiredDescriptionDefault
courseIdNoCourse ID to get assignments for. If omitted, returns assignments for all enrolled courses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior3/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 useful content scope (due dates, status, rubric info) but says nothing about authentication, pagination, empty-result behavior, or ordering. With annotations carrying the safety burden, this is an adequate-but-thin addition.

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 with the core purpose front-loaded, then return content, then usage triggers. Every sentence earns its place and there is no filler.

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?

There is no output schema, so the description correctly compensates by describing what comes back (submissions, quizzes with due dates, status, rubric info). Combined with the annotations, an agent has enough to call it correctly; only ordering/volume behavior is unaddressed.

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 the single courseId parameter is fully documented, including the default behavior when omitted. The description adds no syntax, format, or constraint detail beyond the schema, so the baseline of 3 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?

Names a specific verb and resource ('Fetch assignments and quizzes') and states the scope ('a specific course or all enrolled courses'). It also enumerates the returned artifacts (dropbox submissions, quizzes), which helps separate it from sibling tools like get_todo or get_upcoming_due_dates, though it never names those siblings explicitly.

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?

The final sentence gives concrete user-intent triggers: 'assignments, homework, what to submit, quizzes, or assignment details and rubrics.' That is clear routing context, but it offers no exclusions or alternatives, so an agent must infer why it should pick this over get_todo or get_upcoming_due_dates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.