clickedu-mcp

get_session_detail

Retrieves detailed information for a single class session, including content, grading fields, and attendance link, using assignment and session IDs from the schedule.

Instructions

Detail for one class session (content, valoracio fields, attendance link). assig and sessio come from a session_link in get_schedule.

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": {
      "assig": "<assig>",
      "sessio": "<sessio>"
    },
    "name": "get_session_detail"
  }
}

Input Schema

Name	Required	Description	Default
`assig`	Yes
`sessio`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full burden. 'Detail' and the get_ prefix imply a read, and the parenthetical clarifies which data groups come back, but it says nothing about permissions, side effects, or whether the attendance link is a reference versus a state change.

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 short sentences, front-loaded with the resource and its payload, followed by the parameter-sourcing hint. Slightly compressed phrasing ('valoracio fields') costs a little clarity but nothing is wasted.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the description correctly avoids that. With zero parameter description coverage and no annotations, however, an agent still lacks format details for assig/sessio and any statement of read-only behaviour.

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% – the properties carry only bare titles 'Assig' and 'Sessio'. The description compensates by disclosing the provenance of both values (they come from a session_link in get_schedule), which is the key semantics for calling it correctly. It does not explain their format, but the sourcing instruction is the operationally useful part.

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?

States a specific verb and resource ('Detail for one class session') and enumerates the payload groups: content, valoracio fields, attendance link. This distinguishes it reasonably from note/behaviour siblings, though it never names them explicitly.

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?

Gives a concrete prerequisite path ('assig and sessio come from a session_link in get_schedule'), which tells the agent how to obtain valid inputs. However, it offers no guidance on when to prefer this over siblings like get_session_notes or get_class_behaviour, so the usage decision is only implied.

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