Skip to main content
Glama
ctjmaxwell

Anki Flashcard MCP

by ctjmaxwell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Anki Flashcard MCP Server 🃏

Project Overview 🚀

This project provides a Dockerized Model Context Protocol (MCP) server specifically designed to work with the Anki desktop application. By leveraging the anki-flashcard-mcp server, you can use a large language model (LLM), such as Claude, to automatically generate flashcards and sync them with your Anki decks.

Related MCP server: MCP-AnkiConnect

Prerequisites ✅

Before you get started, please make sure you have the following installed:

  • Docker: The containerization platform. 🐳

  • uv: A fast Python package installer and bundler (recommended for development).

  • AnkiConnect Add-on: This Anki add-on is required to allow the server to communicate with your Anki application. In Anki, go to Tools > Add-ons > Get Add-ons... and enter the code 2055492159.

  • Anki Desktop: The Anki application must be open and running for the server to work. 💡

Development Setup (Optional) ⚙️

If you plan to develop or modify the server, you can set it up locally using uv.

  1. Initialize the project:

uvx create-mcp-server anki-flashcard-mcp
cd anki-flashcard-mcp

  1. Install dependencies and run the server:

uv sync --dev --all-extras
uv run my-server

Running with Docker 📦

This is the recommended way to use the server.

  1. Build the Docker image:

docker build -t anki-flashcard-mcp .

This command builds the Docker image and tags it as anki-flashcard-mcp.

  1. Test the server (optional): You can test the container using the MCP inspector tool to ensure it's running correctly.

npx @modelcontextprotocol/inspector docker run -i --rm --init -e DOCKER_CONTAINER=true anki-flashcard-mcp

This command will run the inspector, which lets you test prompts and tools to verify the container's output.

Using with the Claude App 🤖

Follow these steps to integrate the Dockerized server with the Claude desktop application.

  1. Enable Docker access for Claude: Sometimes, Claude doesn't have the necessary shell environment variables to access Docker. Run the following command in your terminal to fix this:

launchctl setenv PATH "$PATH"

  1. Configure Claude Desktop:

    • Open the Claude app and navigate to Settings > Developer.

    • Find the Local MCP Servers section and click Edit Config.

    • This will open claude_desktop_config.json. Add the following configuration to the JSON file:

{
  "mcpServers": {
    "anki-flashcard-mcp": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--init",
        "-e",
        "DOCKER_CONTAINER=true",
        "anki-flashcard-mcp"
      ]
    }
  }
}

  1. Troubleshooting - Wrapper Script (if direct config fails): ⚠️ If the direct configuration doesn't work, you can use a shell script as a stable entry point.

    • Create a new script file, for example: /Users/cademaxwell/.scripts/run-anki-docker.sh

#!/bin/bash
exec /usr/local/bin/docker run -i --rm --init -e DOCKER_CONTAINER=true anki-flashcard-mcp

  • Make the script executable:

chmod +x ~/.scripts/run-anki-docker.sh

  • Note: Replace /usr/local/bin/docker with the actual path to your Docker executable (you can find this by running which docker).

  • Update the claude_desktop_config.json to point to the new script:

{
  "mcpServers": {
    "anki-flashcard-mcp": {
      "command": "/Users/cademaxwell/.scripts/run-anki-docker.sh"
    }
  }
}

Your Dockerized MCP server is now ready to be used by Claude! Each time you open the Claude desktop app, a new Docker container will start for the anki-flashcard-mcp image.

Available Tools

2 tools
add_anki_noteC
    Adds a SINGLE Anki note. Use this for adding one card at a time.

    :param deck: The name of the deck to add the note to.
    :param front: The content for the front of the card.
    :param back: The content for the back of the card.
    :param tags: A list of tags to add to the note.
ParametersJSON Schema
NameRequiredDescriptionDefault
backYes
deckYes
tagsNo
frontYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. As a mutation tool adding notes, it doesn't disclose what happens on success/failure, whether duplicates are allowed, deck creation behavior, or Anki connectivity requirements. Very little behavioral context beyond the bare operation.

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?

The description is compact and front-loaded with the core purpose in the first line. The parameter list uses a clean :param format. One could argue it's slightly over-formatted with whitespace, but it's reasonably efficient.

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

Completeness2/5

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

This is a mutation tool with no annotations and no output schema. With 0% schema description coverage, the tool relies entirely on this description, which lacks important details: error handling, duplicate behavior, tag format requirements, and return value. Incomplete for a tool with 4 parameters including a complex array type.

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

Parameters2/5

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

