Anki MCP Server gives an assistant 53 tools, and the addon gives you the same server inside Anki

Two distributions of one server, and the project tells you which to use

The most important thing in this README is the Important note at the top, because it changes which of two things you should install.

The recommendation is to prefer the AnkiMCP addon for most setups. The addon runs the MCP server directly inside Anki, so there is no Node.js to install, no AnkiConnect to configure, and no separate process to keep running. You install it with the code 124672614, restart Anki, and the server is up every time Anki opens. It covers local HTTP access and remote access through a built-in tunnel.

This repository is the right choice when you specifically need STDIO transport, meaning Claude Desktop, Claude Code, Cursor or any client that spawns the server as a subprocess, or the MCPB bundle, which is the one-click.mcpb install for Claude Desktop.

For HTTP, tunnel or web-based clients, the addon is described as the simpler and better-supported path.

And the project is explicit that this repository is not being deprecated. It stays maintained and released alongside the addon as part of the same ankimcp.ai project, and the recent releases are v0.27.0 from 2026-10-04, v0.26.0 from 2026-09-18 and v0.25.1 from 2026-09-09, with the last push to the repository on 2026-10-11.

So this is a fork in distribution rather than a fork in capability. The same server, reachable two ways, and the choice is about how the assistant connects to it.

Fifty-three tools, split between the data model and the desktop UI

The server exposes 53 MCP tools, described as 42 essential tools for everyday Anki operations and 11 GUI tools that drive the Anki desktop interface for note editing and creation workflows.

The essential tools fall into groups that mirror how Anki itself is organised. Review and study covers sync with AnkiWeb, get_due_cards and get_cards for querying by state and deck, present_card to show a card, and rate_card to record a rating of Again, Hard, Good or Easy and schedule the next review. Then the schedule-management tools: forgetCards to reset cards to new and discard their scheduling without recording a review, setDueDate to reschedule cards to become due in N days, areSuspended to check suspension state, and suspend and unsuspend.

Deck management has listDecks, deckStats, createDeck supporting Parent::Child with a maximum of two levels, and changeDeck. Note management has addNote, addNotes for batch creation of up to 100 notes sharing a deck and model with partial success supported, findNotes using Anki query syntax such as deck:, tag: and is:due, notesInfo, and updateNoteFields.

The GUI tools are the differentiator. They cover things like guiSelectedNotes for reading the currently selected note from the browser, which is what makes the third example flow work: upload a local file with storeMediaFile, read the selected note, and update the front field with an img tag.

That combination is the reason to care about this server rather than a generic Anki script. It is not just a note store, it is a driver for the application, which is why the tool count is in the fifties rather than single digits.

The distinction that matters most: rating a card versus moving its schedule

Two of the notes in the tool list carry the most practical warning for anyone letting an assistant touch a real collection.

forgetCards and setDueDate change scheduling without logging a review, and that is what separates them from rate_card. The guidance is to reach for them when a card's schedule is wrong rather than the answer.

The reason given is specific and important. Rating a card Again to bury it deeper records a real lapse and drops its ease factor, permanently skewing both future scheduling and your statistics. forgetCards wipes the interval and starts the card over, and setDueDate keeps the card's history and just moves the next review.

That is a design point worth internalising before pointing any assistant at a collection you care about. A scheduling mistake is recoverable in a way that a false lapse is not, and an assistant that reaches for rate_card when it should reach for setDueDate will quietly damage your scheduler.

The other note is about rendering. Card front and back content is rendered per card from its own template, as Anki shows it, so reversed and cloze cards display the correct direction, and static text added by your card templates appears in the output as well.

That second note matters because it tells you the server is not returning raw field text. It is returning what the user would see, which is the right behaviour for an assistant that is supposed to quiz you, and a behaviour you should know about if you are parsing the output yourself.

Two flavours of deck statistics, and why they disagree

There is a similar trap in the deck statistics, and the documentation is unusually clear about it.

The counts block, and everything listDecks reports, mirrors Anki's own deck browser. Cards are counted as due today, capped by each deck's daily new and review limits, with suspended and buried cards excluded. The consequence is that review is not the same as mature cards, and the other bucket is just the arithmetic remainder, mostly review cards not due today plus new cards over the daily limit.

For true per-state totals you use the states block on deckStats or collection_stats, which counts new, learning, review, suspended and buried via Anki searches, ignoring due dates and daily limits.

So the same server can tell you two different numbers for a deck, and both are correct. The counts block answers how much work is waiting for me today, and the states block answers how many cards are in each state. An assistant that conflates them will tell you a deck has 40 review cards when it has 400, because 360 of them are not due today.

