This server provides local and network-based language checking tools for Dutch and US English, designed for AI agents to validate and improve text (e.g., resumes, cover letters, blogs).
Check US English text: Detect typos and British spellings/vocabulary (e.g., colour, whilst, towards) with US replacements, using local hunspell en_US and a British-form detector.
Validate a single US English word: Quickly check spelling and get suggestions for US English, including British form detection.
Check Dutch text: Spell-check Dutch prose locally using OpenTaal/hunspell, returning unknown words, suggestions, and positions.
Validate a single Dutch word: Check spelling and get suggestions for Dutch words.
Get official Dutch word details (network): Retrieve lemma, part of speech, pronunciation, hyphenation, paradigm, and diminutive forms from woordenlijst.org (rate-limited, for individual important words).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@language-mcp Controleer de spelling van: 'Hij heeft dat niet geweten.'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local MCP server for Dutch and US English language checks, built for AI agents (Hermes, Claude, and others) that write resumes, cover letters, blog articles, and website copy.
Currently supported: Dutch and US English. Additional languages can be implemented by adding dictionaries, language-specific rules, and MCP tools; they are not supported automatically by selecting an arbitrary language.
Tool | Source | Network | Purpose |
| hunspell en_US + British form detection (local) | No | Check text for typos and British spelling or vocabulary, with US replacements |
| hunspell en_US | No | B1 plain-language proxies: readability (Flesch Reading Ease, Flesch-Kincaid, ARI), sentence/paragraph length, passive voice, jargon, wordy phrases, hidden verbs, filler, idioms, nominalization density, "you" address |
| hunspell en_US + British form detection (local) | No | Check a single English word for correct US English spelling and suggest replacements |
| OpenTaal/hunspell + selected spelling rules (local) | No | Check words and selected compounds, hyphens, and calendar capitalization; return suggestions, positions, rule IDs, explanations, confidence, and source links |
| OpenTaal/hunspell | No | B1 simplicity proxies: readability (Flesch-Douma, ARI, LIX, Brouwer Leesindex), sentence/paragraph length, passive voice, officialese jargon, filler, idioms, rare-word flags from a Zipf frequency table with plain-synonym suggestions (Open Dutch WordNet), nominalization density, je/u voice |
| OpenTaal/hunspell (local) | No | Check a single Dutch word locally for correct spelling, with suggestions |
| woordenlijst.org (MolexServe) | Yes | Retrieve lemma details: part of speech, pronunciation, hyphenation, paradigm, and diminutive forms |
The local tools use bundled hunspell dictionaries: OpenTaal for Dutch (v2.20.23)
and SCOWL/LibreOffice en_US for US English. The detector for British forms
catches terms that hunspell does not flag (whilst, towards, bespoke,
webshop, sole trader, findability, etc.), including categories from the
Straffe Sites US English guidelines, and provides a US replacement for each match.
get_dutch_word_details queries the internal XML service at woordenlijst.org
(INT/Taalunie). This unofficial integration uses caching and rate limiting
(1.2 seconds between calls); use it only for individual important words.
Tool descriptions and status messages are in US English; Dutch words and
upstream dictionary labels retain their original language.
Related MCP server: kamernet-mcp
check_dutch_text also checks selected patterns that a word dictionary misses:
btw nummer → btw-nummer, keuken tafel → keukentafel, auto ongeluk →
auto-ongeluk, and 3D printer → 3D-printer. Calendar cues such as op Maandag
and in Januari produce medium-confidence suggestions for lowercase spelling.
Each rule finding includes its ID, explanation, original source positions,
confidence, and a precise Team Taaladvies source link.
The rule layer protects code, marked headings, quotations, and other selected
non-prose spans. Pass optional protected_terms for exact case-sensitive names
or unmarked titles; horizontal whitespace may vary. This protection does not
whitelist Hunspell dictionary words.
Accepted variants such as rode kool / rodekool, optional clarity hyphens, and
meaning-dependent word groups are not automatically joined or rewritten.
This is a small, local spelling layer, not a general grammar checker. See the rule catalog, exceptions, limits, and attribution. B1 readability remains a separate check.
Both B1 tools report deterministic proxies with the same structure: a readability block, passive voice, rule hits with plain alternatives and positions in the source text, nominalization density, and a reader-address check. Thresholds are tool parameters because conventions differ by sector.
check_dutch_b1_text reports deterministic B1 proxies, not a validated B1
verdict: "B1" applied to texts is an editorial convention (Rijksoverheid
guideline: write new material at B1, aiming for A2), not an empirically
validated text norm. What the tool measures:
Readability: Flesch-Douma reading ease (NL-adapted Flesch; practical B1 band ~60-70), ARI as a second, language-neutral indication, LIX (Björnsson 1968; Swedish scale, not validated for Dutch — compounds inflate it), and Brouwer Leesindex A (1963 Dutch Flesch recalibration that weighs sentence length twice as heavily as Flesch-Douma). Formulas are suppressed below 50 words / 3 sentences (short-sample guard; the guard is intentional, see the evaluation baseline).
Word frequency: rare-word flags from a bundled Zipf table of the top
50,000 Dutch word forms (derived from FrequencyWords/OpenSubtitles2018 —
spoken-language bias, documented in assets/frequency/README.md). Words
the table knows but scores rare (default below Zipf 3, configurable via
rare_word_zipf_max) are flagged with value, count, and position.
Unknown words are never flagged: Dutch compounds and proper names
dominate that set. When Open Dutch WordNet lists a clearly more frequent
single-word synonym (at least half a Zipf point), the flag includes
concrete suggestions ("staken → try: ophouden, stoppen"); suggestions are
review hints, never automatic replacements.
Sentence and paragraph length against configurable thresholds (defaults: warn >15, flag >20 words per sentence; 150 words per paragraph, matching common editorial guidelines).
Passive voice: hunspell -m morphology batch plus an auxiliary window
(wordt/worden/werd + past participle = high confidence; is/zijn + past
participle = low-confidence zijn-passive; "door" agent noted). These are
review flags: context-free morphology cannot tell a genuine passive from
a copula construction, so editors judge each hit.
Officialese jargon with plain alternatives (betreffende → over, thans → nu, in het kader van → voor...), filler words, and idioms to avoid for NT2 readers, each with the match position in the source text.
Nominalization density (-ing/-tie/-heid/-iteit words per 100 words) and je/u voice consistency (default je, configurable to u).
All checks are local and offline: the same bundled OpenTaal assets and hunspell binary as the spelling tools, plus pure TypeScript rule layers in the spirit of the British-form detector.
The Dutch B1 proxies are grounded in an evaluation baseline: the bundled
City of Amsterdam complex–simple corpus (1,311 sentence pairs, EUPL-1.2,
evaluation-only — nothing from it runs at check time) with a harness that
measures how much more often each proxy flags the complex side of a pair
(tests/eval/b1-amsterdam.ts, committed baseline in
tests/eval/baseline-v1.json, protocol in docs/b1-eval.md). On that set,
passive voice separates +11.8 percentage points and sentence length +10.4;
the rare-word signal separates +3.8; nominalization density and the
long-word share barely separate, and the readability formulas have 0%
coverage on single sentences because of the short-sample guard.
check_us_english_b1_text applies the same approach to US English, with
English formulas, thresholds, and rule sources:
Readability: Flesch Reading Ease (practical B1 band 60-70, "plain English" in Flesch's table), Flesch-Kincaid grade level (default target 9 or lower), and ARI. A zero-dependency syllable counter agrees with the CMU Pronouncing Dictionary on about 94% of the 10,000 most common US English words. The same short-sample guard applies.
Sentence and paragraph length: defaults warn above 20 and flag above 25 words per sentence (plainlanguage.gov average and the GOV.UK limit), and the longest flagged sentences are listed with positions.
Passive voice: hunspell -m with the bundled en_US dictionary marks
regular -ed forms (affix flag D); a closed list covers irregular
participles (written, built, sold). Detects be-passives, get-passives,
and pronoun contractions ("it's built"), notes a "by" agent, skips "used
to", and marks adjectival uses ("is located") as low confidence.
Formal jargon and buzzwords (utilize → use, prior to → before, robust,
leverage), wordy phrases (in order to → to, due to the fact that →
because), hidden verbs (make a decision → decide, provide assistance →
help), filler words, and idioms, based on the Federal Plain Language
Guidelines and the GOV.UK "words to avoid" list. British spellings stay
in check_us_english_text.
Nominalization density (-tion/-sion/-ment/-ance/-ence/-ity per 100 words, everyday nouns excluded) and reader address: third-person references to the reader ("users", "the customer") are reported when the expected address is "you" (default).
Call check_us_english_text with:
{
"text": "We build custom online stores with colorful designs and clear navigation."
}The tool reports the number of words checked, unknown words, and British forms.
It provides suggestions and positions for flagged words. Review suggestions in
context: proper names and technical terms may be valid even when flagged.
For plain-language checks on the same copy, call check_us_english_b1_text
with the same text. For Dutch copy, use check_dutch_text and
check_dutch_b1_text instead.
Requirements: Node 20+ and hunspell on PATH (pacman -S hunspell).
npm install
npm run build # Compile TypeScript into dist/npm test # Run node:test through tsxmcp_servers:
language:
command: node
args: [/absolute/path/to/language-mcp/dist/cli.js]
connect_timeout: 60
enabled: true
timeout: 120Code: MIT.
Dictionary assets:
assets/nl.dic / assets/nl.aff: © OpenTaal — Revised BSD License and/or CC BY 3.0. Full terms are in assets/LICENSE.txt; source: https://github.com/OpenTaal/opentaal-hunspell. Reusing these assets requires attribution to OpenTaal.
assets/en_US.dic / assets/en_US.aff: based on the SCOWL word list (Kevin Atkinson, LGPL), with an affix file from Geoff Kuenning's Ispell (BSD), distributed through LibreOffice/dictionaries. See assets/en_US-LICENSE.txt and assets/en_US-README.txt; source: https://github.com/LibreOffice/dictionaries/tree/master/en.
Data assets (each bundled with its own license and attribution file, kept separate from the MIT code):
assets/frequency/nl-zipf.tsv: Zipf frequencies for the top 50,000 Dutch
word forms, derived from hermitdave/FrequencyWords nl_50k.txt
(OpenSubtitles2018). Content CC BY-SA 4.0; see
assets/frequency/README.md (includes the spoken-language bias caveat).
assets/synonyms/nl-synonyms.tsv: Dutch synonym table (31,199 lemmas),
derived from Open Dutch WordNet release 1.4 (VU Amsterdam, CLTL). CC BY-SA
4.0; see assets/synonyms/LICENSE and assets/synonyms/README.md. When
using this data, cite: Postma, Van Miltenburg, Segers, Schoen & Vossen
(2016), "Open Dutch WordNet", Proceedings of the 8th Global WordNet
Conference. CC BY-SA obligations apply to distributing the derived data,
not to texts checked with the tool.
assets/eval/amsterdam-complex-simple/: City of Amsterdam complex–simple
sentence pairs (EUPL-1.2) and the Hobo 2022 lexical-simplification set,
bundled as evaluation-only assets for the B1 harness; never used at
runtime. See the README in that directory.
Evaluation baselines (tests/eval/) are committed artifacts of the runs
documented in docs/b1-eval.md.
get_dutch_word_details data: woordenlijst.org (Instituut voor de Nederlandse
Taal / Taalunie), accessed through its public web service without a separate
API agreement.
Spell-check Dutch text locally (OpenTaal/hunspell). Returns unknown words with suggestions and positions. Use for CVs, cover letters, blog articles, any Dutch prose.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The Dutch text to check | |
| context | No | Optional label, e.g. "cover letter Acme" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It discloses that the operation runs locally (implying privacy/offline behavior), returns unknown words with suggestions and positions (practical output behavior), and is non-destructive in nature. For a read-only spell-check tool this is genuinely useful behavioral context that an agent wouldn't infer otherwise.
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 zero filler. The core function and implementation are front-loaded in the first clause, output behavior follows immediately, and the usage guidance closes it out. Every word 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?
With no output schema, the description sensibly discloses return shape ('unknown words with suggestions and positions'). For a 2-parameter tool at 100% schema coverage, it covers the language, scope, and use cases. It omits only minor details like behavior on fully correct text, but nothing required 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%: both 'text' and 'context' already have descriptions in the schema, so the baseline is 3. The description does not add meaning beyond the schema for these parameters — it doesn't elaborate on the 'context' label's purpose or constrain input format. The description's mention of 'positions' refers to output, not parameters, so no added parametric value.
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 ('spell-check'), resource ('Dutch text'), and implementation ('OpenTaal/hunspell'). Naming 'Dutch' immediately disambiguates it from sibling check_us_english_text, and 'text' vs 'word' distinguishes it from validate_dutch_word and dutch_word_details. An agent can tell these apart from the first sentence.
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 concrete when-to-use guidance: 'Use for CVs, cover letters, blog articles, any Dutch prose.' This clarifies the intended input scope (full prose) and implies the alternative for English text, though it stops short of explicitly naming check_us_english_text or stating when not to use it. Clear context with mild exclusion gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check English text for US English compliance: typos (hunspell en_US) + British spellings/vocabulary (colour, whilst, towards, bespoke, webshop, sole trader...) with US replacements. Use for EN pages, blogs, US-facing copy.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The English text to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool checks typos via hunspell en_US and flags British spellings/vocabulary with US replacements, which is useful. However, it does not disclose whether it returns a list of suggestions, a corrected version, or only a pass/fail result, and no output schema is provided.
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 sentences, front-loads the main action, and uses parenthetical examples efficiently. Every sentence adds value: the first defines behavior, the second defines target use cases.
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?
The tool is simple (one required parameter, no nested objects), and the schema fully covers the parameter. However, there is no output schema and no annotation, so the absence of return-format information is a meaningful gap: an agent can invoke the tool correctly but cannot predict what the result will look like.
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% for the single 'text' parameter, so the schema already defines it as 'The English text to check.' The description adds US-compliance context and examples, but it does not add new parameter-level constraints or formatting details, so the 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 states a specific verb and resource: checking English text for US English compliance, covering typos and British vocabulary. It differentiates itself from the Dutch-focused siblings by explicitly targeting US English, and the examples make the scope concrete.
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 clear context for when to use the tool: 'Use for EN pages, blogs, US-facing copy.' It does not explicitly mention alternatives or say when not to use it, but the guidance is sufficient to select it over the Dutch-oriented siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get official Dutch word details from woordenlijst.org: lemma, woordsoort, uitspraak, syllabisering/afbreking, verkleinwoord, paradigm. Slower (network); use for individual important words, not bulk.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Dutch word or wordform to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool makes a network call and is slower, and that bulk use is inappropriate. However, it does not mention failure modes, rate limits, or what happens for unknown words.
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 efficient sentences with no filler. The tool's resource and output contents are front-loaded, and the usage caveat is provided at the end without redundancy.
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 one-parameter lookup tool with no output schema, the description covers purpose, key return fields, and a practical usage warning. It lacks explicit handling of missing words or network errors, but those are minor given the tool's simplicity.
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 'word' parameter is already documented as 'Dutch word or wordform to look up.' The description adds output-field context but no additional parameter semantics, matching the baseline for complete schema coverage.
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 ('Get'), a specific resource (official Dutch word details from woordenlijst.org), and enumerates the returned fields (lemma, woordsoort, uitspraak, etc.). This clearly differentiates it from the sibling check/validate tools, which focus on correctness rather than lexical details.
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 clear usage context: use for individual important words, not bulk lookups. It also implicitly separates this tool from validation siblings, though it does not explicitly name an alternative or state when to choose a sibling instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check quickly (lokaal) of één Nederlands woord correct gespeld is, met suggesties bij foute spelling.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Single Dutch word |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It adds useful context: the check is local ('lokaal') and fast, and it returns suggestions for misspelled words. However, it does not disclose what happens for correctly spelled words (e.g., return format, success indicator) or any limitations, such as handling of multi-word phrases or case sensitivity. The transparency is partial.
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 a single, concise sentence that front-loads the core purpose (check spelling) and key behavior (local, quick, suggestions). There is no fluff, and every word contributes to understanding. It is efficiently structured for quick scanning by an agent.
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 simple one-parameter tool with no output schema, the description covers the essential purpose and basic behavior. However, it omits the return format for valid vs. invalid words, which an agent would need to interpret the result. It also does not specify the language of suggestions or any edge-case behavior. Given the absence of annotations and output schema, the description is adequate but not fully self-sufficient.
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 schema already provides full coverage of the only parameter 'word' with a clear description ('Single Dutch word'). The tool description repeats this scope but adds no new semantic detail, such as accepted character sets or normalization rules. With 100% schema coverage, the baseline of 3 is appropriate; the description does not degrade or enhance parameter understanding.
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 the tool checks the spelling of a single Dutch word and provides suggestions for misspellings. It specifies the resource (Dutch word) and the verb (check), and differentiates from siblings by limiting scope to a single word, which separates it from check_dutch_text for full text. However, it does not explicitly name alternatives.
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 phrase 'één Nederlands woord' (one Dutch word) implies usage for single-word validation rather than text, and 'quickly' suggests a lightweight check. But there is no explicit guidance on when to choose this over siblings like check_dutch_text or validate_us_word, nor any exclusions. The intended context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check quickly (lokaal) of één Engels woord correct gespeld is volgens US English, met suggesties. Detecteert ook Britse spelling voor losse woorden.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Single English word |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the check is quick and local ('lokaal'), that it returns suggestions ('met suggesties'), and that it detects British spelling for individual words. This provides meaningful behavioral context beyond the mere existence of the operation.
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?
One compact sentence delivers the operation, scope, language standard, locality, and output behavior with no filler or redundancy. Every word earns its place and the core purpose is front-loaded.
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 simple single-parameter validation tool with no output schema, the description covers the essential context: what is checked, under which spelling standard, and what output to expect (suggestions). It could mention exact return format, but the low complexity and the hint about suggestions make it sufficiently 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?
The schema already describes the only parameter 'word' as a 'Single English word' with 100% coverage. The description reinforces the meaning by specifying US English and one-word scope, but it does not add new parameter-level syntax or format details. 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 states the exact verb-resource pair ('Check ... of één Engels woord correct gespeld is volgens US English') and adds concrete scope: one word, US English, with suggestions, plus British spelling detection. This clearly differentiates it from the text-level sibling check_us_english_text and the Dutch-language tools.
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 intended use context clear: validating a single English word against US English. It implies this is not for full texts or Dutch words, but it does not explicitly point to alternatives or state when not to use it. Thus it is clear context without formal exclusions.
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.
v0.2.1check_dutch_textcheck_us_english_textdutch_word_detailsvalidate_dutch_wordvalidate_us_wordScored across 5 tools
Each tool has a clear, distinct purpose: full-text checking (check_us_english_text, check_dutch_text) vs single-word validation (validate_us_word, validate_dutch_word) vs dictionary lookup (dutch_word_details). The descriptions explicitly state scope (text vs one word), eliminating ambiguity. Even the English and Dutch pairs are clearly separated by language and granularity.
Naming follows a consistent verb-based pattern: 'check_' for full-text tools and 'validate_' for single-word tools, with language identifiers. However, 'dutch_word_details' deviates from the pattern (no verb, inverted noun order) and English language identifiers vary ('us_english' vs 'us'). Overall readable, but minor inconsistencies prevent a perfect score.
Five tools is a well-scoped size for a language-checking server, covering both Dutch and US English at two levels (bulk text and individual words) plus a dictionary lookup. Each tool serves a distinct need without redundancy, and the count is not excessive or trivial.
The surface covers the core workflows: checking full text for both languages, validating individual words, and providing Dutch word details. Minor gaps exist, such as no English dictionary details and no explicit grammar checking, but the stated purpose (spelling and US English vocabulary compliance) is fully addressed. Agents can accomplish common tasks without dead ends.
111 tools for AI assistants, so an answer comes from a rule instead of a guess. 84 deterministic utilities. IBAN and VAT validation, cron parsing, regex testing, hashing, JWT decoding, conversion between JSON, CSV, XML and YAML, units, number bases, timezones and date arithmetic. Eleven of them encode Dutch rules that a model tends to get wrong: AOW pension age, inheritance and gift tax, unemployment benefit duration, notice period, severance, the 30 percent ruling, holiday allowance, mileage allowance, and public and school holidays. Five more generate test data that is structurally valid and belongs to nobody: BSN, IBAN, BRP person records, UPA pension files and document numbers. 14 render tools that return a hosted file. HTML or a live URL to PDF, full page screenshots, QR codes, PDF merge and split, images to PDF, image resize, convert and compress, metadata stripping, PDF to DOCX and back. Plus read_page, which returns the readable content of a JavaScript rendered page as Markdown. 4 memory tools give an agent key-value state that survives between sessions, scoped to its own API key. 3 workflow tools list and run saved multi-step workflows on the caller's account. 6 AI tools for the jobs where a model is the right instrument rather than the wrong one: check a message for scam patterns, write a spreadsheet formula, turn a question into SQL, translate code between languages, improve a prompt, draft an email. Utilities and memory are free. Renders and AI tools have a free tier and credit packs. Workflows need an API key, because a workflow belongs to an account rather than to a key. Streamable HTTP at https://toolforte.com/api/mcp
AI-assisted English lexical records. Stored-only batch lookup; coverage and quality vary.
Utility tools for AI agents: hashing, text stats, validation, DNS, currency, GEO audits.
Live web checks for AI agents: sitemaps, robots.txt, URL status, broken links, feeds, citations.