Skip to main content
Glama
Sign In
GatorPath

GatorPath

by ashleytzele
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

audit_progress

Read-onlyIdempotent

Check degree progress against program requirements: see satisfied, in-progress, remaining, or waived groups, counted courses, and university totals without saving data.

Instructions

Degree audit: per requirement group satisfied / in_progress / remaining / waived (or unparsed: a rule GatorPath can't check, with the Bulletin's quote) and which courses counted, plus university totals (120 units, upper-division, residence, CR cap, GPAs). Nothing is stored.

profile: program (e.g. 'bs-cs'); catalog_year (the DPR's "Requirement (Catalog) Term", e.g. 'Fall 2025': that
year's rules when GatorPath has them, else the newest with a warning); completed: [{code, grade, term?, units? (variable-unit
courses), transfer? (articulated transfer course), credit? ('extension' | 'exam' | 'evaluation': counts for
units, never residence)}], grades as SF State symbols (A..F, CR, NC, W, I);
in_progress: [codes]; ge_done: GE areas met by transfer/AP/IB credit, as the DPR writes them (e.g. "1A", or an
older catalog's "A2", "D", "UD-D": translated automatically), also USH/USG/CSLG; dpr_met: required courses the
DPR shows met by a substitution or exception (e.g. MATH 225 met by MATH 325); not_on_dpr: requirements the
tools list but the student's DPR doesn't have at all (an older catalog, e.g. GE "6" Ethnic Studies): left out and
flagged for an advisor to confirm; first_time (began at SF State as a first-time college student; leave it out
unless the student says: without it, transfer work decides); ge_certified (Cal-GETC certification of lower-division GE, p.2304); prior_bachelors (already holds
a bachelor's or higher degree from a regionally accredited institution: GE and graduation requirements waived,
p.2313); transfer_units: total transfer units; adt: true only for a verified AA-T/AS-T from a California Community
College in a similar approved major (waives SF State Studies, p.2313); approved: {group id: [codes]}, the courses
the student's advisor approved for a group with `approval` (BS Applied Mathematics application electives: no
Bulletin list), from the DPR or the student; gpa optional. A group with `options` is a "Select One": `remaining`
is one option, and the student may take another.

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": "audit_progress"
  }
}

Input Schema

NameRequiredDescriptionDefault
profileYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and closed-world, and the description adds real behavioral context beyond them: 'Nothing is stored', warnings when the catalog year falls back to the newest rules, and flagging of unparsed rules plus not_on_dpr items for advisor confirmation. It stops short of describing failure modes or the shape of the totals block in detail.

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?

It is front-loaded with the return shape and wastes little, but the body is one dense, parenthetical-packed run-on with Bulletin page references (p.2304, p.2313) that assume context. Given 0% schema coverage most content earns its place, yet a bulleted field list would be far easier to parse.

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 complex audit tool with no output schema and zero schema descriptions, the definition explains the return structure, key policy edge cases, and the trickiest input fields well enough to invoke correctly. The omission of roughly a dozen profile properties (plan, goal, qr_pathway, term-boundary flags, unit caps) is the main remaining incompleteness.

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

Parameters4/5

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

With 0% schema description coverage on a deeply nested profile object, the description carries the full burden and does so for the semantically hard fields: completed entry shape (grade symbols, units, transfer, credit types), catalog_year resolution, ge_done notation translation, dpr_met, adt/prior_bachelors/ge_certified rules, and 'Select One' group semantics. Several schema properties remain unexplained (goal, plan, qr_pathway, start_term, graduate_by, include_summer/winter, max_units_per_term, overload_approved, permissions, chosen_electives, dpr_imported, f1), so it does not fully close the gap.

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?

Opens with a precise verb+resource framing ('Degree audit') and enumerates what is returned: per-group satisfied / in_progress / remaining / waived, unparsed rules with the Bulletin quote, courses counted, and university totals. An agent can tell this is a requirements-satisfaction computation, distinct from check_plan or build_plan, without opening the schema.

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?

The usage context is implied (this is what you call to get a live degree audit) but there is no explicit when/when-not guidance or routing to siblings such as check_plan or get_program_requirements. The only conditional guidance is field-level ('leave it out unless the student says'), not tool-selection 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