The other deck-related details are small but worth knowing. createDeck supports a Parent::Child path with a maximum of two levels, and changeDeck moves cards to a different deck and creates it if it does not exist.

What the server actually does with a study session

The three example prompts in the documentation show the intended interaction, and they are the best short description of the tool set.

The first is asking for help reviewing a Spanish deck. The assistant offers to sync with AnkiWeb using sync, fetches due cards with get_due_cards and a deck filter, presents each card with present_card, and records the rating with rate_card. The documentation calls it a natural study conversation with explanations tailored to you.

The second asks for ten Arabic vocabulary cards with right-to-left styling. The assistant lists the note types with modelNames, creates a custom right-to-left model if needed using createModel and updateModelStyling for the CSS, and then batch-creates the cards with addNotes.

The third asks to import an image from the Downloads folder into the front of the selected note. The assistant uploads the local file with storeMediaFile and a file path, reads the currently-selected note from the browser with guiSelectedNotes and notesInfo, and updates the front field with an img tag through updateNoteFields.

Those three flows use disjoint parts of the tool set, which is the point. Reviewing a deck, authoring a deck in a script you cannot type, and editing a note in the desktop app are three different problems, and the tool list covers all three.

Note the answers are omitted by default. get_due_cards and get_cards both omit answers unless you pass include_answer: true, with the default being false. That is a deliberate design choice, because a quiz that leaks the answer is not a quiz, and an assistant that has already seen the back of the card cannot unsee it.

Installing it: the addon for most people, this package for STDIO

For the addon route, the installation is the Anki shared code, and the code is 124672614. The addon runs the server inside Anki, there is no Node.js to install and no AnkiConnect to configure, and you restart Anki and the server is available every time Anki opens.

For this repository, the package is published on npm as @ankimcp/anki-mcp-server at version 0.27.0, with two command names pointing at the same binary, ankimcp and anki-mcp-server.

The package exposes two command names pointing at the same binary.

  "bin": {
    "ankimcp": "bin/ankimcp.js",
    "anki-mcp-server": "bin/ankimcp.js"
  },

The project also ships an MCPB bundle for Claude Desktop, which the documentation describes as the one-click install, and a .mcpbignore file and a manifest.json at the repository root, which are the manifest and packaging rules for that bundle format.

The package is a NestJS application. The build is nest build, and there are separate entry points for the three transports, main-stdio, main-http and main-tunnel, with matching dev and production start scripts. The tests run under Jest with the experimental VM modules flag enabled, and the script sets are split into unit, tools and workflows suites, so the workflow-level tests live in a test/workflows directory and the tool tests live next to the tool implementations under src/mcp/primitives/essential/tools/__tests__.

The documentation site ankimcp.ai is where the comprehensive guides live, with the docs/ directory in the repository holding supplementary material such as the reviewer setup guide and a sample Anki deck.

Where this server is the wrong tool

Three cases, and they are about boundaries rather than defects.

The first is if you want the assistant to do the studying for you rather than help you study. The answers are omitted by default and the flows are built around a conversation in which you rate your own cards. An assistant that reviews on your behalf and rates everything Good would produce a collection whose statistics describe the assistant's confidence rather than yours, and the scheduling would drift away from what you actually know. The tool set includes rate_card because a human is meant to be in that loop.

The second is if your collection is large and you want summaries rather than interaction. The tools are card-level and note-level, and the documented examples are one session, one deck, one note at a time. Bulk operations exist, addNotes for up to 100 notes at once and findNotes with Anki query syntax, but the design assumes a conversational client rather than a batch pipeline over a collection.

The third is if you cannot accept the dependency picture. This repository is a Node server that talks to Anki over HTTP, and the documentation for the addon points at AnkiConnect for the standalone route. Running the server alongside Anki means two processes and a port to think about, which is exactly the friction the addon exists to remove.

One more caveat about the project's licensing. The licence is MIT, and the project distributes a sample Anki deck with the documentation. The cards in your own collection are yours, and a tool that can rewrite them deserves the same care you would give anything else that edits your data.

Editorial conclusion

Adopt the AnkiMCP addon if you want an assistant connected to Anki over HTTP or through a tunnel, because it runs inside Anki and needs no separate process. Do not adopt this standalone repository unless you specifically need STDIO transport or the MCPB bundle, since the project itself points you at the addon otherwise. Verify first which of the two you need before you install anything, and read the note about forgetCards and setDueDate before letting an assistant reschedule your collection.

Frequently asked questions

Official sources

1. ankimcp/anki-mcp-server on GitHub
2. License: MIT
3. Project website
4. README
5. Releases