Skip to main content
Glama
Sign In
DTU Learn MCP

DTU Learn MCP

by frederikngh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

What's coming up

get_upcoming
Read-onlyIdempotent

List deadlines and dated course items across all courses or one course for the next N days, so you can see what needs doing this week.

Instructions

Lists deadlines and dated items in the next N days across all courses (or one course): assignment due dates, quizzes, content with dates, and calendar events, which at DTU include timetable lectures and group work with rooms. Good for 'what do I need to do this week?'.

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": "get_upcoming"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoHow many days ahead to look (default 7, max 120).
courseNoCourse: a DTU course number (e.g. "02450"), part of the course name, or the Brightspace org unit id from list_courses. Omit for all courses.
include_completedNoAlso include items already completed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuine value beyond them by disclosing the content scope it aggregates (assignment due dates, quizzes, dated content, calendar events, DTU timetable lectures and group work with rooms) — an agent knows what "dated items" concretely means. It stops short of stating ordering, pagination, or the window default (default 7 / max 120), which are only in the schema.

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?

Front-loaded with the core action and scope, followed by the item enumeration and a use-case tag. The single long second sentence packs a lot of enumerations; it earns most of its length but is denser than ideal rather than tight.

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 3-optional-parameter read tool with full schema coverage and no output schema, the description covers purpose, scope, and item types adequately. What an agent still can't tell is the shape of a returned item (fields, ordering by date, how completed items are marked when include_completed is set), which would matter since there is no output schema.

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?

With 100% schema description coverage the baseline is 3, and the description does add a little on top: "next N days" and "across all courses (or one course)" communicate the semantics of the days and course parameters at a glance. It does not add anything about include_completed or the accepted course identifier formats, leaving those entirely to the schema.

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 states a specific verb and resource ("Lists deadlines and dated items") plus an explicit time-window scope ("next N days across all courses (or one course)"). It enumerates the distinct item types returned — assignment due dates, quizzes, dated content, calendar events, DTU timetable lectures, group work — which clearly separates it from siblings like list_assignments or get_announcements that cover only one item type.

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?

"Good for 'what do I need to do this week?'" gives a concrete usage scenario, which is better than most definitions. However, it never names an alternative or an exclusion — it doesn't say when to prefer list_assignments or get_announcements, nor that it excludes announcements/undated content. The usage context is clear but the routing guidance is implicit.

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