Skip to main content
Glama
andrsnrua
by andrsnrua

blackboard_export_attendance

Export your course attendance to a private CSV filtered by sessions, with absent records left blank. Only your account data is included.

Instructions

Guarda CSV privado de tu asistencia filtrada por sesiones del curso; registros ausentes quedan vacíos. No exporta otras cuentas.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
courseIdYes
outputDirNo
allowPartialNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true. The description adds real context beyond them: the output is a private CSV, missing records are left empty, and the export scope is limited to the caller's own account. It does not say whether an existing file is overwritten, which is the main remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact, front-loaded sentences that lead with the action and the artifact produced, then add the scope caveat. No filler, though the second sentence's value is modest.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write/export tool with 0% schema coverage, no output schema and three unexplained parameters (including a patterned required id), the description leaves too much unstated. It conveys what is produced and its scope, but not the courseId format, the meaning of outputDir or allowPartial, or overwrite behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description explains none of the three parameters. The required courseId carries a cryptic pattern '^_\d+_\d+$' that is undocumented in both schema and description, and outputDir / allowPartial are completely unexplained, so the description fails to compensate for the coverage gap.

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: 'Guarda CSV privado de tu asistencia' (saves a private CSV of your attendance), which tells the agent it is a file-export operation rather than a read. It implicitly distinguishes itself from the sibling blackboard_get_my_attendance by emphasizing the CSV export, but it never names that sibling or any alternative.

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?

Usage is implied by 'Guarda CSV' (use this when you want a saved file rather than an inline read) and there is an explicit exclusion: 'No exporta otras cuentas' (does not export other accounts). However there is no explicit statement of when to prefer this over blackboard_get_my_attendance or any other attendance sibling.

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