SATCoach: AI SAT Tutor

List the parent's children on SATCoach

list_children

Read-onlyIdempotent

Lists the parent's children that SATCoach shares with this connection: the children whose student account is linked to this parent account, as on the parent dashboard. For each child: child (the reference the other tools take), label (the child's first name, unless the parent renamed it in SATCoach), test, test date, target score, daily goal (questions a day), and whether the child has a tutor. Also returns contextWeNeed: up to 3 short questions about missing context. For when the parent asks which of their children are on SATCoach, or has more than one child and a child reference is needed. With one child, the other tools work without child. Not for finding a child who isn't listed: SATCoach doesn't share that child here, and asking for one returns not_found. 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": {},
    "name": "list_children"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`asOf`	Yes
`source`	Yes
`summary`	Yes
`children`	Yes
`parentUrl`	Yes
`contextWeNeed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds real context beyond them: it requires a connected SATCoach parent account, documents the not_found path for children not shared, and notes the secondary contextWeNeed return with up to three clarifying questions. Nothing about the call's preconditions or failure mode is left implicit.

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 scope are front-loaded, and every sentence carries routing or behavioral information. The middle return-field enumeration is dense and slightly redundant given an output schema exists, but it defines semantics (child as the reference other tools take, label unless renamed) rather than merely restating field names.

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?

For a zero-parameter, read-only roster tool with an output schema, the definition covers entry conditions, return semantics, the not_found case, and its role as the source of child references for sibling tools. An agent has everything needed to decide to call it and interpret the result.

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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline is 4. The description instead spends its space on return-field meaning, which is where ambiguity could otherwise arise.

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?

Starts with a specific verb and resource ('Lists the parent's children') and immediately scopes it to children SATCoach shares with this connection, tied to the parent dashboard. It is clearly distinguishable from siblings like get_child_summary or get_progress because it returns the roster of child references those tools consume.

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?

States explicitly when to call it (parent asks which children are on SATCoach, or a child reference is needed with multiple children), when it is unnecessary ('with one child, the other tools work without child'), and what it is not for (finding an unlisted child, which returns not_found). This is full when/when-not/alternative coverage.

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?