Skip to main content
Glama
andrsnrua
by andrsnrua

blackboard_list_course_links

Read-onlyIdempotent

List HTTP/HTTPS links published on a Blackboard course's pages or contentHandler.url, with path and internal/external origin. Provide a course ID to collect references.

Instructions

Enlaces HTTP/HTTPS publicados en páginas o contentHandler.url del curso, con ruta y origen interno/externo. No abre ni autentica servicios externos.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
courseIdYes
maxDepthNoProfundidad máxima; 20 por defecto
maxItemsNoContenidos a examinar; 300 por defecto
maxResultsNoCoincidencias devueltas; 50 por defecto

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A3.5/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 openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: it clarifies that despite the open-world hint it 'does not open or authenticate external services', which tells the agent no outbound calls or credentials are involved, and it specifies the sources it scans (pages and contentHandler.url).

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?

Two compact sentences with zero filler, leading immediately with what is collected and closing with the negative capability that constrains interpretation. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 sketches the return shape (links with route and origin), and annotations carry the safety profile. Still missing is any usage context or note on result limits/pagination interaction with maxResults, leaving the agent with an adequate but not fully complete picture.

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 coverage is 75% (maxDepth, maxItems, maxResults all documented with defaults), so the schema does most of the work. The description contributes nothing about parameters — courseId's format and the crawl-limit semantics are handled entirely in the schema.

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 names a specific resource (HTTP/HTTPS links found in course pages and contentHandler.url) and its scope (path plus internal/external origin), so the agent knows what kind of output to expect. It does not, however, contrast itself with adjacent tools like list_attachments, list_course_files, or list_contents, so sibling differentiation is left to inference.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of alternatives such as list_contents or list_course_files. The agent must guess when link extraction is preferable to generic content listing.

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