Skip to main content
Glama
joelbarmettlerUZH

wiktionary-de-mcp

by joelbarmettlerUZH
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

wiktionary-de-mcp

PyPI version Python versions CI License MCP

An MCP server that lets Claude (or any other MCP client) look things up in the German Wiktionary, de.wiktionary.org. Instead of answering from memory, Claude checks the dictionary itself and cites the entry.

It's useful when you want a reliable answer to questions like:

  • „Gibt es das Wort ‚verschlimmbessern'?"

  • "What's the gender and plural of ‚Band' in the sense of a music group?"

  • "Is it ‚gewinkt' or ‚gewunken'?"

  • "Conjugate ‚gehen' in Konjunktiv II."

  • "Does ‚laufen' take ‚haben' or ‚sein' in the perfect tense?"

No API key or account is needed.

Tools

Tool

What it does

lookup_word

Checks whether a word exists and returns its dictionary entry: part of speech, gender, inflected forms (plural and cases, comparative and superlative, principal verb forms, auxiliary verb), hyphenation, pronunciation (IPA), meanings, etymology, synonyms, antonyms and example sentences. Upper- and lower-case spellings are tried automatically (Laufen vs. laufen). If the word isn't in Wiktionary, the result says NOT FOUND and suggests similar entries.

get_inflection_table

The complete conjugation of a verb (every tense, mood and person, plus participles and the imperative), or the full declension of an adjective in the positive, comparative and superlative. For nouns it returns all case and number forms.

search_wiktionary

Searches titles and full text, with "did you mean" suggestions. Handy for misspellings or for finding compounds that contain a word stem.

get_raw_wikitext

The raw source of a page, for anything the other tools leave out (translations, references). Returns 8,000 characters at a time and can be narrowed to one section.

Entries are written in German, as on Wiktionary. The German Wiktionary also documents words from other languages, explained in German. Use lookup_word with language: "en" (or "Englisch", "French", "*" for all) to get those.

Related MCP server: Wikipedia MCP Server

Setup

You need uv installed. uv downloads and runs the server for you (via uvx), so there is nothing else to install.

Claude Desktop

Open Settings → Developer → Edit Config, or edit claude_desktop_config.json directly:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

Quit Claude Desktop completely before editing: use Quit from the menu bar or system tray icon, since closing the window leaves it running. The app saves its own preferences into the same file while it runs, so edits made while it's open can be overwritten.

Add the server, keeping any keys already in the file (such as preferences):

{
  "mcpServers": {
    "wiktionary-de": {
      "command": "uvx",
      "args": ["wiktionary-de-mcp"]
    }
  }
}

Restart Claude Desktop, then ask it something about a German word.

If Claude Desktop reports that it can't start the server, it usually can't find uvx. Desktop apps often don't see the PATH from your shell. Run which uvx (macOS, Linux) or where uvx (Windows) and put the full path in "command", for example "/Users/you/.local/bin/uvx".

If the server doesn't show up at all, check the MCP log: ~/Library/Logs/Claude/ on macOS, %APPDATA%\Claude\logs\ on Windows, ~/.config/Claude/logs/ on Linux. A line saying no stdio servers connected means the app didn't find an mcpServers entry in its config.

Claude Code

claude mcp add --scope user wiktionary-de -- uvx wiktionary-de-mcp

--scope user makes it available in every project. Leave it out to add it to the current project only.

Other MCP clients

Any client that supports stdio servers works. Configure the command uvx with the argument wiktionary-de-mcp. If you prefer pip, install with pip install wiktionary-de-mcp and use the command wiktionary-de-mcp.

Updating

uvx caches the package. To get a newer release, run uvx wiktionary-de-mcp@latest once, or pin a version in the config with "args": ["wiktionary-de-mcp@0.2.0"].

Good to know

  • Grammar is per word. Wiktionary records the grammar of individual words: gender, plural, cases, conjugation, auxiliary verb. It doesn't explain general rules such as when to use the dative or where commas go. Claude answers those from its own knowledge.

  • Wiktionary isn't exhaustive. Not finding a word doesn't prove it isn't German. Many valid compounds (Donaudampfschifffahrt) have no entry of their own.

  • Privacy. The server sends only the words you look up to the public Wikimedia API at de.wiktionary.org. Nothing else leaves your machine. Responses are cached in memory for 15 minutes.

Development

