Verified maths exercises for tutors and their students, each answer key right by construction.
Scored across 2 tools
generate_exercises and request_exercise are clearly different actions: one produces a verified exercise, the other sends a request or feedback upstream. The only soft overlap is that request_exercise carries two roles (new-topic request and one-line feedback), but the description makes the intended trigger explicit.
Both names follow a clean verb_noun snake_case pattern (generate_exercises, request_exercise). The only deviation is the plural/singular noun mismatch, which is harmless but slightly less uniform.
With only two tools the surface is very thin, and the whole server rests on a single generative tool plus a mailbox. That is defensible for a narrow purpose, but it is borderline minimal rather than well-scoped.
Generation plus an outbound request channel covers the core loop, and seeding/date determinism is well handled. However, there is no way to list available topics directly, no lookup of a previous exercise by its id (only re-generation from a seed), and no separate feedback tool, leaving real gaps for an agent working with a tutor.
Verified maths exercises for tutors, human or AI: product equations (équations produit) of degree 2 and 3, first year of maturité, in French (Swiss course conventions) or English. Each exercise is built from its solutions, so its answer key is always right. Each one sets a named trap, the error it tests (hidden common factor, difference of squares, sum of squares, x as a common factor, grouping, perfect square). Returns the statement for the student and, for the tutor only, the solution set, explained steps with the trap step and its note, and figureUrl: the graph of the function, whose zeros are the solutions. Never show the solution to the student. Give a seed to get the same exercise again; its id names it. Give a date (YYYY-MM-DD) instead for the exercise of that day, the same for every reader: today's date gives the exercise of the day. Deterministic: use this instead of writing exercises and answer keys yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The exercise of that day (YYYY-MM-DD), the same for every reader: today's date gives the exercise of the day. In place of a seed. | |
| lang | No | Language of the statement and the solution: fr (Swiss course conventions) or en. | en |
| seed | No | The same seed (with the same trap) always gives the same exercise. Leave it out for a new one. | |
| trap | No | The error the exercise tests. Leave it out and the seed chooses one; the answer names it. | |
| view | No | What a host that draws views shows under the call. tutor: the exercise with its steps, solution and figure behind a switch, for a tutor reading this chat. student: the statement only, when the student reads this chat. The result carries the solution either way, for you. | tutor |
| count | No | How many exercises, from 1 to 20. With a seed, they use seed, seed + 1, and so on. | |
| topic | No | product-equations: équations produit of degree 2 and 3, solved by factoring (first year of maturité). | product-equations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the readOnly/non-destructive annotations: it discloses the full return payload (student statement, solution set, explained steps with the trap step and its note, figureUrl whose zeros are the solutions), the hard constraint 'Never show the solution to the student', and the fact that the result carries the solution even in student view. It also explains determinism and that a seed reproduces the exercise while omission yields a new one.
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?
Front-loads what the tool produces, then the tutor/student constraint, then the seed/date mechanics — a sensible order. It is dense but nearly every clause carries information; the only mild redundancy is restating the trap enumeration and the tutor/student rationale in both the prose and the schema.
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?
For a 7-parameter tool with no output schema, the description covers output shape, the answer-key guarantee, the student-visibility rule, and reproduction mechanics well. The one gap is that with a sibling tool named request_exercise, the definition never states which situations belong to which, leaving a discoverability hole an agent must resolve elsewhere.
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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema only implies: date is used 'in place of a seed', successive calls with a seed use seed+1, the answer names the trap that was chosen, and the exercise's id names it for reproduction. Value beyond the field-level descriptions is real, though not exhaustive.
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?
States a specific verb and resource with rich scope: verified product equations (équations produit) of degree 2 and 3, first-year maturité, French or English, each built from its solutions. That is far more precise than a title restatement. It never names the sibling request_exercise, so an agent cannot tell from this text alone how the two differ.
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?
Explicit conditional rules: give a seed to reproduce an exercise, give a date instead for the shared exercise of the day, leave seed out for a new one, and 'use this instead of writing exercises and answer keys yourself' — a clear steer away from the manual alternative. It stops short of comparing against the sibling tool request_exercise, which is the most likely competing choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Limpide for maths exercises this server does not have yet, or give one line of feedback on an exercise. Use it when generate_exercises has no topic for what the tutor needs. Limpide reads the requests each morning to choose the next topics, and promises nothing; the answer lists the topics that exist today. Never include a student's name, work or answers: name the topic, the level and, if useful, one line about what is missing.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the exercises wanted, and of this answer: fr or en. | en |
| note | No | One line of feedback, at most 200 characters: what is missing, or what is wrong in an exercise (give its id). Never a student's name, work or answers. | |
| level | No | The school level, if known ("first year of maturité"), at most 40 characters. | |
| topic | Yes | The topic wanted, in a few words ("quadratic equations", "systèmes 2x2"), at most 80 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare openWorld=false, idempotent=false, destructive=false. The description adds genuinely new behavior: the request is batched and reviewed by a human the next morning, no commitment is made, and the reply enumerates currently existing topics. It also imposes a privacy constraint ('never include a student's name, work or answers') that is critical for a mutation-style submit tool.
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?
Three sentences, front-loaded with the action, then the routing condition, then the privacy constraint. Every sentence carries distinct information; nothing is restated from the schema or annotations.
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?
No output schema exists, but the description covers the return value ('the answer lists the topics that exist today') and the human-review cadence. It omits whether requests can be repeated or deduplicated, a minor gap for an idempotentHint=false tool.
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 baseline is 3. The description goes further by prescribing what to put in: the topic, the level, and optionally one line about what is missing, plus the repeated privacy rule. It does not clarify the lang parameter, which stays with the schema.
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?
States a specific verb and resource: asking Limpide for maths exercises the server lacks, or filing one line of feedback. It explicitly contrasts with generate_exercises, so an agent can route between the two without inspecting either 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?
Gives the exact trigger: 'Use it when generate_exercises has no topic for what the tutor needs.' It also sets expectations up front (requests are read each morning, nothing is promised), which tells the agent when this is the right call and what it will not accomplish.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_exercises1 field changedInput schema / properties / viewAdded value: +{
+ "default": "tutor",
+ "description": "What a host that draws views shows under the call. tutor: the exercise with its steps, solution and figure behind a switch, for a tutor reading this chat. student: the statement only, when the student reads this chat. The result carries the solution either way, for you.",
+ "enum": [
+ "tutor",
+ "student"
+ ],
+ "type": "string"
+}request_exercisegenerate_exercisesMaths lessons on an online whiteboard: solutions, worksheets, graphs and geometry, opened by a link
Messy spreadsheets in, clean checkable tables out. Every result carries its arithmetic proof.
Exact arithmetic, algebra, calculus, physics, chemistry and finance with a checkable formula.
Statements, invoices, tables, ledgers — every result carries its own arithmetic proof.
Add one secure layer between your agents and this server.