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

Beyond the readOnly/openWorld annotations, it discloses two significant limits: the server does not grade free text and never runs code, which prevents an agent from treating an exercise attempt as something that will be evaluated. It also discloses the output shape per mode (verdict, correct option, reason; hint and reference answer) in a tool that has no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded by kind, with no filler. The long parenthetical bundling the free-text and code caveats plus the hint-ordering rule is dense but every clause carries information; a lightly broken-out structure would read faster.

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

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

With no output schema, the description carries the return-value burden and does so for both modes, and it flags the two assumptions an agent would most likely get wrong (grading of free text, code execution). For a five-parameter read tool with three enums, nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the enums and the answer field are already documented, including that answer is optional for an exercise. The description reinforces the kind-dependent meaning of the answer and the no-grading rule, but adds no syntax or format detail the schema lacks. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific act (telling whether an answer is right, which option is correct, and why) and scopes it to a numbered item of a lesson, then splits the behavior by kind: judgment-plus-reason for a quiz question versus hint-plus-reference-answer for an exercise. An agent can tell exactly which of the two results it will receive without opening the schema.

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

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

It gives an explicit sequencing rule for exercises: offer the hint first, and the reference answer only after the learner has made an attempt. That is real when-to-use guidance rather than a restatement. It stops short of naming an alternative (e.g. explain_concept) for the case where the learner needs a concept rather than a check, and states no exclusion beyond the free-text and code caveats.

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