WaterExamMath

Check an answer

check_answer

Check the learner's answer to one practice problem and record it, or several problems at once with answers (up to 20 pairs of problem id and letter). Returns, per problem, whether it was correct, the correct option, the worked solution and the cited conversion sheet line. The problem id identifies its exam (grade). Side effects: creates the learner's account on first use, saves the attempt to the learner's progress for that grade (mastery per topic and the review schedule; missed problems come back later) and adds a usage record. Overwrites and deletes nothing. Limit: at most 40 answers per minute per account; over it, nothing is recorded and the call can be retried a moment later. Calling it again for the same problem records another attempt, so call it once per answer the user gives. Problems that are part of an open timed set can't be checked until that set is submitted.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_answer"
  }
}

Input Schema

Name	Required	Description
`answer`	No	The letter the user chose, e.g. "B" (single form)
`answers`	No	Several answers at once: [{ questionId, answer }, ...] in the order the user gave them (batch form)
`questionId`	No	The problem id from practice_questions (single form)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses real side effects: account creation on first use, progress/mastery/review-schedule writes, and a usage record, plus an explicit 'overwrites and deletes nothing' reassurance. It also explains non-idempotency concretely (a repeat call records another attempt) and states the 40-answers-per-minute limit and the fact that over-limit calls record nothing and can be retried.

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?

Front-loaded with the core action and return shape, then side effects, then limits and the timed-set exclusion; nearly every clause carries information. The return-value sentence is dense with four parallel items, which slightly hurts scannability.

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?

No output schema exists, and the description compensates by enumerating what comes back per problem (correctness, correct option, worked solution, cited conversion sheet line). Combined with the side-effect, rate-limit, and timed-set notes, an agent has everything needed to call it correctly.

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 the baseline is 3, but the description adds meaning the schema lacks: the problem id resolves to an exam/grade, and `answers` is a batch of problem-id/letter pairs in the user's order (capped at 20). That contextual framing genuinely helps an agent build correct calls.

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?

States a specific verb and resource: check a learner's answer to a practice problem and record the attempt, including a batch form via `answers`. The closing note about problems inside an open timed set cleanly separates this from the mock-exam siblings (save_mock_answers / submit_mock_exam).

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?

Gives clear calling guidance: use the single form or the batch form with up to 20 pairs, call once per answer the user gives, and do not use it for problems in an unsubmitted timed set. It names no alternative sibling by name, so it falls short of the explicit-alternatives bar for a 5.

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

All WaterExamMath 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?