clickedu-mcp

get_evaluation

Read a subject's term evaluation page to inspect sections, activity weights, and entered grades per student and activity without saving changes.

Instructions

Read the 'Avaluar' page of one subject for one term: its sections and activities with their weights (%), and every grade already entered, per student and activity. Read-only; it never saves anything.

subject_id is the assignatura id (the number in the 'EvaluateTermly&id=' link that get_subjects_and_rosters returns, e.g. 3376). term_id picks the term (ids are listed in the answer as term_ids); omit it for the current one. Grades come from Clickedu as entered; a final grade that Clickedu computes in the page is not stored until the teacher saves, so it may be missing here.

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": {
      "subject_id": "<subject_id>"
    },
    "name": "get_evaluation"
  }
}

Input Schema

Name	Required	Description	Default
`term_id`	No
`subject_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.7/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it declares read-only behavior ('never saves anything') and discloses a non-obvious data caveat that Clickedu-computed final grades are not stored until the teacher saves, so they may be missing. That provenance detail is exactly the kind of behavior an agent could not infer elsewhere.

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?

Front-loads the purpose in the first sentence, then a parameter paragraph, then a caveat paragraph, with no filler. Every sentence adds actionable information.

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?

Given an output schema exists, the description need not spell out return values, yet it still summarizes contents (sections, activities, weights, grades) and adds the critical final-grade caveat. For a two-parameter read tool, nothing an agent needs to call it correctly is missing.

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 description coverage is 0%, so the description must compensate, and it does: subject_id is explained as the assignatura id with a concrete example (3376) and the exact link it appears in, and term_id is explained as optional with ids listed in the answer and empty meaning current term. It fully covers both parameters, though the 'term_ids listed in the answer' phrasing assumes output structure the agent must confirm.

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 ('Read the Avaluar page of one subject for one term') and enumerates what it returns: sections, activities with weights, and entered grades per student and activity. This clearly distinguishes it from roster tools like get_subjects_and_rosters, which it explicitly references as the id source.

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?

Gives a clear usage context: use it to read evaluation data, with subject_id sourced from the 'EvaluateTermly&id=' link returned by get_subjects_and_rosters, and term_id omitted for the current term. It lacks an explicit when-not-to-use clause (e.g., versus other grade or roster tools), which keeps it short of a 5.

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