GPA Calculator MCP

Weighted grade

weighted_grade

Read-only

Calculate your current course grade from weighted parts and see the best and worst possible final grades. Set a target to find the average needed on unmarked parts.

Instructions

Combine weighted course parts into the grade so far, plus the worst and best possible finish. Inputs: parts (each with a name, a weight that is a percentage of the whole course greater than 0, and an optional score between 0 and 100; leave the score out for parts that are not marked yet). Optional target_percent sets a course grade to work out the average needed on the unmarked parts. A weight is a percentage of the whole course, so the parts are never rescaled. Parts that add up to less than 100 leave the rest of the course still to come, and weights that add up to more than 100 are an error. Example prompt: "My course is 20% quizzes, 30% labs, 50% exam. I have 85 on quizzes and 70 on labs. What's my grade so far and what's the best I can finish with?"

Input Schema

Name	Required	Description	Default
`parts`	Yes	The weighted parts of the course. Each needs a name and a weight (a percentage of the whole course greater than 0); score is 0 to 100, or leave it out for parts that are not marked yet. Weights are percentages of the whole course, so parts that add up to less than 100 leave the rest of the course still to come.
`target_percent`	No	Optional target course grade in percent. When given, works out the average needed on the unmarked parts.

Output Schema

Name	Required	Description
`parts`	Yes	One entry per part, in the order they were passed.
`possible`	No	When a target_percent is given, true when the target can be reached.
`best_finish`	Yes	The course grade if every remaining part scores 100.
`done_weight`	Yes	The weight of the marked parts, as a percentage of the whole course.
`total_weight`	Yes	The weights of the parts added together, as a percentage of the whole course.
`worst_finish`	Yes	The course grade if every remaining part scores 0.
`already_there`	No	When a target_percent is given, true when the target is already reached.
`current_grade`	Yes	The average on the marked work, or null when nothing is marked yet.
`earned_points`	Yes	The points already banked out of the 100 the whole course is worth.
`needed_percent`	No	When a target_percent is given, the average needed on the unmarked parts. Below 0 when already there, above 100 when out of reach.
`remaining_weight`	Yes	The weight of the course that is still to come, as a percentage of the whole course.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.7Oct 30, 2026

addedInput schema / properties / target_percent

Added value: +{
+  "description": "Optional target course grade in percent. When given, works out the average needed on the unmarked parts.",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

addedOutput schema / properties / already_there

Added value: +{
+  "description": "When a target_percent is given, true when the target is already reached.",
+  "type": "boolean"
+}

addedOutput schema / properties / needed_percent

Added value: +{
+  "description": "When a target_percent is given, the average needed on the unmarked parts. Below 0 when already there, above 100 when out of reach.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / possible

Added value: +{
+  "description": "When a target_percent is given, true when the target can be reached.",
+  "type": "boolean"
+}

First observedv0.1.4Oct 24, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavior: weights are never rescaled, sums below 100 mean the course is incomplete, and sums above 100 are an error. These are meaningful operational details that help an agent invoke the tool correctly, with no contradiction of the annotations.

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?

The description is front-loaded with the core purpose and remains readable, with the example prompt adding practical value. It is somewhat repetitive about weights being percentages of the whole course, which keeps it from being maximally concise.

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

Completeness5/5

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

The description covers the essential inputs, weight-sum constraints, optional target behavior, and an example, while an output schema exists to explain return values. Given the moderate complexity and fully described schema, the definition is complete enough for correct invocation.

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 description coverage is 100%, so the schema already documents both parameters well. The description still adds useful meaning by clarifying that weights are percentages of the whole course and are never rescaled, and by explaining the purpose of target_percent.

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 verb and resource: combining weighted course parts into the grade so far, plus worst and best possible finish. It clearly identifies the outputs, but it does not explicitly distinguish this tool from siblings such as needed_on_final or calculate_gpa.

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 description gives clear usage context, including when to provide target_percent to compute the average needed on unmarked parts, and includes an example prompt. However, it does not explicitly say when to use this tool instead of similar siblings.

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

Deploy Server