Skip to main content
Glama

build_plan

Read-onlyIdempotent

Generate a deterministic graduation plan from completed and remaining courses, sequencing prerequisites, grouping corequisites, and filling elective slots within term unit caps.

Instructions

Deterministic baseline plan to graduation, laid out on the Bulletin roadmap: each term starts from its roadmap semester (what's done is skipped, what isn't ready carries over), then the remaining required courses by prereq chain (critical path first, corequisites together), then slots for what's open (GE areas, senior electives, free electives) to reach the 120 and upper-division totals. Already run through check_plan: see check.

Fill each slot with list_eligible_electives + the student's goal, then call check_plan again before presenting.
Unit loads follow the roadmap (D24): each spring/fall term's cap is the printed units of the roadmap semester the
student's units have reached (16, 15, 16, … for a BS CS QR 1/2 freshman; the last semester's past its end; never
under 12 for f1), shown as each semester's max_units and roadmap. max_units_per_term is the student's own cap and
overrides it. Also include_summer, include_winter (Winter Session terms
between fall and spring: up to 4 units of GE, American Institutions or free electives) and f1 (F-1 visa: spring/fall
terms filled toward 12 units, pp.2390, 2393). Returns needs_input
(qr_pathway, start_term) instead of guessing. Each semester has `why`: per course, what it's needed before, the
chain it starts, and whether delaying it pushes back graduation. `pace` says what sets the length: the longest
prereq chain vs the units per term (load: roadmap / max_units_per_term); normal_load is the lighter option at the
normal 15 (terms, graduation term) when the roadmap goes above it; fold_last_term when a light last term fits into
one earlier term (a term sooner at one heavier load). profile.graduate_by (D25) fits the loads to that goal: when the
roadmap's loads end later, every term goes to the roadmap's heaviest semester, then one unit more at a time up to
19, until the plan ends by then (load: graduate_by, pace.fit with the units and a note; above the roadmap's
heaviest is an overload: advisor). pace says whether the term is reachable and, if not, why_not.
For "3, 4 or 5 years", call it at different max_units_per_term / include_summer / include_winter.

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

Input Schema

NameRequiredDescriptionDefault
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 read-only/idempotent annotations, the description discloses substantial behavior: deterministic roadmap sequencing, carry-over rules, prerequisite-critical-path ordering, unit caps, F-1 and graduate-by load fitting, and `needs_input` instead of guessing. It also explains output concepts like `why`, `pace`, `normal_load`, `fold_last_term`, and `why_not`, which materially helps an agent understand what the tool will do.

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

Conciseness2/5

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

The description is dense, run-on, and packed with unexplained references such as `D24`, `D25`, and `pp.2390, 2393`, making it hard to scan. Much of the content is relevant, but it is not structured into clear sections and the heavy parenthetical compression hurts readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex planning tool with no output schema and a rich nested profile input, the description covers the core algorithm, key optional controls, and some returned fields like `needs_input`, `why`, and `pace`. However, it remains incomplete on many profile fields and output details, and its cryptic phrasing leaves important behavior under-explained.

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% and the single `profile` parameter contains many nested fields, so the description must carry the burden. It explains key planning knobs such as `goal`, `max_units_per_term`, `include_summer`, `include_winter`, `f1`, `graduate_by`, `qr_pathway`, and `start_term`, but many profile fields like `completed`, `dpr_met`, `ge_done`, `approved`, and `chosen_electives` are left unexplained.

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 states a specific function: building a deterministic baseline graduation plan from the Bulletin roadmap, including term ordering, required courses, and elective slots. It distinguishes this from `check_plan` and `list_eligible_electives` by describing the follow-up workflow, though it does not clearly separate itself from `get_roadmap` or `audit_progress`.

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 explicitly says to fill slots with `list_eligible_electives` plus the student's goal, then call `check_plan` again before presenting. It also explains how to explore 3-, 4-, or 5-year variants via `max_units_per_term`, `include_summer`, and `include_winter`. There is no explicit when-not-to-use guidance, but the workflow is clear.

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