Enables adding monolingual dictionary lookup results as Anki flashcards, including definitions, IPA phonetics, audio URLs, and verb forms, via the MultiDefine note types and anki-mcp-server.
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., "@Anki MultiDefine MCP Look up 'Haus' in German and add it to my Anki deck."
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.
Tell Claude to add a word to Anki. It looks it up in a real monolingual dictionary, formats the card, downloads audio, and creates the note — all in one message.
"Add a card for 'Schadenfreude' to my German deck."Works for English, German, Russian, French, and Azerbaijani. Definitions come from Oxford, DWDS, Wiktionary, and Larousse — the same sources the MultiDefine Anki add-on uses.
Requirement | Notes |
Anki desktop app | Free, runs locally |
AnkiConnect add-on | Lets Claude talk to Anki |
MultiDefine add-on | Provides the note types Claude writes to |
Runs this server — no separate install step needed | |
The AI client |
Related MCP server: Cambridge Dictionary MCP Server
Download anki-multidefine-mcp.mcpb
Open Claude Desktop → Settings → Extensions → drag the file in (or use Install Extension and select it)
Claude Desktop installs the server automatically
You still need to install the Anki add-ons (Step 2 below) and the Anki MCP server.
# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | shOr via Homebrew: brew install uv
Open Anki → Tools → Add-ons → Get Add-ons and enter:
2055492827That installs AnkiConnect. Then install MultiDefine:
Download multidefine.ankiaddon
In Anki: Tools → Add-ons → Install from file → select the downloaded file
Restart Anki after both are installed.
Open (or create) this file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Paste the following (merge with any existing mcpServers block if you have one):
{
"mcpServers": {
"anki-multidefine": {
"command": "uvx",
"args": ["anki-multidefine-mcp"]
},
"anki-mcp": {
"command": "npx",
"args": ["-y", "@ankimcp/anki-mcp-server", "--stdio"],
"env": {
"ANKI_CONNECT_URL": "http://localhost:8765"
}
}
}
}Keep Anki open — AnkiConnect only responds while Anki is running.
Copy any of these directly into Claude:
Add a card for "Haus" to my German deck.Look up "schadenfreude" in English and add it to my Vocabulary deck.Add cards for these Russian words to my Russian deck: уважение, доверие, свобода.What German words have I added in the last week?When you ask Claude to add a word, it:
Calls define(word, language) — looks up the word in the monolingual dictionary
Reads multidefine://schema — knows exactly which Anki fields to fill and how
Calls findNotes — skips the card if it already exists in the deck
Calls storeMediaFile with the audio URL — downloads pronunciation into Anki's media folder
Calls addNote with the MultiDefine_{Language} note type — card appears in your deck
No UI to learn. No form to fill. Just describe what you want.
Key | Dictionary | Audio | IPA | Verb forms |
| Oxford Learner's | Yes | Yes | Yes |
| DWDS | Yes | Yes | Yes |
| ru.Wiktionary | Yes | Yes | — |
| Larousse | Yes | — | — |
| AZLEKS | — | — | — |
Claude infers the language from context — you rarely need to specify the key explicitly.
Claude says it can't connect to Anki — Anki must be open and AnkiConnect installed. Verify by visiting http://localhost:8765 in your browser; you should see a plain-text AnkiConnect response.
"Note type not found" — MultiDefine must be installed in Anki so the MultiDefine_German (etc.) note types exist. Check via Tools → Manage Note Types.
"Word not found" — The word isn't in that dictionary. Try a different spelling or language.
Duplicate card — Claude checks first and tells you if the card already exists. Ask it to update the existing note if you want.
uvx not found — Claude Desktop may not inherit your shell PATH. Use the full path: run which uvx in your terminal, then replace "uvx" in the config with that path (e.g. /Users/you/.local/bin/uvx).
Tool | Description |
| Look up a word. Returns definitions, IPA, audio URL, verb forms. |
| List supported language keys and their capabilities. |
Resource: multidefine://schema — field mapping and workflow rules Claude reads automatically before creating notes.
See AGENTS.md for the provider contract, word_info schema, and instructions for adding a new language.
See CONTRIBUTING.md for setup, smoke tests, and PR checklist.
License: GPL v2. providers/oxford.py is BSD 3-Clause (Near Huscarl).
Look up a word in a monolingual dictionary.
Returns structured word_info with definitions, examples, IPA, audio URL, and verb forms. Returns {"found": false} if the word is not in the dictionary. Raises ValueError for an unsupported language key (call languages() first).
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | ||
| language | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well by disclosing the return format (structured word_info, found:false) and error behavior (raises ValueError), which are behavioral traits beyond what the schema states. It misses minor details like rate limits or side effects, but for a read-only lookup tool, it is quite transparent.
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 concise and well-structured. It front-loads the main purpose, then returns details and error handling in separate sentences. Every sentence provides value, with no filler. It is appropriately sized for its complexity.
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 the tool's complexity (2 params, simple lookup, error handling), the description is fairly complete. It covers the return format, failure case, and an error condition that requires calling a sibling. It doesn't explain the output structure in detail, but no output schema exists, so a bit more detail on the return structure might be expected. However, it names the fields (definitions, examples, IPA, audio URL, verb forms), which is sufficient for most agents.
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 0%, so the description must compensate for parameter semantics. The description mentions 'unsupported language key' for the language parameter, implying it should be a valid language key, and implies the word is the lookup term. It adds semantic context, but doesn't detail the language key format or provide a list of valid values. Given the low coverage, this is adequate compensation.
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's purpose: 'Look up a word in a monolingual dictionary.' It specifies the resource (dictionary) and the action (look up), which is clear and distinguishes it from the sibling 'languages' tool. However, it does not explicitly contrast itself with the sibling, so it loses a point for lack of sibling differentiation.
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 usage by mentioning 'call languages() first' for language key validation, which hints at a prerequisite. However, it does not explicitly state when to use this tool vs alternatives or when not to use it, so it falls short of providing explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported languages and their capabilities (audio, IPA, verb forms).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does convey a read-style 'List' operation rather than a mutation. It does not state whether there are side effects, response details, or how 'capabilities' are represented.
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 tightly worded sentence with the action and the three content areas front-loaded. Every word earns its place and there is 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?
For a zero-parameter listing tool, naming the output categories (audio, IPA, verb forms) is largely sufficient. It stops short of describing the exact shape of the returned list or error behavior, but no additional input context is needed.
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 input schema is empty and coverage is 100%, so there are no parameter semantics for the description to add beyond the baseline for a zero-parameter tool. The description does not mislead about arguments.
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 uses a specific verb ('List') and names a concrete resource ('supported languages') plus salient capabilities, so an agent can tell what it does. It does not explicitly contrast itself with the sibling 'define', so it misses the strongest form of differentiation.
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?
No guidance is given about when to call this tool versus 'define' or any alternative. The word 'supported' implies a discovery/read use, but the conditions and alternatives are left entirely implied.
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.1.2definelanguagesScored across 2 tools
The two tools have completely distinct roles: define performs dictionary lookups, while languages provides supported-language metadata. There is no overlap in purpose, and the dependency between them is explicitly documented.
Both names are simple and lowercase, but they follow different grammatical patterns: define is a verb while languages is a bare resource noun. The inconsistency is minor and readable, but a prefix like list_languages would be more consistent.
Two tools is slightly thin by general MCP standards, but it is appropriate for a focused dictionary-lookup server. Each tool fills a necessary role: the core operation and the supporting metadata operation.
For the narrow domain of dictionary lookup, the surface is complete: define handles lookup with not-found handling, and languages enables callers to discover supported features before calling define. There are no obvious dead ends or missing lifecycle steps.
15 media & data tools for AI agents: search, transcribe, subtitles, voiceover, translate & more.
62 real-world tools for agents: search, scraping, social, enrichment, image, video, voice.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Exactly 50 data transformation and live web verification tools for AI agents.
