Skip to main content
Glama
Sign In
UofT Timetable Builder MCP

UofT Timetable Builder MCP

by SleepyPandas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

course_info

Read-onlyIdempotent

Retrieve readable course cards with descriptions, prerequisites, sections, instructors, meeting times, enrolment, and waitlist details for UofT timetable planning.

Instructions

Get readable course cards: description, prerequisites, sections, and meetings.

course_codes are full codes such as CSC148H1 (1 to 8). section_code optionally keeps only F (Fall), S (Winter), or Y (full year) offerings. Returns one card per offering with credits, breadth, plain-text requirements, and sections grouped by type with instructors, meeting times, enrolment, and waitlist. Sections flagged full or cancelled say so; lists are capped per type. The id is the Timetable Builder course id used by generate_timetable. Unknown codes appear under errors.

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_codes": "<course_codes>"
    },
    "name": "course_info"
  }
}

Input Schema

NameRequiredDescriptionDefault
course_codesYes
section_codeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the read-only, idempotent, and non-destructive annotations, it discloses one card per offering, section grouping, full or cancelled status flags, capped lists, and unknown-code errors. It does not quantify the caps or clarify whether valid cards are still returned alongside errors in a mixed request.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, followed logically by parameters, returned content, edge cases, and integration. It is dense but efficient, with essentially every clause adding actionable information.

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 two-parameter read tool without an output schema, the description provides unusually good coverage of inputs, result structure, truncation, and errors. Its main remaining gaps are sibling selection guidance, the apparently stale generate_timetable reference, and unspecified list-cap sizes.

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

Parameters5/5

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

Despite 0% schema description coverage, the description explains both parameters well: course_codes requires full codes, gives CSC148H1 as an example, and states the 1–8 range, while section_code is identified as optional and every filter value is expanded. This supplies the operational meaning missing from the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb and resource, “Get readable course cards,” and specifies description, prerequisites, sections, and meetings as the retrieved content. This suggests detailed lookup of known courses rather than course discovery, but it does not explicitly distinguish the tool from find_courses.

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?

Full-code inputs, optional offering filtering, and downstream use of the returned id provide useful workflow context. However, there is no explicit routing guidance such as using find_courses to discover codes, and the reference to generate_timetable does not match any listed sibling, weakening the only explicit integration guidance.

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