GPA Calculator MCP

Plan grades for upcoming courses

plan_courses

Read-only

Calculates the grade you need in each upcoming course to reach a target cumulative GPA from your current GPA and completed credits, showing the lowest letter per course that keeps the plan on track.

Instructions

Plan the grade needed in each upcoming course to reach a target cumulative GPA. Inputs: current_gpa (0 to 7), credits_completed (0 or more), target_gpa (0 to 7), courses (each with an optional name and credits greater than 0) and a scale id, which sets the top grade point the scale allows. It works out the GPA the upcoming credits need, then gives the lowest letter in each course that keeps the plan on track, assuming the other courses meet the same target. Says so when the target is already reached or would take more than one term. Example prompt: "I have a 3.4 GPA over 60 credits. What do I need in each of my four classes next semester to reach 3.5?"

Input Schema

Name	Required	Description	Default
`scale`	No	Grade scale id: "us4", "us4plus", "ontario-college", "uk-classification", "australia-hd" or "weighted-5.0". Defaults to "us4". Ask the student which one their school uses if unsure.	us4
`courses`	Yes	The upcoming courses to plan for. Each needs credits greater than 0, and name is optional.
`target_gpa`	Yes	The cumulative GPA you want to reach, between 0 and 7.
`current_gpa`	Yes	Your cumulative GPA so far, between 0 and 7.
`credits_completed`	Yes	Credits already completed, 0 or more.

Output Schema

Name	Required	Description
`scale`	Yes	The scale id the plan was made on.
`courses`	Yes	One entry per upcoming course, in the order they were passed.
`possible`	Yes	True when the target can be reached with these courses on this scale.
`max_points`	Yes	The top grade point the scale allows.
`needed_gpa`	Yes	The GPA needed on the upcoming credits. It is below 0 when the target is already reached, and above the top of the scale when the target takes more than one term.
`scale_name`	Yes	The name of the scale the plan was made on.
`target_gpa`	Yes	The cumulative GPA to reach.
`current_gpa`	Yes	The cumulative GPA so far.
`already_there`	Yes	True when the target is already reached, so a 0.0 on the upcoming credits keeps it.
`upcoming_credits`	Yes	The credits of the courses to plan for.
`credits_completed`	Yes	The credits already completed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Oct 24, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds substantive behavioral detail beyond that: it computes the GPA the upcoming credits must average, then returns the lowest acceptable letter grade per course, and explicitly discloses the key assumption that other courses meet the same target. Edge-case messaging (target already met, more than one term needed) is also disclosed.

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?

Purpose and core mechanics are front-loaded in the first sentence, followed by inputs, algorithm, and an example — a sensible order. It is dense but every paragraph carries information; only the input enumeration partly duplicates the schema.

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 5-parameter read-only computation with a full schema and an output schema, the description covers the essential contract: inputs, the ceteris paribus assumption behind per-course targets, and out-of-scope outcomes. Return-format details are rightly left to the output schema.

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?

Schema coverage is 100%, so baseline is 3, and the description adds real value by explaining that the scale id 'sets the top grade point the scale allows' — a semantic point the schema's enum list alone does not convey. The rest of the parameter restatement (ranges, credits > 0, optional name) is redundant with the schema.

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 sentence gives a specific verb and resource — planning the grade needed per upcoming course to reach a target cumulative GPA — which is clearly distinct from calculation-only siblings like calculate_gpa or convert_grade. It does not explicitly name the very similar-sounding target_gpa_planner sibling, so the agent must infer the difference from the description alone.

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?

The concrete example prompt ("I have a 3.4 GPA over 60 credits...") makes the intended usage scenario unambiguous, and the description notes what happens when the target is already reached or would need more than one term. It stops short of stating when to prefer this over target_gpa_planner or needed_on_final, so no explicit exclusion is offered.

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

Deploy Server