Skip to main content
Glama

justify_absences

Preview and justify one student's absences and late arrivals for a date range, then confirm to save the changes.

Instructions

Justify ONE student's absences and lates in a date range, the way 'Detall d'assistència > Justificar en bloc' does in the student file. One student per call; never loops over a class.

Without confirm=True it lists what can be justified in the range and which items would be, and changes nothing. Each item has a key, date, time, subject and type: "absent" / "late" (unjustified), or with include_not_taken=True also "not_taken" (a session where the teacher did not take the register, shown by the page's eye icon). Call again with confirm=True only after the teacher approves.

keys picks items from that list; omit it to justify every absent/late item (and not_taken ones if include_not_taken). Justifying a not_taken session records the student as absent-with-justification there; only do it when the teacher says the student was not in class. note is the optional annotation (e.g. "Visita mèdica"). The 'email me a copy' box is never ticked. Dates are YYYY-MM-DD; date_to defaults to date_from. After saving it re-reads the range and reports each item's new state.

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": {
      "alu_id": "<alu_id>",
      "date_from": "<date_from>"
    },
    "name": "justify_absences"
  }
}

Input Schema

NameRequiredDescriptionDefault
keysNo
noteNo
alu_idYes
confirmNo
date_toNo
date_fromYes
include_not_takenNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so: the default call is a no-op preview, nothing changes until confirm=True, the 'email me a copy' box is never ticked, and the tool re-reads the range and reports each item's new state after saving. These are exactly the side-effect and safety details an agent needs for a mutation tool.

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?

Information is front-loaded: purpose and the one-student constraint come first, then the dry-run/confirm workflow, then per-parameter semantics. It runs long across four paragraphs and re-states the confirm pattern twice, but nearly every sentence carries operative detail rather than filler.

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?

For a complex mutation tool with an unusual two-phase preview/commit pattern, the description covers scope, safety defaults, item taxonomy (absent/late/not_taken), selection semantics, and post-save behavior. An output schema exists and the description still summarizes the reported result state, so 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 0%, so the description must compensate, and it largely does: keys (selection from the preview list, omit to justify all), note (optional annotation with example), date_from/date_to (YYYY-MM-DD, date_to defaults to date_from), include_not_taken, and confirm are all explained with meaning beyond the bare schema. Only alu_id is left unexplained in the text, a minor gap in an otherwise strong 7-parameter disclosure.

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 and resource ('justify ONE student's absences and lates in a date range') and anchors it to a concrete UI equivalent ('Detall d'assistència > Justificar en bloc'). The 'ONE student per call; never loops over a class' clause separates it cleanly from the class-level siblings like mark_attendance and get_class_behaviour.

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 when/when-not rules: call without confirm to preview, call with confirm only after teacher approval, and use include_not_taken only when the teacher says the student was not in class. It also rules out a misuse mode (looping over a class), so an agent knows the boundaries without checking siblings.

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