NTNU Courses (unofficial)
Server Details
Unofficial NTNU course data: search, timetables, grades, course info, and exam logistics.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- MartinSA04/ntnu-mcp
- GitHub Stars
- 1
- Server Listing
- ntnu-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
12 toolscheck_timetable_conflictsInspect
Checks a set of NTNU courses for the same year for clashing lecture/lab times and colliding exam dates — a clash check to run before registering for courses. Accepts bare course codes.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| course_codes | Yes |
compare_coursesInspect
Side-by-side comparison of NTNU courses for a given year — campus, exam dates, weekly teaching hours, and latest grade distribution — to help choose between courses. Accepts bare course codes.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| course_codes | Yes |
get_course_infoInspect
Everything about an NTNU course except exam logistics: credits, level, campus, language of instruction, prerequisites, mandatory activities, course content / learning outcomes, credit reductions ('studiepoengreduksjon'), which study programs the teaching is planned for, contacts, and any alert notices (e.g. 'no longer taught'). English text by default; pass language 'nb' for Norwegian. Omit year for the current study year. For exam dates, times, aid codes, and rooms use get_exam_info.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| language | No | ||
| course_code | Yes |
get_course_scheduleInspect
Every dated teaching activity (lectures, labs) for a course in a year, with Oslo-local times and rooms. Long output for large courses — prefer get_weekly_timetable for a compact recurring-week overview.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| course_code | Yes |
get_course_versionsInspect
The DBH-versioned course codes (like 'TDT4100-1') that exist for a bare NTNU course code. Useful when grade lookups come back empty.
| Name | Required | Description | Default |
|---|---|---|---|
| course_code | Yes |
get_exam_infoInspect
Exam logistics for one or more NTNU courses in a single call: every exam occasion (ordinary / re-sit) with date, start time, duration, permitted-aids code ('hjelpemiddelkode') with its meaning, exam system, and assigned rooms. The way to answer 'when and where are my exams and what can I bring' for a whole semester at once. Rooms are only published days before the exam; unpublished fields are null. Omit year for the current study year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| language | No | ||
| course_codes | Yes |
get_grade_distributionInspect
Historical grade distribution for an NTNU course (per year and semester, with counts and percentages; grades A-F, or pass/fail codes). Accepts bare codes like 'TDT4100'. Omit years to get all recorded years. Small counts may be privacy-masked. Data comes from Norway's official DBH statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | ||
| course_code | Yes |
get_semestersInspect
NTNU's terms (semesters) with ids like '26h' (autumn 2026) / '26v' (spring), teaching weeks, exam-period dates, and which term is current.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
get_study_planAInspect
The official study plan for an NTNU program and cohort intake year: which courses (codes, credits, mandatory/elective) belong to each semester, and the specialization choice points with their course groups. The bridge from 'I study X' to concrete course codes — feed them to get_weekly_timetable, check_timetable_conflicts, or get_exam_info. cohort_year is the year the student STARTED (defaults to the current cohort); students in their Nth year started N-1 years ago.
| Name | Required | Description | Default |
|---|---|---|---|
| cohort_year | No | ||
| program_code | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details what the tool returns (courses, credits, mandatory/elective per semester, specialization points) and clarifies cohort_year semantics. It does not explicitly state read-only behavior but implies it by describing a query operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, purpose is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return structure (courses, codes, credits, mandatory/elective, semester, specialization points) and mentions sibling tools. Could note potential error cases, but not required for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description explains cohort_year meaning (year started) and mentions program_code in context, but does not define or constrain its format or value range. With two parameters and zero schema descriptions, more detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the official study plan for an NTNU program and cohort intake year, listing courses per semester and specialization points. It also distinguishes itself from siblings by positioning itself as the bridge to concrete course codes for other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use this tool to get course codes, then feed them to get_weekly_timetable, check_timetable_conflicts, or get_exam_info. Also explains cohort_year. However, no explicit when-not-to-use or alternatives for getting study plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_weekly_timetableInspect
The recurring weekly timetable grid for a course in a year: weekday, times, ISO-week ranges, and rooms. The compact way to answer 'when are the lectures for X'.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| course_code | Yes |
search_coursesInspect
Search NTNU's course catalog for a given year (server-side free-text search over course names and codes; Norwegian terms often match best, e.g. 'maskinlæring' rather than 'machine learning'). Call this first when you don't know the exact course code. Returns course codes, Norwegian names, campus, and exam dates.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| year | Yes | ||
| query | No |
search_study_programsAInspect
Search NTNU's study-program catalog (~400 programs) by free text (name, code, keywords), study level (e.g. 'bachelor', 'master', 'ph.d'), and/or city (Trondheim, Gjøvik, Ålesund). Returns program codes like 'MTDT' — the input for get_study_plan. Call this first when you only know a program's name.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| level | No | ||
| query | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear the burden. It mentions catalog size and input types but omits details like case sensitivity, partial matching, or empty result behavior. Core behavior is transparent but not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by usage guidance. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description covers the main aspects: what it searches, what it returns, and how it connects to another tool. Missing details like pagination or error handling are minor gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema) but description adds meaning: explains query is free text (name, code, keywords), level is study level with examples, and city lists specific cities. This compensates for the lack of schema documentation, though exact format for level is not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches NTNU's study-program catalog by free text, study level, and/or city, and mentions it returns program codes needed for get_study_plan. It distinguishes it from siblings like search_courses and get_study_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call this first when only a program name is known, and notes the output is input for get_study_plan. Does not explicitly list when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.