Skip to main content
Glama
Sign In
DTU Learn MCP

DTU Learn MCP

by frederikngh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read a course file

read_file
Read-onlyIdempotent

Downloads a DTU Learn file and extracts its text from PDF, PowerPoint, Word, notebooks, code, or text, using course, assignment, submission, feedback, or link identifiers; returns paged text.

Instructions

Downloads a file from DTU Learn to the user's computer and returns its text (PDF, PowerPoint incl. speaker notes, Word, notebooks, code, text). Give either topic_id (course content), assignment_id + file_id (assignment attachment), assignment_id + submission_file_id (a file the user handed in), assignment_id + feedback_file_id (a file in the user's feedback, e.g. their hand-in with the teacher's comments), or url (a DTU Learn link to a file, as shown in module pages, descriptions and instructions, e.g. https://learn.inside.dtu.dk/content/enforced/...). Long files are paged: use offset to continue. The saved path is returned so a coding agent can also open the original.

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": {
      "course": "<course>"
    },
    "name": "read_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNoA DTU Learn link to a file, e.g. from a module page in get_course_outline.
courseYesCourse: a DTU course number (e.g. "02450"), part of the course name, or the Brightspace org unit id from list_courses.
offsetNoCharacter offset to start from (default 0).
file_idNofileId of the attachment from get_assignment.
topic_idNotopicId of a file from get_course_outline.
max_charsNoMaximum characters to return (default 40000).
assignment_idNoassignmentId, for an assignment attachment.
feedback_file_idNofeedbackFileId of a feedback file from get_assignment.
submission_file_idNosubmissionFileId of a handed-in file from get_assignment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds material context beyond them: the call downloads a file to the user's computer and returns the saved path (an on-disk side effect not captured by readOnlyHint), extracts PowerPoint speaker notes, and pages long files via offset. That is exactly the extra behavioral detail the annotations cannot convey.

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-loads the core action and file-format coverage, then the input-mode enumeration, then paging behavior. Dense but every clause carries information; the parenthetical for feedback_file_id is slightly verbose but justified by the non-obvious semantics.

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?

With no output schema, the description still explains that text is returned, that long files are paged via offset, and that a saved path is returned for downstream use. For a 9-parameter, multi-modal file reader this is complete enough to call correctly.

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 coverage is 100%, so the baseline is 3, but the description adds the XOR-style combination logic between topic_id / assignment_id+file_id / submission_file_id / feedback_file_id / url that the schema does not express. Offset paging and max_chars defaults remain schema-only, which is fine.

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 ("Downloads a file from DTU Learn ... and returns its text") and enumerates the supported file formats, so the agent can distinguish it from get_course_outline/get_topic which only surface metadata. The scope is unambiguous at a glance.

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?

Explicitly enumerates the mutually exclusive input modes (topic_id, assignment_id+file_id, assignment_id+submission_file_id, assignment_id+feedback_file_id, or url) and names the sibling tool each id comes from, which is strong routing guidance. It stops short of saying when to prefer a sibling (e.g., get_topic) over downloading the file, so not a full 5.

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