Skip to main content
Glama
Sign In
edhec-mcp

edhec-mcp

by Sillvs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Check my absences

aurion_absence_check
Read-onlyIdempotent

Lists recorded absences with assessment scheduling, 48-hour proof deadlines, proof status, and next steps, plus EDHEC attendance rules to check against your programme rules.

Instructions

Read-only. Lists your recorded absences and, for each one, whether an assessment was scheduled (Aurion timetable, Blackboard due dates), the 48-hour proof deadline, whether a proof is already on file, and what to do. Includes EDHEC attendance rules with their source. Rules can differ by programme: tell the user to check their own Programme Rules.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aurion_absence_check"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and open-world, so the 'Read-only.' prefix adds little. The description does add real behavioral context beyond them: the data is merged from Aurion timetable and Blackboard due dates, there is a 48-hour proof deadline, proof-on-file status is included, and rules carry their source and may vary by programme.

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 safety trait is front-loaded, then the returned content, then the caveat. It is a single dense sentence with a list of fields and one follow-up caveat; the field enumeration earns its place because no output schema exists, though the list is slightly packed.

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?

With no output schema, the description carries the burden of describing return content and does so field by field, plus the cross-system data sources and the programme-rules caveat. It could be stronger by naming the intended next step or confirming empty-result behavior, but an agent has enough to call and interpret it.

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?

There are zero parameters and full schema coverage, so the baseline of 4 applies. The description correctly adds no parameter discussion, leaving nothing misleading about inputs.

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 ('Lists your recorded absences') and enumerates the per-absence facts returned (assessment scheduled or not, 48-hour proof deadline, proof on file). The read-only list framing distinguishes it cleanly from the sibling aurion_absence_prepare and aurion_absence_submit, which are the write paths.

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?

Usage is implied by 'what to do' and the instruction to tell the user to check their own Programme Rules, but it never says explicitly when to call this versus aurion_absence_prepare/submit or aurion_timetable. An agent must infer that this is the diagnostic read step before preparing a submission.

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

Deploy Server

Other Tools