Skip to main content
Glama
Sign In
GatorPath

GatorPath

by ashleytzele
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ge_combinations

Read-onlyIdempotent

Find up to 8 course combinations that complete open GE, SF State Studies, and American Institutions requirements, fewest courses first, using recent courses and showing overlaps and options.

Instructions

Up to 8 ways (3 when more than 5 are open) to finish the open GE, SF State Studies and American Institutions requirements that one course can fill, fewest courses first, from courses that ran in the last year where that covers them (overlaps lists every course that counts for two or more); the first is the fewest a bounded search found, not a proven minimum: one course covering several (4UD + Environmental Sustainability + Global Perspectives), two that split them, or one each. Each part says what one course covers, how many courses cover exactly that (options), and examples (ready first, then recently offered); the parts can go in different terms. courses_that_fit: per open requirement, every course the student can take for it. Pass the build_plan output as plan so planned courses count; readiness is at each requirement's slot term in it (by_term: one term for all).

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": {
      "profile": "<profile>"
    },
    "name": "ge_combinations"
  }
}

Input Schema

NameRequiredDescriptionDefault
planNo
by_termNo
profileYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses a great deal: results are capped at 8 (3 when more than 5 requirements are open), only courses offered in the past year are considered, ordering is fewest courses first, and critically the first result is the best a bounded search found rather than a proven minimum. It also sketches the shape of each part (coverage, option count, examples ordered ready-then-recent) and the courses_that_fit fallback, all of which meaningfully shape interpretation of the output.

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 purpose is front-loaded, which is good, but the rest is one sprawling paragraph stitched together with semicolons, colons and nested parentheses, forcing the reader to re-parse clauses like 'one course covering several (4UD + Environmental Sustainability + Global Perspectives), two that split them, or one each'. The information largely earns its place, but the structure does not.

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 and only three parameters, the description does most of the necessary work by describing result caps, ordering, the per-part anatomy, and the courses_that_fit section. The unaddressed profile parameter and the unexplained reference to 'overlaps' are the main omissions for a tool of this complexity.

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 carries the burden. It explains plan (use build_plan output so planned courses count) and by_term (one term for all, otherwise readiness at each requirement's slot term) reasonably well. The required profile parameter, however, is never described — its contents must be inferred from the nested schema, which is a real gap at this coverage level.

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 clause names a specific action and object: enumerate up to 8 course combinations that satisfy open GE, SF State Studies and American Institutions requirements, fewest courses first. An agent can tell this apart from siblings like get_program_requirements or build_plan. The wording is dense and hyphenated with parentheticals, which slows comprehension, but the verb+resource+scope are all present.

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?

There is concrete guidance on chaining with build_plan ('Pass the build_plan output as plan so planned courses count') and on the by_term short-circuit ('one term for all'). What is missing is an explicit statement of when to prefer this over alternatives such as audit_progress, check_plan, or get_roadmap, or when not to call it at all.

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