Skip to main content
Glama
RohanMuppa

Brightspace MCP Server

by RohanMuppa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Video Transcript

get_video_transcript

Retrieve timestamped transcript text from videos embedded in Brightspace course content, such as recorded lectures. Supports Kaltura and YouTube, with paging for long transcripts.

Instructions

Read the transcript of a video embedded in course content, such as a recorded lecture or explainer clip. Call it with courseId and topicId from get_course_content (typeFilter: 'video' or 'other'), or with videoUrl directly if you already have the link. Returns transcript text with timestamps, plus title and duration when available. Currently supports Kaltura (e.g. BoilerCast) and YouTube; other platforms return a clear message naming what isn't supported yet. Use offset/maxChars to page through a long transcript. Read only — this never marks the video as watched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoCharacter offset into the transcript to resume from. Pass back nextOffset from a truncated response to fetch the next piece.
topicIdNoContent topic ID (from get_course_content) whose embedded video to transcribe. Requires courseId.
courseIdNoCourse ID the video belongs to. Required together with topicId unless videoUrl is given directly.
maxCharsNoMaximum characters of transcript text to return in one call. The response reports whether it was truncated.
videoUrlNoDirect video URL to transcribe, e.g. the url field get_course_content already returned. Use instead of courseId/topicId when you already have the link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.9.7

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it declares read-only behavior ('never marks the video as watched'), enumerates supported platforms, and describes the unsupported-platform fallback message. It omits any auth/permission or rate-limit context, but covers the important side-effect disclosure.

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?

Four sentences, front-loaded with purpose then call patterns then return/limitations/read-only. Every sentence earns its place with no redundancy.

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, yet the description specifies return contents (timestamped transcript text, title, duration when available, truncation signal). Combined with platform and pagination notes, an agent has everything needed to call it correctly.

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 adds cross-parameter relationships — the courseId/topicId pairing vs. standalone videoUrl, and the offset/maxChars paging loop — giving meaning beyond isolated field docs.

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 (read) and resource (transcript of a video embedded in course content), scoping it to recorded lectures/clips. Clearly distinguishable from sibling content tools like get_course_content.

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 invocation paths: courseId+topicId sourced from get_course_content (typeFilter 'video'/'other'), or videoUrl directly. Names platform limits (Kaltura/YouTube only) and pagination via offset/maxChars.

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