Open number-sense practice data and game catalogue for dyscalculia. Read-only.
Scored across 6 tools
Most tools have clearly distinct roles, but get_citation, get_reference, and list_studies all touch citations/references, and get_prevalence versus list_chart_data both retrieve data. The descriptions largely mitigate this by cross-referencing each other, especially the explicit 'use get_reference' guidance.
All six tools follow a snake_case verb_noun pattern: explain_screening_test, get_citation, get_prevalence, get_reference, list_chart_data, list_studies. The use of 'explain' alongside 'get' and 'list' is a minor variation but still consistent and readable.
Six tools is well-scoped for a niche informational site about dyscalculia statistics and screening. Each tool corresponds to a distinct resource or operation, with no obvious redundant entries.
The surface covers screening-test explanation, site citation, prevalence data, reference lookup, chart/table datasets, and study listing, so core informational workflows are supported. A minor gap is that only prevalence has a dedicated data getter; other statistics topics such as persistence, math anxiety, and interventions rely on generic list_chart_data or list_studies rather than direct tools.
Describes the five screening games on dyscalculia.io: what each measures, how many items it has, what an item is and how items and games are scored in general terms, and the limits. Optionally returns the item sets (dot counts, number pairs, number-line targets, digit-sequence lengths). It describes the test only: it does not score anyone, take answers or return a result. The test is a screening of basic number skills, not a diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | One game key: dotEnumeration, symbolicCompare, nonSymbolicCompare, numberLine, digitSpan. | |
| include_items | No | Include the item sets. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that it optionally returns item sets, describes scoring only in general terms, and explicitly does not score, take answers, or return a result. That extra behavioral context is exactly what an agent needs to avoid misusing the 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?
The description is front-loaded with the core purpose and then quickly covers return behavior and scope limits. It is dense but every sentence contributes useful information without repetition.
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 two-parameter explanatory tool with no output schema, the description is complete: it covers what is described, optional returns, general scoring scope, limits, and the crucial non-diagnostic caveat. An agent has enough context to invoke it correctly.
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 schema already documents both parameters and their allowed values. The description adds some useful context about optional item sets and the five games, but it does not add significant meaning beyond the structured 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?
The description names a specific verb and resource: it 'describes the five screening games on dyscalculia.io' and summarizes what each measures. It also explicitly distinguishes this explanatory role from scoring or answering, so an agent can immediately tell what the tool does not do.
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?
The description makes the usage context clear: use this to learn about the screening test, not to score anyone or submit answers. It gives a strong when-not boundary, though it does not name alternative sibling tools or comparison cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
License (the compilation is CC BY 4.0; each figure belongs to its cited source), the citation text, an HTML credit link and the download addresses. To cite a single number, cite its study: use get_reference.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing that the compilation is CC BY 4.0, that each figure belongs to its cited source, and that the tool returns citation text, an HTML credit link, and download addresses. It does not describe response structure or pagination, but for a simple read-only citation tool the added licensing nuance is meaningful.
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 description is two compact sentences with no wasted words. It front-loads the license and returned artifacts, then ends with the sibling routing instruction, making it easy to scan.
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 parameters, no output schema, and annotations covering read-only behavior, the description supplies what an agent needs: what the tool returns, the licensing nuance, and when to use get_reference instead. Nothing essential for correct invocation 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?
The tool has zero parameters, so the baseline is 4. There are no parameters whose semantics the description needs to clarify, and the description appropriately focuses on returned content instead.
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 states that the tool provides license information, citation text, an HTML credit link, and download addresses for the dyscalculia.io data. It also explicitly distinguishes itself from the sibling tool get_reference for citing a single number. An agent can identify the tool's purpose without opening any 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?
The description gives a clear alternative: to cite a single number, use get_reference. It implies this tool is for citing or reusing the compilation, licensing details, and download addresses, but it does not explicitly state a when-to-use sentence for this tool beyond the content list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Published dyscalculia prevalence figures with sample size, publication year, age, the reference key (see get_reference) and a calc flag (true when the site calculated the figure itself). Filter by study id, by age (entries whose stated age range includes it; entries with no stated age are never matched) or by a percent range (entries whose figure or range overlaps it). With no filter, returns all 10 entries. These are published research estimates, not a diagnosis of any person. There is no worldwide pooled meta-analysis of dyscalculia prevalence: the 'worldwide' entry is a range across population studies. Studies use different criteria and ages, so figures are not directly comparable.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Age in years, e.g. 11. | |
| study | No | One study id: worldwide-range, german-guideline, israel-1996, brazil-2016, uk-morsanyi-2018, england-devine-2018, england-devine-2013, uk-lewis-1994, flanders-2004, inserm-2007. | |
| max_pct | No | Upper bound in percent. | |
| min_pct | No | Lower bound in percent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint by disclosing result-set size, that the 'worldwide' entry is a cross-study range rather than a pooled meta-analysis, and that figures are not directly comparable across studies. It also clarifies the calc flag semantics and that the data is not a diagnosis. Minor gap: no mention of ordering or whether results are cited/stable.
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-loaded with what is returned, then filter semantics, then interpretive caveats; every sentence carries information. It is dense but not padded—the caveat block is long yet materially useful.
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 four optional params, no output schema, and read-only annotations, the description supplies the filter behavior, returned field set, default behavior, and interpretation limits an agent needs to call and use it correctly.
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 already 100%, so baseline is 3; the description earns higher by specifying matching semantics the schema cannot convey — age matches when the stated age range includes it and unaged entries never match, while percent filters match on figure/range overlap. Study and percent parameters are only lightly touched, keeping 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?
States a specific resource (published dyscalculia prevalence figures) and immediately enumerates the returned fields, so the agent knows exactly what comes back. It explicitly routes reference-key lookups to the sibling get_reference, showing it can be distinguished from neighbors without opening schemas.
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?
Explains the three filter modes and the no-filter default ('returns all 10 entries'), and names get_reference as the companion tool for keys. It lacks an explicit statement of when to prefer a sibling like list_studies over this tool, but the usage context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full citation for one reference key (for example shalev2000, grosstsur1996), with its DOI and PMID when the site has them, the link the site uses, and the topics that cite it. The site holds 93 references; keys are returned by get_prevalence and list_studies.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Reference key, e.g. shalev2000 |
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 genuinely useful context beyond that: DOI/PMID are only present 'when the site has them' (conditional fields), the site is a fixed small corpus of 93 references, and citing topics are included in the response.
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, both front-loaded: what you get first, then where the key comes from. No filler, and the corpus size is stated in a compact clause rather than a separate sentence.
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, and the description compensates by naming the returned fields and their conditional nature. For a one-parameter lookup with annotations covering the safety profile, nothing an agent needs in order 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 coverage is 100% and already describes the key field, so the baseline is 3. The description earns an extra point by supplying example key formats and specifying the two sibling tools that produce valid keys, which the schema does not.
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 ('Full citation for one reference key') and enumerates the returned fields: DOI, PMID, site link, and citing topics. The example keys (shalev2000, grosstsur1996) make the shape of the input concrete, so an agent can distinguish it from list-oriented siblings immediately.
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 tells the agent where keys come from ('keys are returned by get_prevalence and list_studies'), which is real routing guidance for obtaining the required parameter. However, it never addresses the closest-sounding sibling get_citation or states when-not to use this tool, leaving a differentiation gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the chart and table datasets on the statistics page (id, title, topic, section, row count) with their download addresses: the CSV and JSON of the whole page, one SVG per chart, the screening-test JSON and the changelog JSON. Pass an id (for example chart-1, table-2) to get that dataset's rows with their values, notes and reference keys.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | One of: chart-1, chart-6, chart-8, chart-9, table-2, table-4, table-5. |
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 real value by disclosing what is returned (dataset metadata, download addresses for CSV/JSON/SVG/screening-test/changelog, and row values with notes and reference keys). No contradiction with annotations. It does not mention result size or pagination behavior for large datasets, keeping it at 4.
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 with the default no-argument behavior and followed by the id variant. Every clause carries information: returned fields, downloadable artifacts, and per-dataset payload. No filler.
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 carries full responsibility for describing return content, and it does so thoroughly — enumerating metadata fields, the five download address types, and the row-level payload. Combined with annotations that cover the safety profile and a fully documented single parameter, 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 coverage is 100% and the enum of valid ids is already in the schema, so the baseline would be 3. The description goes beyond it by explaining the semantic consequence of the id parameter — that it returns that dataset's rows with values, notes and reference keys — and by giving concrete example ids.
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 (lists chart and table datasets on the statistics page) and even enumerates the returned fields (id, title, topic, section, row count) plus the download artifacts. It also clarifies the second mode when an id is supplied, so the tool's scope is unambiguous against siblings like get_prevalence or get_reference. It stops short of naming a sibling it is not, so a 4 rather than 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?
The description explicitly tells the agent how to switch modes: call with no argument to enumerate datasets, pass an id (e.g. chart-1, table-2) to get that dataset's rows. That is clear operational context. However, it names no alternatives or exclusions (e.g. when to prefer get_prevalence for a rate instead), so it lacks true when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every source the statistics page cites (peer-reviewed studies with DOI or PMID, plus official statistics and guidelines), with the topics each supports and, for population studies, the prevalence entries built from them. Filter by topic: prevalence, persistence, math-anxiety, interventions, by-country, sex-ratio, comorbidity, key-figures, family, official-counts, method. Use get_reference for one full citation.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | One of: prevalence, persistence, math-anxiety, interventions, by-country, sex-ratio, comorbidity, key-figures, family, official-counts, method. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's job is added context, and it delivers: it discloses what counts as a source, that population studies carry derived prevalence entries, and the granularity of returned data. What's missing is scale/pagination or ordering behavior for a potentially large list, which is a real but secondary 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?
Two sentences, zero filler, front-loaded with the scope of the result set before the filter enumeration and the sibling routing. The long enum list is a necessary lookup aid rather than 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?
No output schema exists, and the description does carry the burden of describing return content well: sources plus their supported topics plus derived prevalence entries. Only ordering, pagination and rough result size are unaddressed, which is minor for a single-optional-parameter list 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% and the single topic parameter is fully documented there. The description restates the enum values verbatim but adds no meaning beyond them — no note on what an unfiltered call returns versus a filtered one. Baseline 3 applies since the schema does the heavy lifting.
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?
Specific verb (lists) plus a precisely characterized resource: peer-reviewed studies with DOI/PMID, official statistics and guidelines, with the topics each supports. It also carves out an explicit boundary against the sibling get_reference, so an agent can distinguish it 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?
States the filtering dimension with the full allowed values and then names the alternative for a different need ('Use get_reference for one full citation'), which is exactly the when/when-not routing an agent requires. The default (no filter) is implicitly the unfiltered list, and the topic options make selection unambiguous.
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.
explain_screening_testget_citationget_prevalenceget_referencelist_chart_datalist_studiesPhonics word lists and reading-game catalogue for dyslexia support. Read-only.
Read-only mindfulness games, guided practices, research, glossary and PanchaVikas resources.
Read-only game, setup, place, evidence and travel decision tools with explicit provenance.
Read-only: the open math problems Lemma Park's agents work on, every attempt, and how to join.
Add one secure layer between your agents and this server.