git clone https://github.com/joelbarmettlerUZH/wiktionary-mcp
cd wiktionary-mcp
uv sync
uv run pytest -m "not network"   # offline tests
uv run pytest                    # also runs live tests against de.wiktionary.org
npx @modelcontextprotocol/inspector uv run wiktionary-de-mcp   # try the tools interactively

To use your local checkout from Claude Desktop, use this server entry:

"wiktionary-de": {
  "command": "uv",
  "args": ["run", "--directory", "/path/to/wiktionary-mcp", "wiktionary-de-mcp"]
}

The code is small: server.py defines the tools, wikitext.py turns Wiktionary's page source into readable text, and client.py talks to the MediaWiki API.

Releasing

Every push to main runs release.yml. If the version in pyproject.toml isn't on PyPI yet, the workflow tests, builds and publishes the package with Trusted Publishing (no stored token). It then creates a matching vX.Y.Z GitHub release. If that version is already on PyPI, it does nothing. To release:

uv version --bump patch   # or minor / major; updates pyproject.toml and uv.lock
git commit -am "Release vX.Y.Z" && git push

License

The code is licensed under the Apache License 2.0. Dictionary content returned by the tools comes from Wiktionary contributors and is licensed under CC BY-SA 4.0.

Available Tools

4 tools
get_inflection_tableGet conjugation/declension tableA
Read-onlyIdempotent

Return the complete inflection table for a German word.

For verbs this is the full conjugation (all tenses, moods, persons, participles,
imperative); for adjectives the full strong/weak/mixed declension of the positive,
comparative and superlative. Both come from the page "Flexion:<word>". Nouns
usually have no such page; for them this returns the case and number forms
listed on the entry itself.
ParametersJSON Schema
NameRequiredDescriptionDefault
wordYesThe lemma (dictionary form), e.g. 'laufen', 'gehen', 'Haus'.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and open-world behavior, so the bar is lower. The description adds useful behavioral context: data comes from the 'Flexion:<word>' page, and nouns usually lack that page so the tool falls back to forms listed on the entry itself. It does not explain what happens if a verb or adjective page is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and compact: purpose first, then the per-part-of-speech behavior, then the noun fallback. Every sentence carries specific information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety behavior and an output schema covering return structure, the description supplies the remaining necessary context: language, scope by part of speech, source page, and noun fallback. An agent has enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single 'word' parameter, which the schema already documents as the lemma/dictionary form with examples. The description adds no further parameter meaning beyond that baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Return the complete inflection table for a German word.' It then precisely scopes what that means for verbs, adjectives, and nouns. This makes it readily distinguishable from lookup_word and get_raw_wikitext 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining what content is returned and for which parts of speech, but it never explicitly says when to use this tool instead of lookup_word or get_raw_wikitext. There are no exclusions or alternative-tool routing instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_raw_wikitextGet raw wikitextA
Read-onlyIdempotent

Return the unprocessed wikitext source of a de.wiktionary.org page.

Use only when lookup_word omits something you need (e.g. translations,
references). Pages can be very long (100k+ characters), so prefer `section`
and page through with `offset` when the result says it was truncated.
ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesExact page title (case-sensitive), e.g. 'Haus' or 'Flexion:gehen'.
offsetNoCharacter offset to start from, for paging through long pages.
sectionNoOnly return the part of the page under the first heading or section marker containing this text, e.g. 'Übersetzungen', 'Referenzen', 'Englisch'. Omit for the whole page.
max_charsNoMaximum characters to return.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful operational behavior: pages can exceed 100k characters, results may indicate truncation, and paging via `section` and `offset` is recommended. It does not add auth or rate-limit details, but the annotations lower the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly written sentences. The core purpose is front-loaded, the usage restriction follows immediately, and the paging advice is placed last where it belongs. No sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers when to use the tool, its relationship to lookup_word, and how to handle long/truncated results. With full schema descriptions, annotations, and an output schema present, no additional detail is required for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline would be 3 even without description help. The description still adds strategic meaning by explaining when and how to use `section` and `offset` for long pages. It does not elaborate on `title` or `max_chars`, but the schema already documents those fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Return the unprocessed wikitext source of a de.wiktionary.org page.' It clearly distinguishes itself from lookup_word by specifying raw source output. An agent can identify this as the low-level wikitext access tool 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this only when lookup_word omits needed content such as translations or references, naming the sibling alternative and the condition for switching. It also gives practical guidance to prefer `section` and page with `offset` when truncation occurs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_wordLook up a wordA
Read-onlyIdempotent

