clickedu-mcp

get_monthly_attendance

Fetch a class group’s monthly and cumulative attendance report for selected months, covering every student, session counts, justified and unjustified absences and lates, and percentages.

Instructions

'Resum mensual acumulat' for one class group: every student on the list (also those with no incidents), per month and in total, with A (unjustified absences), AJ (justified absences), R (unjustified lates), RJ (justified lates) and number of sessions, plus percentages. R and RJ are separate.

class_id comes from get_subjects_and_rosters. months is a list of two-digit month numbers ("09", "10", ...); omit it to get Clickedu's default selection. To get the whole school year so far, pass every month from "09" to the current one. Read-only.

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": {
      "class_id": "<class_id>"
    },
    "name": "get_monthly_attendance"
  }
}

Input Schema

Name	Required	Description	Default
`months`	No
`class_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A4.5/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 it does declare 'Read-only' explicitly plus the notable behavioral trait that students with zero incidents are still included, and that output carries percentages alongside raw counts. It does not mention authentication/permission expectations or any rate or size limits for large month ranges, leaving those gaps.

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?

The purpose and output shape are front-loaded in the first sentence, followed by a short operational note and a one-word safety signal. It is slightly dense with parenthetical detail, but each clause (separate R/RJ, the year-to-date recipe) removes a concrete failure mode rather than padding.

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?

An output schema exists, so the description needn't describe return values, and it still previews the key columns. With two simple flat parameters, one required, a read-only profile and a stated dependency for class_id, an agent has everything needed to invoke this correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate entirely, and it does: months is defined as a list of two-digit month strings with literal examples ("09", "10"), the omit-case default is explained, and class_id's provenance is named. This is more than the schema provides, not a restatement of it.

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?

The description opens with a specific named report ('Resum mensual acumulat') over a specific resource (one class group) and enumerates the exact output contents: A, AJ, R, RJ, session counts and percentages, including students with no incidents. The clause 'R and RJ are separate' pre-empts a real ambiguity, and the aggregate-per-month scope clearly separates it from raw siblings like get_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 Guidelines4/5

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

It gives concrete operational guidance: class_id must come from get_subjects_and_rosters, months may be omitted for Clickedu's default, and to cover the school year so far you pass every month from "09" to the current one. What it lacks is an explicit statement of when to prefer this over get_attendance or get_class_behaviour, so the routing is inferred from scope rather than stated.

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