Phonics word lists and reading-game catalogue for dyslexia support. Read-only.
Scored across 6 tools
Each tool has a distinct scope: list discovery, per-list retrieval, pattern search, grade aggregation, citation/license, and placement rationale. The metadata tools and the four word/list tools are clearly separated by inputs and outputs, so misselection is unlikely.
All names are snake_case and follow a consistent verb_noun pattern using find_, get_, or list_ plus an object. The variation among find/get/list maps naturally to search, retrieve, and enumerate actions.
Six tools cover the read-only reference surface without redundancy. Each is necessary for discovery, retrieval, search, aggregation, or attribution.
The surface covers listing, per-list retrieval, pattern search, grade aggregation, citation, and placement basis. Minor gaps exist: there is no direct exact-word lookup or cross-list all-words endpoint, though agents can approximate these via find_words or get_word_list.
Finds words in the lists that start with, end with or contain a letter pattern, for example 'sh', 'ck', '-ight' or 'ai'. Returns each match with its list, grade range and page. Case-insensitive.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | Only English lists covering this grade. | |
| limit | No | Default 60. | |
| contains | No | ||
| language | No | ||
| ends_with | No | ||
| starts_with | No |
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 useful behavior beyond annotations by stating that matches include list, grade range, and page, and that matching is case-insensitive. It omits pagination/limit behavior, which keeps it below 5.
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 tight sentences, front-loaded with the core purpose and followed by return and case-sensitivity details. Every sentence carries useful information with no repetition or 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?
For a six-parameter search tool with no output schema, the description does a reasonable job explaining pattern matching and return fields. However, it leaves out limit/pagination behavior, language filtering, and whether multiple pattern filters are combined with AND or OR, so an agent would still need to inspect the schema and infer behavior.
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 only 33%, so the description needs to compensate. It usefully explains the semantics of the starts_with, ends_with, and contains pattern parameters with examples and notes case-insensitivity, but it does not clarify how those parameters combine, nor does it explain language filtering or limit behavior.
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 verb and resource: finding words in lists by letter pattern, with starts-with, ends-with, and contains modes. The pattern-focused purpose clearly distinguishes it from sibling tools like get_words_for_grade and get_word_list.
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 implies this is the tool to use for pattern-based word lookup, but it does not explicitly say when to choose it over siblings such as get_words_for_grade or get_word_list. No exclusions or alternative-routing guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
License (CC BY 4.0 for the compilation; the Dolch words are public domain), the citation text and the CSV and JSON download addresses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the payload contains (license scope, citation string, download URLs), which is useful behavioral context, but says nothing about format, completeness, or whether the addresses are 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?
It is a single sentence fragment with no verb, which reads as a bullet list of payload items rather than a front-loaded purpose statement. Every element is relevant, but the lack of a leading verb hurts scannability.
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 must explain the return values, and it does so adequately: license terms, citation text, and download addresses. It stops short of describing the shape of the response or how an agent should use the returned citation, which is a minor gap for a zero-param informational 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?
The tool takes zero parameters, so the baseline of 4 applies. The description does not introduce any parameter-related confusion, and the schema coverage is moot with an empty object.
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 content returned (license terms, citation text, CSV/JSON download addresses) and, with the title, makes clear this is a citation/reuse resource rather than a word-list retrieval tool, distinguishing it from siblings like get_word_list. It lacks an explicit verb phrase, but the resource is unambiguous.
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 by the title 'How to cite and reuse the word lists' — an agent can infer it should call this when attribution or download links are needed. There is no explicit when-not or reference to sibling tools, and no statement about how it complements list_word_lists/get_word_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains the source of each grade placement: Dolch's own grade levels (1936, public domain), the Common Core Foundational Skills item that names the skill, or a typical sequence when no standard names it. Includes the limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 nonetheless adds real context the annotations cannot: the licensing/provenance of the data (Dolch 1936, public domain) and the fact that limits are disclosed rather than hidden. It does not describe the response shape, but as a static no-argument explainer that is a minor 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 compact sentences, front-loaded with the core purpose and with the source list immediately after. The trailing fragment 'Includes the limits.' is terse to the point of slight ambiguity about what those limits are, which costs a point but no text 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 parameters, no output schema, and simple read-only annotations, the description covers everything an agent needs to decide to call it. The only shortfall is that it does not say whether this returns a per-word basis or a single document-level explanation, which affects how an agent would use the result.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly does not waste words restating empty schema content.
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: it explains the provenance of each grade placement, and enumerates the three possible sources (Dolch 1936, Common Core Foundational Skills, typical sequence). It does not explicitly position itself against the sibling get_citation, which is the most plausible source of confusion, 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?
There is no explicit 'use this when' or 'do not use' statement, but the content strongly implies the use case: understanding why a word was assigned a grade and what the methodology's limits are. The absence of any routing against get_citation or get_words_for_grade keeps it at implied rather than stated guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full list: every word, its groups (for example -at, -an, -ap families), the grade range, the placement basis, the page URL and the license. Use an id from list_word_lists, e.g. short-a, kindergarten, sh.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | List id, e.g. short-a, kindergarten, vowel-teams, or es:palabras-con-m |
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 clear. The description adds value by listing the returned fields, but it does not disclose other behavioral traits like error handling, id validation, or pagination.
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 with no waste: the first front-loads the return fields, and the second provides usage guidance. Every part of the description 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?
Given a simple one-parameter retrieval tool with no output schema, the description does a good job of enumerating what is returned (words, groups, grade range, placement basis, URL, license) and where to get the id. It could mention the response format or error behavior, but it is largely complete.
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 id parameter is well documented with examples. The description adds the source of the id (list_word_lists), which is a small but useful addition beyond the schema; 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 clearly states that it returns a full word list with specific fields, and it distinguishes itself from list_word_lists by requiring an id from that tool. However, it does not differentiate itself from other siblings like find_words or get_words_for_grade.
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 provides a prerequisite (use an id from list_word_lists) and gives examples, which implies when to use it. But it lacks explicit guidance on when to choose this over alternatives such as find_words or get_words_for_grade, and offers no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every different English word from the lists that cover a grade, deduplicated, with the lists each word comes from. Optional section filter (for example only sight words or only cvc). A grade is a typical guide, not a rule: programs and standards differ, and it is not an assessment of any child. English lists are placed by grade; lists in other languages follow each language's own curriculum and have no grade.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | Yes | pre-k, kindergarten, grade-1, grade-2 or grade-3 | |
| limit | No | Maximum words to return. Default 300. | |
| section | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the description's added value is the return shape (deduplicated words plus their source lists) and the scoping rule that only English lists are grade-placed. The caveat that grade is a guide rather than an assessment is meaningful behavioral context an agent would otherwise have to guess. It stops short of noting ordering or truncation behavior beyond the schema's limit.
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 what is returned, then the optional filter, then the grade caveat. No sentence is redundant and the most decision-relevant information comes first.
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 the burden of describing the response, which it does (deduplicated words with source lists). Combined with the grade/language scoping caveat, an agent has enough to call it correctly; only pagination/ordering detail is absent.
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 67%, and the description fills the notable gap by giving meaning and examples for the undocumented 'section' enum and by framing 'grade' as a curriculum guide rather than a strict rule. The 'limit' parameter is left to the schema, which already documents its default and bound.
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 opening clause states a specific verb and resource — every distinct English word across the lists covering a grade, deduplicated, with per-word list provenance. It implicitly separates itself from single-list siblings (get_word_list) and search siblings (find_words) by describing aggregation across lists, but never names them.
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 optional section filter is illustrated with examples ('only sight words or only cvc'), which implies when to use it. However, there is no explicit statement of when to choose this tool over get_word_list or find_words, and no when-not guidance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the available word lists with id, title, language, section, grade range, the source of the grade placement and word count. Filter by language, grade (English lists whose grade range includes it) or section. A grade is a typical guide, not a rule: programs and standards differ, and it is not an assessment of any child. English lists are placed by grade; lists in other languages follow each language's own curriculum and have no grade.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | English lists that cover this grade. | |
| section | No | cvc, families, sight, digraphs, patterns or wordlist (other languages). | |
| language | No | en, de, es, fr, nl or pt-br. Omit for all. |
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 value by clarifying that non-English lists carry no grade and that grade placement is not an assessment, but says nothing about result volume, pagination, or ordering. Reasonable but not rich for the lower annotation bar.
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?
Returned fields and filters are front-loaded, and the grade caveat is placed after the operational content where it belongs. It is slightly longer than needed, with the 'typical guide, not a rule' point repeated in spirit, but no sentence 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 compensates by listing the returned fields, and all three optional enum parameters are covered at 100% schema coverage. The grade-placement semantics fill the main conceptual gap; only result ordering/pagination is left unaddressed, which is minor for a small read-only catalog 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, but the description goes beyond the schema by stating that English lists are placed by grade while other languages follow their own curriculum and have no grade — meaning a grade filter implicitly excludes non-English lists. That interaction is not obvious from the enum descriptions alone.
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?
Opens with a specific verb+resource ('Lists the available word lists') and enumerates the returned fields (id, title, language, section, grade range, placement source, word count), which clearly separates it from the singular get_word_list and find_words. It stops short of naming a sibling explicitly, so it lands at clear-but-not-differentiated.
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 filtering axes and the semantics behind the grade filter ('English lists whose grade range includes it'). It gives a clear usage context and caveat (grade is a guide, not a rule), but offers no explicit when-not or pointer to an alternative tool.
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.
find_wordsget_citationget_placement_basisget_word_listget_words_for_gradelist_word_listsOpen number-sense practice data and game catalogue for dyscalculia. Read-only.
Read-only mindfulness games, guided practices, research, glossary and PanchaVikas resources.
Read-only IELTS and CELPIP question banks, learner practice, progress, scores, and feedback.
Read-only scripture-study engine: complete-or-fail concordance over Greek NT, Hebrew OT, LXX.
Add one secure layer between your agents and this server.