Check whether a word exists in the German Wiktionary and return its dictionary entry.

Returns part of speech, grammatical forms (gender, plural, cases, comparison,
verb principal parts, auxiliary verb), hyphenation, IPA, meanings, etymology,
synonyms, antonyms and example sentences, all in German. The German Wiktionary
also has entries for words of other languages (explained in German); select
them with `language`. If the word does not exist the result starts with
"NOT FOUND" and lists similar entries.
ParametersJSON Schema
NameRequiredDescriptionDefault
fullNoReturn every line of every section instead of a compact summary.
wordYesThe word to look up, e.g. 'Haus', 'laufen', 'schön'.
languageNoWhich language's entry to return. Accepts German names as used on Wiktionary ('Deutsch', 'Englisch'), English names ('German', 'English') or ISO codes ('de', 'en'). Use '*' for all languages.Deutsch

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description adds real behavioral context beyond them: the entry content is in German, the field set returned, and critically the failure mode ('NOT FOUND' prefix with similar entries listed). Rate limits or caching behavior are not mentioned, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in one sentence, followed by return contents, language behavior, and the not-found case in a logical order with no filler. The enumerated return-field list is somewhat redundant given an output schema exists, which costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not restate return values, yet it covers the non-obvious parts an agent needs: German-language output, the language-selection nuance, and the NOT FOUND sentinel. Only the `full` parameter's effect on output volume goes unmentioned in prose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents `word`, `language`, and `full`, making 3 the baseline. The description adds a useful nuance about `language` (foreign words get German-language explanations, selectable by language), but says nothing about `full`, so it does not clearly exceed the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ('Check whether a word exists in the German Wiktionary and return its dictionary entry'), which is precise and immediately actionable. It is implicitly distinguishable from siblings like search_wiktionary, but no sibling is named or contrasted, so it falls short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: single-word lookup is the obvious use case, and the description notes that foreign-language entries exist and are selected via `language`. However, it never says when to prefer this over search_wiktionary or get_inflection_table, nor any prerequisites, so the agent must infer the boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_wiktionarySearch the German WiktionaryA
Read-onlyIdempotent

Full-text and prefix search over de.wiktionary.org entries.

Useful for finding the correct spelling of a word, compounds that contain a stem,
or entries when lookup_word returns NOT FOUND.
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results.
queryYesSearch text. Matches titles and page content, e.g. a misspelled word or a word stem.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the description only needs to add context. It does add the meaningful behavioral detail that matching works both as full-text and prefix search, which is not in the annotations, though it says nothing about result ranking or pagination 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the capability statement front-loaded and the routing guidance second. Every clause carries information an agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, annotations declare the read-only/idempotent/open-world profile, and parameter semantics are fully covered by the schema. Nothing needed to invoke the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% – both query and limit are documented in the schema itself, including that query matches titles and page content. The description adds no parameter-level detail beyond that, which is the correct baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search) and resource (de.wiktionary.org entries) with the search mode (full-text and prefix) called out. It is clearly distinguishable from lookup_word, which it names explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives three concrete use cases (correct spelling, compounds containing a stem) and an explicit routing rule: use this when lookup_word returns NOT FOUND. The agent knows exactly when to prefer it over the exact-lookup sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.1
    • First observedget_inflection_table
    • First observedget_raw_wikitext
    • First observedlookup_word
    • First observedsearch_wiktionary
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation4/5

Each tool targets a distinct retrieval need: processed dictionary entry, search, raw wikitext, and inflection tables. Some overlap exists because lookup_word already returns grammatical forms and raw wikitext can duplicate lookup content, but the descriptions clarify when to use each.

Naming Consistency5/5

All tool names use snake_case with a predictable verb_noun pattern (lookup_word, search_wiktionary, get_raw_wikitext, get_inflection_table). The mix of lookup, search, and get verbs is natural and consistent.

Tool Count5/5

Four tools is well-scoped for a focused German Wiktionary server; each tool covers a distinct access pattern and none feels redundant or out of place. The count sits comfortably within the typical 3-15 range.

Completeness4/5

The surface covers core dictionary workflows: lookup, search, raw wikitext fallback, and inflection tables. Minor gaps exist, such as no dedicated translation lookup, but agents can work around these using get_raw_wikitext.

Maintenance

ActivityNo data
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers