ScarletPlan is a Rutgers course planning assistant that combines live course catalog data, prerequisite checking, degree requirements tracking, schedule optimization, professor ratings, and section fill statistics to help students plan their academic career.
Course Search & Details (search_courses, get_course): Search the catalog by free text, subject, level, and term; get full course info including prerequisites, sections, core codes, and credits.
Prerequisite Analysis (get_prereq_tree, check_eligibility): View annotated prerequisite trees for any course and check which courses a student is eligible to take based on their completed transcript.
Section Information (get_sections): List all sections for a course in a given term, including meeting times, instructors, and open/closed status.
Professor Ratings (get_professor): Look up RateMyProfessors data (avg rating, difficulty, would-take-again %) with match confidence scores and courses taught.
Fill Rate Statistics (get_fill_stats): Historical fill-rate stats showing how quickly sections fill, how long they stay closed, and how often they reopen.
Degree Requirements Progress (get_requirements_progress): Track per-bucket progress toward the CS BS degree, including satisfied and remaining courses and credits.
Conflict-Free Schedule Optimization (solve_semester_schedule): Generate up to k conflict-free schedules using CP-SAT, with preferences for start/end times, days off, and campus.
Schedule Validation (validate_plan): Check a manually edited schedule for time conflicts.
Degree Plan Generation (solve_degree_plan): Create a multi-semester plan respecting prereq ordering, credit limits, and pinned course placements toward a target graduation term.
Student Profile Management (get_user_profile, set_user_profile): Persistently store and retrieve student data (completed courses, graduation target, preferences) across sessions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ScarletPlan Plan my remaining semesters for CS BS degree"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local-first Rutgers course planning assistant. Answers "what should I take and when?" using a CP-SAT solver, your real transcript, and live SOC data — running entirely on your machine, connected to Claude Desktop or Claude Code via MCP.
Disclaimer: ScarletPlan is not an official Rutgers tool. Always verify plans with Degree Navigator and your academic advisor.
Question | How |
What courses am I eligible for? | Prereq tree evaluation against your transcript |
Build me a conflict-free schedule | CP-SAT section optimizer with time/campus preferences |
Plan my remaining semesters | CP-SAT degree planner against CS BS requirements |
Will this section fill? | openSections fill-rate stats (grows over time) |
Who's a good professor for 344? | Cached RateMyProfessors ratings with name matching |
Related MCP server: polyu-estudent-mcp
Requirements: Python 3.11+, uv, Claude Desktop or Claude Code.
# 1. Clone and install
git clone https://github.com/heetshah15/scarletplan && cd scarletplan
uv sync
# 2. Build the database (ingest current + next term for NB)
uv run python scripts/setup.py
# 3. Start the MCP server (test it works)
uv run scarletplan-server
# 4. Add to Claude Desktop config (see below)
# 5. Start the openSections poller cron (see below)Add this to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"scarletplan": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/scarletplan", "scarletplan-server"],
"env": {
"SCARLETPLAN_DB": "/absolute/path/to/scarletplan/scarletplan.db"
}
}
}
}Or see docs/claude_desktop_config.snippet.json for a ready-to-copy snippet.
The server also speaks MCP over streamable HTTP for the planned web frontend — stateless with JSON responses, so multiple workers can run behind a load balancer:
uv run scarletplan-server --transport streamable-http --host 127.0.0.1 --port 8765
# endpoint: POST http://127.0.0.1:8765/mcpConfiguration (flags override env vars):
Env var | Flag | Default |
|
|
|
|
|
|
|
|
|
|
|
|
| — |
|
There is no auth on the HTTP transport: keep it bound to localhost and put the
website's authenticated backend in front of it. Every tool returns structured
JSON with error/caveats[] contracts (see docs/PRODUCTION_AUDIT.md), and a
health tool reports version, schema, and catalog freshness.
Paste this into your Claude project instructions (or .claude/instructions.md):
You are a Rutgers course planning assistant powered by ScarletPlan tools.
Rules:
- Always resolve course facts via tools, never from memory (SOC data changes).
- On first use: gather completed courses, target graduation, preferences via
set_user_profile so the student doesn't repeat themselves.
- Planning flow: get_requirements_progress → solve_degree_plan → present → iterate.
- Scheduling flow: solve_semester_schedule (k=3) → present tradeoffs →
validate_plan after any manual edits.
- Always surface caveats[] to the user, especially low-confidence ratings.
- End every degree plan with: "Verify this plan with Degree Navigator and your
academic advisor. ScarletPlan is not an official Rutgers tool."
- For professor ratings: always show match_confidence; flag anything below 85%.The fill-rate stats dataset only grows if the poller runs during registration windows. Add this cron job so data starts accumulating:
# Edit crontab: crontab -e
*/5 * * * * cd /path/to/scarletplan && \
uv run python -m scarletplan.poller.poll_open \
--year 2026 --term 9 >> poller.log 2>&1Key registration windows (when fill-rate data is most valuable):
November 2026 — spring 2027 registration
April 2027 — fall 2027 registration
January / September — add/drop chaos
RMP uses an unofficial GraphQL endpoint. Isolated and optional — if it breaks, all other tools continue working.
# Scrape once per semester, cache in DB
uv run python -m scarletplan.ingest.rmp.rmp_scraper --year 2026 --term 9
# Dry run to check match quality first
uv run python -m scarletplan.ingest.rmp.rmp_scraper --year 2026 --term 9 --dry-runMatch confidence ≥0.85 is reliable. 0.70–0.85 is surfaced as low-confidence. Below 0.70 is not stored.
Tool | What it does |
| Full-text search the catalog |
| Full detail: prereqs, sections, core codes |
| Prereq AST annotated with course titles |
| Which courses you can take given your transcript |
| Sections with meeting times, instructors, open status |
| RMP rating + match confidence + courses they teach |
| Historical fill rate for a section index |
| CS BS degree progress by bucket |
| Top-k conflict-free schedules with CP-SAT |
| Check a manually-edited schedule for conflicts |
| Multi-semester degree plan with prereq ordering |
| Persistent student profile |
uv run pytest # all tests
uv run pytest -m "not network" # skip live SOC tests
uv run python scripts/report_parse_failures.py # see unparsed prereq stringsTests use synthetic in-memory SQLite — no network, no real DB required.
Given candidate course_strings and the student's completed courses, return per course: eligible (bool), the unsatisfied prereq subtree, and any 'unknowns' (notes we could not verify automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| completed | Yes | ||
| course_strings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return values including 'unknowns' for unverifiable notes. However, it doesn't state side effects (none implied), required permissions, or behavior when inputs are invalid. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of ~20 words, front-loaded with key info. No fluff. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and outputs, but no output schema exists to define return structure. Missing details like whether output is a list or dict, or what the 'unsatisfied prereq subtree' looks like. Adequate for the tool's complexity but could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no additional meaning beyond parameter names. It mentions 'course_strings' and 'completed courses' but doesn't explain format (e.g., comma-separated? list of IDs?). Value is marginal beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'check eligibility'. Specifies inputs (course_strings, completed) and outputs (eligible, unsatisfied prereq subtree, unknowns). Distinguishes from sibling tools like get_prereq_tree which only returns prereq structure without checking eligibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage: when you need to check eligibility given completed courses. But no explicit mention of when not to use or alternatives like solve_degree_plan. Could benefit from stating it's for individual course checks rather than plan optimization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one course: prereq AST + raw text, sections summary, core codes, credits. Accepts 'CS 344', '198:344', or '01:198:344'. Always pass caveats through to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | ||
| course_string | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It reveals that the tool accepts multiple course string formats and instructs to pass caveats. However, it does not mention if the tool is read-only, requires authorization, or how it behaves on errors. The description adds some context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the purpose immediately and provides key input format details succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description covers the main purpose and input format but leaves out the term parameter's role and what the return value looks like. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the course_string parameter with three examples ('CS 344', '198:344', '01:198:344'). However, it does not explain the term parameter, which is optional and has a default of null. The description adds value for one but not both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full details for one course, including prereqs, sections, codes, and credits. It distinguishes from sibling tools like search_courses (which would search) and get_sections (which would get sections only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs comprehensive details for a single course. It says 'Full detail' and provides input format examples. However, it does not explicitly say when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical fill statistics for a section index, derived from the openSections poller. Returns hours_to_first_fill (how quickly the section filled after registration opened), pct_time_closed (fraction of the registration window the section was unavailable), and reopen_count (how many times a closed section reopened due to drops — high reopen_count means a closed section is still worth watching). Returns status='no_data' when the poller has not yet collected data for this term. Always surface caveats[] to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | ||
| year | No | ||
| index_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Explains data source (openSections poller), special return status ('no_data'), and meaning of reopen_count. Lacks details on idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately sized and informative, explaining key fields and caveats. Could be slightly more concise but is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description covers return fields adequately. Mentions caveats and no-data case. Could provide more detail on term/year format but sufficient for a tool with few parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description does not explain the parameters beyond implying index_number is required. No additional meaning or format guidance for term or year.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns historical fill statistics for a section index, listing specific fields (hours_to_first_fill, pct_time_closed, reopen_count). Distinct from sibling tools like get_sections which provide different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies use for fill stats but does not compare to other tools or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annotated prerequisite tree for a course (AST with course titles). Use to explain WHY a course is or isn't available.
| Name | Required | Description | Default |
|---|---|---|---|
| course_string | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output type (AST with course titles) and the use case, but it does not disclose authentication needs, error behavior (e.g., if course not found), or whether it is a read operation. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information about the tool's output and purpose. It is appropriately sized but could be slightly expanded to include parameter details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter (undocumented), no output schema, and no annotations, the description is insufficient. It explains the output's purpose but leaves out critical details about the input format and behavioral context, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, course_string, has 0% schema description coverage and the tool description does not mention it at all. It provides no format, example, or guidance on how to specify the course. With a single parameter, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an annotated prerequisite tree (AST with course titles) and its purpose: to explain why a course is or isn't available. The verb 'get' and resource 'prerequisite tree' are specific, and it distinguishes from siblings like check_eligibility which likely does a direct eligibility check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to explain WHY a course is or isn't available,' providing clear context for when to use it. It does not state when not to use or explicitly name alternatives, but the purpose is well-aligned with the tool's function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a professor by name. Returns their cached RateMyProfessors rating (avg_rating 1–5, avg_difficulty 1–5, would_take_again_pct) plus which courses they teach this term. Accepts any name format: 'Professor Smith', 'J. Smith', or SOC format 'SMITH, J'. Always surface match_confidence and caveats[] — low-confidence matches (<85%) should be flagged to the user. ratings_available=false means the scraper has not run yet for this term.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| term | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, fully describes caching behavior ('cached RateMyProfessors rating'), the `ratings_available` flag meaning, and confidence caveats. Does not mention auth or rate limits, but these are less critical for a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: first states core purpose, second clarifies name flexibility and output interpretation, third explains a key flag. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers all return fields (ratings, courses, match_confidence, caveats, ratings_available). Completely explains what the agent needs to know for invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so descriptions must compensate. Explains name accepts any format and provides examples. The `term` parameter is mentioned indirectly ('this term') but lacks format or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Look up', the resource 'professor by name', and the exact data returned (cached ratings and courses). It clearly differentiates from sibling tools like get_course or search_courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions on name formats ('Professor Smith', 'J. Smith', SOC format) and how to handle low-confidence matches. Lacks explicit when-not-to-use but sibling tools are clearly distinct in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-requirement-bucket progress for the CS BS major. completed: list of course strings the student has finished. Returns buckets with satisfied/remaining course lists and credit counts. Call this before solve_degree_plan to show what's left to complete.
| Name | Required | Description | Default |
|---|---|---|---|
| completed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior: it returns buckets with satisfied/remaining and credit counts. However, it does not explain what a 'bucket' is or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the tool's purpose, parameter, and usage recommendation with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description covers the essential points: what it does, what input it takes, what it returns, and how it fits into the workflow. Lacks examples but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'completed' parameter as 'list of course strings the student has finished,' adding meaning beyond the schema. However, it does not specify the exact format of course strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides per-requirement-bucket progress for the CS BS major, and distinguishes its role as a precursor to solve_degree_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this before solve_degree_plan to show what's left to complete,' providing clear usage context. Does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sections for a course in a term with meeting times, instructors, and open status. Times are minutes-from-midnight; Thursday is 'H'.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | ||
| course_string | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool lists sections and provides format details (times in minutes-from-midnight, Thursday 'H'), which is helpful. However, it does not disclose whether it is read-only, any rate limits, or if data is paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states purpose and contents, the second adds format clarification. No unnecessary words, though it could be slightly smoother.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should cover return structure. It mentions fields (meeting times, instructors, open status) but not the structure (e.g., list of objects). It is adequate for a basic understanding but incomplete for expecting exact output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'course' and 'term' but does not explain the format of course_string (e.g., 'CS101') or that term is optional and accepts integer or null. The description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sections for a course in a term, specifying meeting times, instructors, and open status. The verb 'list' and resource 'sections' are specific, and it distinguishes from siblings like get_course (which likely gets course info) or search_courses (which searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when section details are needed for a course, but it lacks explicit guidance on when to use this tool versus alternatives like get_fill_stats or get_prereq_tree. There is no statement of when not to use or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a stored user-profile value (e.g. 'completed_courses', 'target_grad', 'preferences'). Returns null if unset.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses the return behavior (null if unset) but omits other behavioral traits such as idempotency or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and add examples and return behavior without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description adequately covers purpose, parameter semantics, and return value, though it could mention error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by providing examples of valid key values, but does not specify exact allowed keys or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read a stored user-profile value') and provides concrete examples of valid keys, distinguishing it from the sibling tool set_user_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (reading profile values vs. writing), but does not explicitly state when not to use or list alternatives beyond the sibling set_user_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Rutgers course catalog by free text, subject code (e.g. '198' for CS), level (300 = 300-level), and term. Returns compact course rows. Use before get_course when the user names a topic not a code.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | ||
| level | No | ||
| limit | No | ||
| query | No | ||
| subject | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states returns 'compact course rows', implying read-only operation, but lacks details on pagination, rate limits, or side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. First sentence efficiently states core functionality with key parameter examples. Second sentence adds clear usage advice. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 5 params, no output schema, no annotations, the description covers the main purpose, key parameters, and usage context. Missing details on 'limit' and return structure, but for a search tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning for 'query' (free text), 'subject' (with example '198' for CS), 'level' (explains 300=300-level), and 'term' (mentioned). However, 'limit' parameter is not described, and no format for 'term' is given. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'Rutgers course catalog', listing search criteria (free text, subject, level, term). It also distinguishes from sibling 'get_course' by specifying when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before get_course when the user names a topic not a code', providing clear context for when to use this tool vs an alternative. No explicit when-not scenarios, but the guidance is direct and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a user-profile value so the student does not repeat themselves across turns. Value is any JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It only mentions storage for repetition avoidance but does not discuss side effects like overwriting, permissions, or data persistence beyond turns. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is appropriately sized and front-loaded with the core action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description is incomplete given the absence of annotations and output schema. It lacks information about parameter semantics, behavior on overwriting keys, and any return value. A user needs more context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the 'key' or 'value' parameters. It only mentions that 'Value is any JSON' but leaves the key undefined and provides no additional semantic meaning for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'store' and the resource 'user-profile value', and explains the purpose of avoiding repetition across turns. It distinguishes from the sibling tool 'get_user_profile' which retrieves values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to store a value so the student does not repeat themselves), but does not explicitly state when not to use it or mention alternatives among siblings. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan remaining semesters from now to target_term. completed: list of course strings the student has finished. target_term: {'year': 2028, 'term': 1} where term 1=spring, 9=fall. preferences: optional dict with max_credits_per_term (int, default 18), min_credits_per_term (int, default 12), current_year, current_term. pins: optional dict mapping course_string to {'year': Y, 'term': T} to force placement. Returns a semester-by-semester plan or a structured infeasibility explanation. Always call get_requirements_progress first to show the student their remaining requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| pins | No | ||
| completed | Yes | ||
| preferences | No | ||
| target_term | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return behavior (plan or infeasibility explanation) and parameter effects, but lacks disclosure on side effects, idempotency, authentication needs, or behavior for past target terms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four focused sentences: purpose, parameter explanations, output type, usage guideline. No fluff, front-loaded with intent, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters, return type, and prerequisite call. Missing details about the structure of the returned plan or infeasibility explanation (no output schema). Also lacks behavioral notes like rate limits or mutability, but overall sufficient given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet description fully explains all four parameters: completed (list of strings), target_term (dict with year/term mapping), preferences (optional with defaults), pins (optional mapping). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Plan remaining semesters from now to target_term', clearly indicating the verb (plan) and resource (degree plan). It distinguishes from sibling tools like solve_semester_schedule (single semester) and check_eligibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call get_requirements_progress first, providing a clear usage guideline. However, it does not explicitly state when not to use this tool or compare directly to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a list of course_strings and a term, return up to k (default 3) conflict-free section schedules using CP-SAT optimization. preferences may include earliest_start (minutes from midnight, e.g. 600=10am), latest_end, days_off (list of day strings like ['F']), campus_preference (e.g. 'BUSCH'). Returns schedules with section assignments, a human-readable summary, and penalty_score (lower=better). Always surface caveats[] to the user. Use get_sections first to confirm sections exist for the term.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| term | Yes | ||
| preferences | No | ||
| course_strings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the use of CP-SAT optimization, return of penalty_score, and that caveats are always surfaced. However, it does not detail failure modes, side effects, auth needs, or performance impacts, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, front-loaded with the main purpose, then detailing preferences and output, and ending with a usage note. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an optimization tool with 4 parameters (2 required) and no output schema, the description covers the primary use case and mentions get_sections as a prerequisite. However, it lacks details on error handling, preference interaction, and output format specifics, making it moderately complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds significant value by explaining k's default, that preferences may include earliest_start, latest_end, days_off, campus_preference, and that course_strings is a list. This compensates for the bare schema, though preferences structure remains loosely defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: given course strings and a term, return conflict-free schedules using CP-SAT optimization. It specifies output includes schedules, summary, penalty_score, and caveats, distinguishing it from sibling tools like solve_degree_plan by focusing on semester scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use get_sections first to confirm sections exist, providing a clear prerequisite. It implies the tool is for generating conflict-free schedules with preferences, but does not explicitly state when not to use or list alternatives beyond get_sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a proposed schedule (list of section index numbers) has any time conflicts. Use after the student manually edits a solve_semester_schedule result. Input: {sections: [index_number, ...], term: int}. Returns valid (bool), conflicts (list of overlapping pairs), and caveats (unknown indexes).
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lists output structure (valid, conflicts, caveats) and implies read-only behavior. Does not mention side effects, but acceptable for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage context, input/output description. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description adequately covers input format and all three return fields. Sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully compensates by specifying the exact structure of the 'plan' object: {sections: [index_number, ...], term: int}. Adds critical meaning beyond vague schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'check whether' and resource 'proposed schedule for time conflicts'. Distinguishes from sibling solve_semester_schedule by specifying it validates after manual editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after the student manually edits a solve_semester_schedule result'. Provides clear context but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_eligibilityget_courseget_fill_statsget_prereq_treeget_professorget_requirements_progressget_sectionsget_user_profilesearch_coursesset_user_profilesolve_degree_plansolve_semester_schedulevalidate_planScored across 13 tools
Each tool targets a distinct aspect of course planning—eligibility, details, fill stats, professors, requirements, schedules—with clear descriptions that prevent confusion. The only potential overlap between solve_degree_plan and solve_semester_schedule is well-differentiated by their long-term vs. short-term focus.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_course, solve_degree_plan). The verbs are appropriately chosen and uniform across the set, making it easy to predict functionality from the name.
With 13 tools, the number is well-scoped for a university course planning assistant. Each tool serves a clear purpose without redundancy, covering search, details, prerequisites, scheduling, and user profile management.
The tool set covers the full student planning workflow: searching courses, checking prerequisites and eligibility, managing schedules, validating plans, and storing preferences. No obvious gaps exist for typical planning tasks, though external actions like enrollment are excluded.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
AI-native Kanban board — connect Claude to claim, work and move your tasks over MCP.
