Learn Python by building glowing math patterns: lessons, scripts, quiz checks and concepts.
Scored across 6 tools
The six tools mostly target clearly different artifacts: catalog (list_patterns), course order (learning_path), one lesson (get_lesson), one script (get_code), concept lookup (explain_concept), and answer checking (check_answer). The main near-overlap is between list_patterns and learning_path, both navigational, and between explain_concept and get_lesson, though descriptions make the distinction workable.
Five of six names follow a clean verb_noun pattern: check_answer, explain_concept, get_code, get_lesson, list_patterns. Only learning_path breaks the pattern as a noun phrase, a minor but noticeable deviation.
Six tools is well within the ideal 3-15 range for a lesson/code reference server. Each tool covers a distinct need: browsing patterns, following the course, reading a lesson, viewing code, looking up concepts, and checking answers.
The server covers the core read-only learning surface well: lesson content, scripts, concept lookup, quizzes, and course navigation. Minor gaps exist around user progress tracking or retrieving a specific exercise/quiz by ID, but these are not necessarily in scope.
For a quiz question of a lesson: says whether the answer is right, which option is, and why. For an exercise: gives its hint and its reference answer to compare the learner’s attempt with (this server does not grade free text and never runs code); offer the hint first and the reference only after a try.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | A quiz question or an exercise | |
| lang | No | The language of the answer: en (the default), pl; es, pt, fr, de, ja and ko for patterns and lessons (the course stays in English there) | |
| answer | No | The learner’s answer: for the quiz the option’s text or its number (1 to 3); for an exercise optional | |
| number | Yes | Its number in the lesson, from 1 | |
| pattern | Yes | The pattern (its slug), as list_patterns gives it |
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.
Finds a Python or math idea in the lessons (e.g. "np.roll", "recursion", "golden ratio", "binomial", "leapfrog", "attractor") and gives what the lessons say about it, with the lesson and video that show it.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The language of the answer: en (the default), pl; es, pt, fr, de, ja and ko for patterns and lessons (the course stays in English there) | |
| concept | Yes | The idea to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, and the description adds value beyond that by describing what is returned: lesson content plus the citing lesson and video. It stops short of stating not-found behavior or how many matches to expect, which would round out the read semantics.
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?
A single well-structured sentence with the action front-loaded and the return shape trailing. The six-item example parenthetical is on the long side but each example clarifies the accepted concept granularity, so little is wasted.
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 adequately by naming lesson text plus lesson and video references. Missing are edge cases such as no-match behavior and result-count expectations for a search-style 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 coverage is 100% so the baseline is 3, and the description earns a bump by illustrating the granularity of the concept parameter with real lookup strings ("np.roll", "binomial", "leapfrog", "attractor"). The lang parameter is not mentioned at all in the description, which keeps it from a 5.
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 a specific verb-and-resource pair ("Finds a Python or math idea in the lessons and gives what the lessons say about it") and enumerates the domain with concrete examples like "np.roll", "recursion", and "golden ratio". It also states the shape of the answer (lesson content plus the lesson and video that show it), which separates it from get_lesson or list_patterns without the agent needing to open a 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?
Usage is implied rather than stated: the agent can infer this is the concept-lookup tool rather than an ID-based lesson fetch or a pattern listing, but there is no explicit "use this when..." sentence and no alternative named. No guidance on what to do when a concept is unknown or ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole Python script of a pattern (numpy and matplotlib, under 80 lines), as the lesson and the site show it and as the site’s tests run it, with how to run it, what to change to see something new, and a Google Colab notebook to run it in a browser.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The language of the answer: en (the default), pl; es, pt, fr, de, ja and ko for patterns and lessons (the course stays in English there) | |
| pattern | Yes | The pattern (its slug), as list_patterns gives it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and closed-world behavior, so the bar is lower, and the description still adds real content: the script is short, uses numpy and matplotlib, is test-verified, and comes with execution instructions and a browser-runnable Colab notebook. It does not discuss localization of the returned script, which is the main unstated behavior.
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?
It is a single sentence with the resource front-loaded and no filler. The stacked clause 'as the lesson and the site show it and as the site's tests run it' is slightly redundant, which keeps it from a 5.
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 burden of describing the return value, and it does so concretely: script body plus run steps, modification hints, and a Colab link. The only gap is how the lang parameter affects the script and accompanying text.
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%, and both parameters are enums fully documented in the schema, so the baseline of 3 applies. The description adds nothing about the lang parameter or which pattern slugs exist, leaving the schema to carry that load.
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 a specific resource (the whole Python script of a pattern, numpy/matplotlib, under 80 lines) and lists the bundled extras (run instructions, tweak guidance, Colab notebook). This clearly separates it from get_lesson and list_patterns, though it never names those siblings explicitly.
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?
Usage is only implied: an agent can infer this is the tool for full runnable code as opposed to lesson prose or concept explanations. There is no explicit when-to-use statement, no guidance on pairing it with get_lesson, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One lesson of the course: the question the pattern asks, why it works at three depths, the formula, its script line by line with explanations, exercises with hints, a quiz and flashcards. Exercise answers and quiz keys are left out on purpose: use check_answer once the learner has tried.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The language of the answer: en (the default), pl; es, pt, fr, de, ja and ko for patterns and lessons (the course stays in English there) | |
| pattern | Yes | The pattern (its slug), as list_patterns gives it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond them: the content deliberately omits answers and quiz keys, which prevents an agent from misreading the payload as incomplete or retrying for missing data. It says nothing about size, pagination, or the language-switching behavior, so it is not exhaustive.
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, zero filler, with the content inventory up front and the answer-withholding caveat plus redirect to check_answer at the end. The middle clause is a dense comma-list that is slightly harder to scan than a structured breakdown, but every element earns its place.
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?
There is no output schema, so the description correctly spends its words telling the agent what a lesson payload contains, which is exactly the missing piece. Combined with the intentional-omission note, an agent can call this correctly and interpret the result. Minor gaps remain around ordering, size, and the relationship to explain_concept.
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% and both parameters carry enums with their own descriptions, including the note that the course stays in English for non-en languages. The description adds no parameter-level meaning of its own. A 3 baseline is appropriate where the schema does the work.
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 clearly scopes the tool to a single lesson of a course and enumerates its contents (question, three-depth explanation, formula, line-by-line script, exercises with hints, quiz, flashcards), which effectively distinguishes it from get_code and explain_concept. It never states a verb like 'return' or 'retrieve', so the action is inferred from 'One lesson of the course', keeping it short of a 5.
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 routing rule for the main ambiguity: exercise answers and quiz keys are withheld, so the agent should call check_answer after the learner has tried. That is concrete when-to-use guidance tied to a named sibling. It does not address when to prefer explain_concept or get_code over a full lesson, so the coverage of alternatives is partial rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The free Python course in its order: each lesson builds one pattern in a short numpy/matplotlib script, from arrays and loops (Beginner) to randomness and recursion (Intermediate) to simulations and grids (Advanced). Each lesson with what it teaches and its link. Optionally only one level.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The language of the answer: en (the default), pl; es, pt, fr, de, ja and ko for patterns and lessons (the course stays in English there) | |
| level | No | Only the lessons of this level |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations: the lessons are short numpy/matplotlib scripts that progressively build patterns, and the output includes teaching summaries and links — valuable since there is 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?
The definition is front-loaded with the core purpose and reasonably tight. The sentence 'Each lesson with what it teaches and its link' is a fragment and the level progression list is verbose, but both carry useful information without excessive padding.
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 read-only index tool with no required parameters and no output schema, the description is complete enough: it explains what is returned (each lesson with teaching point and link), the ordered nature, and the optional level filter. Language semantics remain in the schema, which is acceptable given full coverage.
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 both parameters are already documented in the schema, including language behavior and level filtering. The description reinforces that level filtering is optional but adds no syntax or semantics beyond the schema, making baseline 3 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 states a specific resource and scope: the free Python course lessons in their intended order, each with its teaching point and link. It distinguishes the content by level progression, but does not explicitly differentiate from siblings like get_lesson or list_patterns, leaving that inference to the agent.
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?
Usage is implied (fetch the ordered course outline, optionally filtered to one level), and 'Optionally only one level' communicates the level filter's optionality. However, there is no explicit guidance on when to use this versus get_lesson, list_patterns, or other siblings, and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The patterns of the channel: each one simple rule (the golden angle, the Galton board, Turing patterns…), its category, whether it has a Python lesson and at what level, with links to its page and newest video.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | The language of the answer: en (the default), pl; es, pt, fr, de, ja and ko for patterns and lessons (the course stays in English there) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral content by spelling out the per-item fields returned, including derived flags like 'whether it has a Python lesson and at what level'. It says nothing about ordering, pagination, or result size, which is the main remaining gap.
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?
A single front-loaded sentence: resource first, then the field breakdown. Dense but readable, with the parenthetical examples earning their place by making 'pattern' concrete. Slightly long as one sentence but nothing is redundant.
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 steps in and describes the returned record structure item by item, which is exactly what an agent needs to decide whether to call it. Combined with fully documented optional parameters and read-only annotations, the definition is essentially complete; only ordering/paging behavior is left unstated.
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?
There is one optional parameter with 100% schema description coverage and an enum listing all eight language codes, so the schema carries the semantics fully. The description never mentions language and adds no meaning beyond it, which is the baseline case for high coverage rather than a strength.
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 a specific verb+resource ('The patterns of the channel') and then enumerates exactly what each entry contains: rule, category, Python-lesson availability and level, page link, newest video link. That is far more than a restatement of the name. It does not explicitly distinguish itself from get_lesson or learning_path, so it stops short of a 5.
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?
Usage is only implied: the shape of the response (list of patterns with links) signals a browse/overview call, and the mention of 'links to its page' hints that detail lookups happen elsewhere. No sentence states when to prefer this over get_lesson, get_code, or learning_path, and there are no exclusion conditions.
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.
check_answerexplain_conceptget_codeget_lessonlearning_pathlist_patternsVerified maths exercises for tutors and their students, each answer key right by construction.
Map prerequisites, track mastery and recommend the next topic each learner is ready for.
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Create structured courses, lessons, and educational images for any topic, level, and language.
Add one secure layer between your agents and this server.
