clickedu-mcp

mark_attendance

Set one student's attendance status for a single session, with a preview first and a confirmed write only after teacher approval; other students remain unchanged.

Instructions

Set ONE student's attendance for ONE session. Single action only.

Without confirm=True this returns a PREVIEW of the exact change and does not write anything. Call again with confirm=True only after the teacher approves. It replays every other student's current state unchanged and flips only this student, so no one else's attendance is touched.

status is "absent", "late" (retard), or "present" (clears any absence/late). reason_code is the motive code for absent/late (e.g. 10=MALALT, 11=METGE, 12=GESTIONS). justified marks an absent/late as justified.

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": {
      "cgap": "<cgap>",
      "sessio": "<sessio>",
      "alu_id": "<alu_id>"
    },
    "name": "mark_attendance"
  }
}

Input Schema

Name	Required	Default
`cgap`	Yes
`alu_id`	Yes
`sessio`	Yes
`status`	No	absent
`confirm`	No
`justified`	No
`reason_code`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does well: it discloses the non-writing preview path, the write path, and the replay semantics that only the target student is flipped while everyone else's state is preserved. It stops short of stating permission requirements or any downstream side effects such as notifications, which keeps it off a 5.

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?

Scope is front-loaded in the first line, then the confirm workflow, then parameter semantics. Every sentence carries information; there is no restatement of the tool name or filler.

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 7-parameter mutation with an output schema, the description supplies the workflow, safety gate, and the meaning of the non-obvious fields, so an agent can call it safely. It would be stronger if it hinted at what cgap/sessio/alu_id identify or where they come from, but that gap is minor against the rest.

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 does for the semantically tricky parameters: allowed status values and what "present" does (clears absence/late), reason_code meaning with example codes (10=MALALT, 11=METGE, 12=GESTIONS), and the effect of justified and confirm. The three identifier parameters (cgap, sessio, alu_id) are still left bare, so the balance is good but not complete.

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 plus an explicit scope constraint: "Set ONE student's attendance for ONE session. Single action only." That scope also separates it from batch-style siblings like get_monthly_attendance and justify_absences without needing to name them.

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 a precise two-step protocol: without confirm=True it returns a preview and writes nothing, and confirm=True should be called only after teacher approval. That states both when to call and when not to commit, leaving nothing to inference about the approval gate.

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