Skip to main content
Glama

bb_list_course_files

Read-onlyIdempotent

List every discoverable file in a Blackboard course, including nested content folders, using the course ID or unique name.

Instructions

遍历课程全部可发现的内容区及嵌套目录,列出文件;course 为 ID 或唯一名称。

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": "<course>"
    },
    "name": "bb_list_course_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
courseYes

Output Schema

NameRequiredDescriptionDefault
okNo
dataNo
errorNo
messageYes
completeNo
warningsNo
checked_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so safety is covered. The description adds genuine behavioral context beyond that: the traversal is recursive over all discoverable content areas and nested directories, warning the agent that the result set is broad. It does not mention pagination, size limits, or cost of a deep traversal.

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?

A single tight sentence plus a semicolon clause, front-loaded with the action and scope. Every clause carries information; nothing is repeated from the schema or annotations.

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?

For a one-parameter read tool with an output schema and full annotation coverage, the description supplies the traversal scope and the accepted parameter format, which is close to sufficient. Minor gaps remain around result size, pagination, and handling of inaccessible items.

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?

With only one parameter and 0% schema description coverage, the description compensates well by specifying that 'course' accepts either an ID or a unique name — the single most important calling detail. It does not address what happens with ambiguous or non-matching names.

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?

The description states a specific verb and resource ('list files' across course content areas and nested directories), which clearly separates it from bb_download_courseware or bb_list_courses. It stops short of naming any sibling explicitly, so the differentiation is implied by scope rather than stated.

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

Usage Guidelines3/5

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

Use is implied by 'list the files' in a course, but there is no explicit when-to-use or when-not guidance, and no pointer to an alternative such as a download tool for actually fetching content. The agent must infer the appropriate context.

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