Skip to main content
Glama
RohanMuppa

Brightspace MCP Server

by RohanMuppa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Course Content

get_course_content

Retrieve course content structure to find materials like lecture slides, files, and links. Filter by module title or depth.

Instructions

Fetch the content tree for a course showing modules, topics, files, and links. Use this when the user asks about course materials, lecture slides, uploaded files, content structure, or what's in a course module. Use moduleTitle to filter to a specific module (e.g. 'Labs', 'Staff', 'Homeworks') instead of fetching the entire tree. Use maxDepth to limit recursion depth for a table-of-contents view. A module or topic that isn't currently available carries isAvailable/availabilityStatus/availabilityMessage (and startDate/endDate when known) explaining why; absence of these fields means it's available now.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
courseIdYesCourse ID to get content tree for.
maxDepthNoLimit recursive depth of the content tree. Depth 1 returns top-level modules with direct children only. Useful for getting a table of contents without all nested content.
typeFilterNoOptional filter to narrow results by content type.all
moduleTitleNoCase-insensitive substring match on module titles. Only returns modules whose title contains this string (e.g. 'Labs', 'Staff', 'Homeworks'). Children of matching modules are included in full.
modifiedSinceNoOnly return topics last modified at or after this ISO 8601 datetime (e.g. 2026-01-15T00:00:00Z), plus any module that contains a matching topic. Topics with no modified timestamp are always included. When set, the response reports how many topics were filtered out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.9.7
    • addedInput schema / properties / modifiedSince
      Added value: +{
+  "description": "Only return topics last modified at or after this ISO 8601 datetime (e.g. 2026-01-15T00:00:00Z), plus any module that contains a matching topic. Topics with no modified timestamp are always included. When set, the response reports how many topics were filtered out.",
+  "format": "date-time",
+  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+  "type": "string"
+}
  2. First observedv1.0.7

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it explains that unavailable modules/topics expose isAvailable/availabilityStatus/availabilityMessage (plus startDate/endDate) and that field absence means currently available — non-obvious return-shape behavior. It omits any note on response size, pagination, or auth expectations.

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?

Front-loads the core fetch statement, then usage triggers, then parameter tips, then the availability caveat. Every sentence carries distinct information with no repetition.

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?

No output schema exists, so the description must convey return structure, and it names the node types and the availability-field convention. It is largely sufficient for a read-only fetch, though a fuller account of nesting/output shape would complete it.

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 the schema already documents all five parameters (baseline 3). The description still adds value by giving concrete moduleTitle examples ('Labs', 'Staff', 'Homeworks') and framing maxDepth as a table-of-contents view, reinforcing the intended usage.

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 (fetch) and resource (the content tree for a course) and enumerates its shape — modules, topics, files, links. This lets an agent distinguish it from siblings like get_syllabus or get_my_courses without opening a schema.

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?

Gives explicit positive triggers ('course materials, lecture slides, uploaded files, content structure, or what's in a course module') and tells the agent to use moduleTitle to target a single module rather than pulling the whole tree. It does not name a sibling tool as an alternative or state any when-not condition, so it stops short of the top score.

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