Skip to main content
Glama
Sign In
GatorPath

GatorPath

by ashleytzele
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_prereq_chain

Read-onlyIdempotent

Retrieve the complete prerequisite chain for a course, including all required and alternative courses plus non-course conditions, to determine everything that must be completed before enrollment.

Instructions

Everything that must come before a course, all the way down.

`requires` is the course's own prereq tree ({"all": […]} / {"any": […]} of course, standing, gpa, permission, …
leaves). `chain` lists every course mentioned anywhere below it, alternatives included, prerequisites first and the
course itself last; read each entry's `requires` for which are and/or. `conditions` are the non-course leaves;
`verifiable: false` ones (permission, "or equivalent", …) can't be checked by GatorPath.

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": {
      "code": "<code>"
    },
    "name": "get_prereq_chain"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safe-read profile (readOnly, idempotent, closed-world), so the description sensibly spends its words on the shape of the result: the requires tree grammar, ordering of chain (prerequisites first, course last), and the important caveat that verifiable:false leaves cannot be checked by the system. Not covered: behavior for unknown codes or the size/shape of very deep chains.

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 a plain-language summary, then a compact field-by-field breakdown of the return value; every clause carries information. Slightly dense with domain shorthand ("and/or", "stands") that assumes familiarity, but no filler.

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 correctly spends most of its text explaining the return fields (requires, chain, conditions, verifiable), which is exactly what an agent needs to interpret the response. Only the input side and error/failure behavior are left thin.

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 coverage is 0% and the single parameter `code` is never described in the schema, so the description must carry it. It only indirectly implies the parameter is a course identifier via "a course" and "the course itself last"; there is no statement of format (e.g. "CS 101") or what happens to an invalid code.

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 first sentence names a specific resource and scope: the full transitive prerequisite closure of a course ("all the way down"), which distinguishes it from a single-course lookup. It never names a sibling tool, so the differentiation is implicit rather than stated.

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?

Usage is only implied by the semantics of prerequisites; the description never says when to reach for this versus get_course, get_program_requirements, or check_plan, and gives no exclusions or preconditions (e.g. whether the course must exist in the catalog).

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