Skip to main content
Glama
yatuk

itu-mcp

by yatuk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Public Course Schedule

get_public_course_schedule
Read-onlyIdempotent

Fetch a public ITU OBS course schedule by department and program type without login. Filter by course name, code, or CRN and page results to view sections, instructors, times, rooms, and capacity.

Instructions

Read the public OBS course schedule for a department. No login required — reads the open DersProgram page. Use query for a course name/code fragment, including full sections. Filtered/paged calls return at most 50 sections by default (limit up to 100). Follow next_offset with the same filters to read more. Returns structured course list with CRN, instructor, sessions (day/time/room), capacity, enrolled count, and prerequisite links.

Input Schema

NameRequiredDescriptionDefault
crnNo
limitNo
queryNo
offsetNo
program_typeYes
department_codeYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.2.1
    • addedInput schema / properties / limit
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Limit"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
    • addedInput schema / properties / query
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Query"
+}
    • removedOutput schema / additionalProperties
      Removed value: -true
    • addedOutput schema / properties
      Added value: +{
+  "result": {
+    "additionalProperties": true,
+    "title": "Result",
+    "type": "object"
+  }
+}
    • addedOutput schema / required
      Added value: +[
+  "result"
+]
    • changedOutput schema / title
      Previous value: -"get_public_course_scheduleDictOutput"New value: +"get_public_course_scheduleOutput"
  2. Addedv0.2.3

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description usefully adds auth requirements (no login), pagination defaults (50, max 100), and the next_offset continuation pattern — real behavioral context beyond the annotations.

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, then pagination and return details in logical order. Every sentence adds value, though the return-field enumeration is somewhat lengthy given an output schema already exists.

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?

A read-only paginated tool with strong annotation coverage and an output schema. The description covers auth, paging, and filtering adequately; the remaining gap is the unexplained required parameters program_type and department_code.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the load. It clarifies query, limit, and offset semantics well, but the required program_type and department_code parameters (and crn) are left unexplained beyond their titles, so compensation is only partial.

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 (Read) plus resource (public OBS course schedule) and scope (for a department). The 'No login required / public DersProgram page' framing sharply distinguishes it from authenticated siblings like obs_get_schedule and get_course_sections.

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 one concrete usage hint ('Use query for a course name/code fragment') and the no-login context, which implies public/unauthenticated use. However, it never explicitly names alternatives or states when-not to use it versus the many sibling schedule/course tools, leaving routing to inference.

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