Schema coverage is 0%, so description must compensate. It lists parameters (deck, front, back, tags) but only with terse one-liners that essentially restate the parameter names without adding meaning. No examples, no format requirements for tags or deck names, no size limits for front/back content.

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 description states it 'Adds a SINGLE Anki note' with a specific verb+resource. It distinguishes from the sibling add_multiple_anki_notes by emphasizing 'SINGLE' and 'Use this for adding one card at a time,' though it doesn't explicitly name the sibling.

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 context ('one card at a time') which provides implicit distinction from the multi-add sibling. However, it doesn't explicitly say when NOT to use this tool or name the alternative tool add_multiple_anki_notes directly.

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

add_multiple_anki_notesB
    Adds a BATCH of multiple Anki notes in a single, efficient operation. Use this for adding more than one card at once.

    :param deck: The name of the deck to add the notes to.
    :param notes: A list of notes to add. Each note should be a dictionary with "Front" and "Back" keys.
    :param tags: A list of tags to add to every note in the batch.
ParametersJSON Schema
NameRequiredDescriptionDefault
deckYes
tagsNo
notesYes

TDQS

B3.3/5.0
Behavior2/5

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

There are no annotations provided, so the description carries the full burden of behavioral disclosure. It claims efficiency but doesn't describe edge behaviors: what happens on partial failure, duplicate detection, whether notes are validated, or what gets returned. For a batch mutation tool with zero annotation coverage, this is a significant transparency gap.

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?

The description is compact with three focused param sections and a clear purpose statement up front. No wasted sentences, though the docstring format adds some formatting noise.

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

Completeness3/5

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

For a 3-param batch operation, the description covers the parameters and usage intent well, but with no output schema and no annotations, it should disclose what the batch operation returns (e.g., note IDs, error report) and how failures are handled. This is a moderate gap for a batch mutation tool.

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 0%, so the description must compensate and does so well. It explains that each note dictionary should contain 'Front' and 'Back' keys and that tags apply to 'every note in the batch' — meaning beyond the bare schema definition of notes as opaque objects.

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 description clearly states verb+resource: adds a BATCH of multiple Anki notes. It distinguishes from the sibling by emphasizing 'single efficient operation' and 'more than one card at once', which differentiates it from add_anki_note.

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 says 'Use this for adding more than one card at once', which gives clear usage context and implicitly contrasts with the single-note sibling tool. However, it doesn't explicitly state when NOT to use it or mention any alternative for adding a single card.

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. 2 tool updatesv0.1.0
    • First observedadd_anki_note
    • First observedadd_multiple_anki_notes
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

C2.7/5.0

Scored across 2 tools

Disambiguation3/5

The two tools are clearly distinguished by single vs. batch operation, and the descriptions explicitly state when to use each. However, there is still some ambiguity since both serve the same fundamental purpose (adding notes to a deck), and an agent might reasonably pick either for a single-note add when the batch tool would also work.

Naming Consistency3/5

Both tools follow a verb_noun style with 'add' as the verb, which is consistent. However, the naming is somewhat redundant ('add_anki_note' vs 'add_multiple_anki_notes') rather than a clean noun-based pattern like 'create_note' and 'create_notes', and the repetition of 'anki' in both is verbose.

Tool Count1/5

Only two tools exist, and they cover only the 'add' operation. For a flashcard MCP server, this is extremely thin — there are no tools to retrieve, update, delete, search, or review notes or decks. A server this narrow is difficult to justify as useful for real workflows.

Completeness1/5

The surface only supports adding notes. There are no get/update/delete operations for notes, no deck management, no card review/study operations, and no search capability. This is a severely incomplete surface for managing Anki flashcards and will cause agents to hit dead ends immediately after adding content.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Clanki

    jasperket
    A
    license
    A
    quality
    B
    maintenance
    An MCP server that enables AI assistants like Claude to interact with Anki flashcard decks, allowing users to create, manage, and update flashcards through natural language conversations.
    9
    42
    MIT

  • TalkToAnki

    muxuuu
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables AI assistants to seamlessly manage Anki flashcards, decks, and templates through the AnkiConnect API. It supports intelligent querying, batch note creation, and detailed study progress analysis using natural language.
    4
    MIT

  • anki-mcp

    hbd
    F
    license
    A
    quality
    D
    maintenance
    An MCP server that enables Claude Code to create, manage, and search Anki flashcards directly from the terminal. It supports batch card creation, deck statistics retrieval, and synchronization with AnkiWeb for cross-platform review.
    8
    -