Skip to main content
Glama

get_sections

Read-onlyIdempotent

Search course sections for a term and return class numbers, meeting times, instructors, seat counts, and clash-free schedule options for planning.

Instructions

Class Search sections of courses in one term (e.g. '2027-spring'), to show after a plan for its first term once that term's schedule is out: class number (class_nbr, what Student Center asks for), meetings (days, time, where), mode, instructor, seats_open, waitlist_open, enrolled, and attributes (permission numbers, GE tags; Class Search shows no capacity). rate_my_professors: {instructor: a Rate My Professors search} per named instructor, links for the student to open (anonymous student opinion, not SF State's). not_offered: no section that term (move it in the plan, then check_plan). unknown: GatorPath has no schedule for that subject and term (not out yet, or a subject it didn't scrape): check Class Search. A snapshot from scraped_at: seats, rooms and instructors change, so the student confirms in Class Search before registering.

Time clashes are checked here, not by you: `schedule` {code: [class_nbr, …]} is one set of sections with no time
clashes, the fewest full sections first (a lecture with its lab or activity is one pick), and each section says
in_schedule, or clashes_with: the scheduled sections of other courses it overlaps ([]: it fits instead). `sets`:
how many clash-free sets there are. When none fits, schedule is null and always_clash names the course pairs that
never fit together: one moves to another term (then check_plan).

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": {
      "term": "<term>",
      "codes": "<codes>"
    },
    "name": "get_sections"
  }
}

Input Schema

NameRequiredDescriptionDefault
termYes
codesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description does add genuine behavioral context beyond them: results are a stale snapshot from scraped_at that the student must re-confirm in Class Search, and the response includes Rate My Professors links that are anonymous third-party opinion rather than SF State data. That is useful, but it is framed mostly as return-content description rather than operational behavior of the call itself.

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

Conciseness3/5

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

The content is front-loaded with the purpose, but the body is a dense, run-on block mixing return-field enumeration, status semantics, and clash-resolution algorithm into prose with no headings or line breaks. Nearly every sentence carries information, yet the volume for a two-parameter lookup makes it hard to scan, and much of it is really output semantics that would be better structured.

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?

With no output schema, the description takes on the burden of explaining returns and does so thoroughly: field list, `not_offered`/`unknown` statuses, the `schedule`/`sets`/`always_clash` clash-resolution structures, and snapshot staleness are all covered. What is missing is input-side completeness — what `codes` actually are — which leaves one required parameter unaddressed.

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

Parameters2/5

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

Schema coverage is 0%, so the description must carry both parameters. It supplies an example for `term` ('2027-spring'), which is helpful, but `codes` — a required array — is never defined: no format, no cardinality, no statement that these are course codes rather than section numbers. The larger half of the required input is left entirely to inference, which is a serious gap at 0% coverage.

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 opening sentence names a specific verb and resource ("Class Search sections of courses in one term") and enumerates the returned fields (class_nbr, meetings, seats_open, attributes), which no sibling tool provides. It implicitly distinguishes itself from get_course and check_plan by routing certain outcomes to them, but the phrasing is turgid enough that the core purpose takes work to extract.

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?

It gives explicit routing for two outcome branches: `not_offered` means move the course in the plan and then call check_plan, while `unknown` means check Class Search directly because GatorPath lacks the schedule. That is real when-to-use/when-to-redirect guidance, though it never states the plain precondition for calling this tool (you have a plan term and want section detail) nor when get_course would be the better first call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.