SATCoach: AI SAT Tutor

Child's practice over a period

get_progress

Read-onlyIdempotent

Practice numbers for one period, counted as the parent portal counts them: this_week (the last 7 days, the portal's "This Week"), last_week (the 7 days before those), or last_4_weeks (the last 28 days). Returns the period's start and end, days active, questions done (every answered question counts, diagnostic ones too), accuracy, the previous period's numbers for comparison, and status: ahead, on_track, behind, or not_enough_data, measured against the child's daily goal (questions a day) over the same days. For when the parent asks how the child did this week, last week, or over the last month, or whether practice is going up or down. Not for predicting or estimating an SAT score: status measures practice against the daily goal only, and no SATCoach tool predicts a score. Not for seeing the questions the child answered either: question text and answers are never returned. Requires a connected SATCoach parent account.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "child": "c_Q3m9xT2bLk7vN0pRw4sY1A",
      "period": "this_week"
    },
    "name": "get_progress"
  }
}

Input Schema

Name	Required	Description	Default
`child`	No	The child's reference, from the list of the parent's children. Optional when the parent has one child on SATCoach.
`period`	No	Which period: this_week (the last 7 days), last_week (the 7 days before those), or last_4_weeks (the last 28 days).

Output Schema

Name	Required	Description	Default
`to`	Yes
`asOf`	Yes
`from`	Yes
`child`	Yes
`label`	Yes
`period`	Yes
`source`	Yes
`status`	Yes
`summary`	Yes
`accuracy`	Yes
`previous`	Yes
`dailyGoal`	Yes
`parentUrl`	Yes
`daysCounted`	Yes
`daysPracticed`	Yes
`questionsDone`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), yet the description still adds real behavior: it states the parent account must be connected, explains that every answered question counts including diagnostics, and defines what status is measured against (the daily goal over the same days). The main redundancy is that it re-enumerates return fields that the output schema already documents.

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 period semantics are front-loaded and the exclusion sentences are short and decisive. The paragraph is dense but a bit overlong, partly because the period definitions appear both here and in the schema.

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?

With an output schema present, the description does not need to explain return shapes, and it still covers auth prerequisites, counting methodology, status semantics, and privacy limits. Nothing an agent needs in order to call this correctly for a two-parameter read tool is missing.

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 100% and both parameters are already documented, so the baseline is 3. The description's period definitions duplicate the schema's enum description nearly verbatim, and it says nothing new about the optional `child` parameter or what happens when it is omitted.

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?

The description names a specific verb and resource (practice numbers for one period) and immediately defines the three period values with the portal's own definitions. It also draws sharp boundaries against adjacent-but-different questions (SAT score prediction, individual question text), so an agent can separate it from get_child_summary or get_diagnostic_report without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the triggering user intents explicitly ("how the child did this week, last week, or over the last month, or whether practice is going up or down") and names two explicit non-uses with reasons. The only minor gap is that it does not name a specific sibling tool as the alternative, but it rules out whole categories of misuse.

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

All SATCoach: AI SAT Tutor tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?