Provides tools for managing Anki decks and cards, including creating decks, adding basic and cloze cards, batch card operations, and retrieving review queues through the Anki API.
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 MCP Server add a basic card to my Spanish deck with front 'hola' and back 'hello'"
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.
An MCP (Model Context Protocol) server that provides tools for interacting with the Anki API. This server allows AI assistants to manage Anki decks and cards through simple tool calls.
List Anki decks with pagination
Create new decks
Add cards (basic and cloze types)
Batch add multiple cards
Get review queue with filtering options
Support for dynamically loading additional tools from an external API
Related MCP server: Anki MCP Server
listDecks - List all Anki decks with optional pagination
createDeck - Create a new Anki deck
addCardsBatch - Add multiple cards to a deck in batch
addBasicCard - Add a single basic card to a deck
addClozeCard - Add a cloze deletion card to a deck
getReviewQueue - Get cards due for review with filtering options
npm install -g @x-mcp/anki
# or
pnpm add -g @x-mcp/anki# Install dependencies
pnpm install
# Build the project
pnpm run build
# Run in development mode (auto-restart on changes)
pnpm run dev
# Run the server
pnpm start
# Lint and format code
pnpm run lint
pnpm run formatAdd this to your MCP client settings:
{
"mcpServers": {
"anki-mcp": {
"command": "npx",
"args": ["-y", "@x-mcp/anki@latest"],
"env": {
"ANKI_BASE_URL": "http://localhost:3000", // Anki API base URL
"ANKI_API_KEY": "ank_YOUR_API_KEY_HERE" // Your Anki API key
}
}
}
}Create a .env file:
# Required: Anki API configuration
ANKI_BASE_URL=http://localhost:3000/api/v1
ANKI_API_KEY=ank_YOUR_API_KEY_HERE
# Optional: External tools API configuration
API_URL=https://your-api-endpoint.com/tools
API_KEY=your-api-keyOnce configured, the AI assistant can use commands like:
"List all my Anki decks"
"Create a new deck called 'Spanish Vocabulary'"
"Add a card with front 'Hello' and back 'Hola' to my Spanish deck"
"Show me cards due for review"
Each tool makes direct HTTP requests to the Anki API and returns the response data.
The tools interact with an Anki API that should have the following endpoints:
GET /api/v1/decks - List decks
POST /api/v1/decks - Create deck
POST /api/v1/decks/{deckId}/cards/batch - Add cards
GET /api/v1/study/queue - Get review queue
MIT
Add a single basic card to a deck
| Name | Required | Description | Default |
|---|---|---|---|
| back | Yes | Back side of the card | |
| tags | No | Tags for the card | |
| front | Yes | Front side of the card | |
| deckId | Yes | ID of the deck to add card to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'add', implying creation, but does not discuss idempotency, duplicate handling, authorization, or side effects.
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 short sentence, which is concise and waste-free. However, it lacks structure or front-loading of key information for a quick read.
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 has 4 input parameters (all described in schema), no output schema, and siblings, the description is minimal. It does not explain what constitutes a 'basic card', whether the operation is reversible, or behavior for conflicting tags.
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%, so the schema already documents all parameters. The description does not add any extra meaning beyond the schema, so a baseline score of 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 clearly states the verb 'add', the resource 'basic card', and the target 'deck'. It distinguishes itself from siblings like addCardsBatch (batch) and addClozeCard (different type).
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 on when to use this tool versus alternatives such as addCardsBatch or addClozeCard. The description does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add multiple cards to a deck in batch
| Name | Required | Description | Default |
|---|---|---|---|
| cards | Yes | Array of cards to add | |
| deckId | Yes | ID of the deck to add cards to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Add multiple cards' without disclosing atomicity, error handling, or validation behavior for batch operations.
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, front-loaded sentence. It is concise but perhaps too terse, missing useful context without being verbose.
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 batch complexity and absence of output schema, the description is incomplete. It does not explain the return value or how to handle partial failures, which is critical for 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 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it does not clarify order or partial failure semantics.
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 verb 'Add', the resource 'cards', and the mode 'batch'. It effectively distinguishes from sibling tools like addBasicCard and addClozeCard, which handle single cards.
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 provided on when to use this batch tool versus single-card alternatives, nor any mention of batch size limits or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a cloze deletion card to a deck
| Name | Required | Description | Default |
|---|---|---|---|
| back | Yes | Back side of the card | |
| tags | No | Tags for the card | |
| front | Yes | Front side of the card | |
| deckId | Yes | ID of the deck to add card to | |
| clozeText | Yes | Cloze text with {{c1::text}} format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states 'add', implying creation, but omits critical details like whether duplicates are checked, required permissions, or what happens if the deck doesn't exist. This lack of transparency is a significant gap.
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?
A single, succinct sentence communicates the core purpose without any superfluous words. It is front-loaded and efficient.
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 has 5 parameters, no output schema, and no annotations. The description does not explain the relationship between front, back, and clozeText (e.g., whether front/back are derived or static). It also fails to mention return value or side effects, leaving the agent underinformed for proper invocation.
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%, so each parameter has a description in the schema. The tool's description adds no extra parameter information beyond what the schema already provides. Baseline score of 3 is appropriate here.
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 action ('Add'), the resource ('cloze deletion card'), and the destination ('to a deck'). It effectively distinguishes from siblings like addBasicCard (adds a different card type) and addCardsBatch (batch operation).
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 provided on when to use this tool versus alternatives like addBasicCard or addCardsBatch. The agent is left to infer usage context from the name alone, which is insufficient for choosing correctly among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Anki deck
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the deck | |
| isPublic | No | Whether the deck should be public | |
| description | Yes | Description of the deck |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavior but only states creation. Does not mention side effects (e.g., duplicate handling, permissions, or irreversible actions).
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?
Single, concise sentence with no wasted words. Perfectly 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?
No output schema or behavioral context. Missing details on success/error outcomes, validation rules, or default values for optional parameter isPublic.
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%, so description does not need to explain parameters. Schema descriptions already document each parameter adequately.
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 verb 'Create' and specific resource 'Anki deck', which is distinct from sibling tools focused on cards and reviewing. No ambiguity.
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 on when to use this tool versus alternatives like listDecks or addBasicCard. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cards due for review with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of cards to return | |
| deckId | No | Optional deck ID to filter cards | |
| includeNew | No | Include new cards | |
| includeReview | No | Include review cards | |
| includeLearning | No | Include learning cards |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like idempotency, side effects, or rate limits. It only implies a read operation without explicit confirmation.
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 sentence with no unnecessary words. It is concise and front-loaded with the main action and resource.
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 5 optional parameters and no output schema, the description lacks details about return format, pagination, or behavior when no parameters are provided. It is too minimal to fully inform an agent.
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%, so the schema already describes all parameters. The description adds 'filtering options' but provides no additional semantic value beyond what the schema offers.
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 verb 'Get' and the resource 'cards due for review', and mentions 'filtering options', which distinguishes it from sibling tools that create cards or list decks.
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?
There is no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites mentioned. The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Anki decks with optional pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of decks to return | |
| offset | No | Number of decks to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states basic functionality without disclosing side effects, auth needs, or other behavioral traits beyond listing decks.
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, front-loaded with key info, with no unnecessary words.
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 list tool with no output schema, the description is adequate but could mention expected return format or default pagination behavior.
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%, so baseline is 3. The description adds 'optional pagination' but doesn't provide parameter-specific details like defaults or bounds.
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 action (list) and resource (all Anki decks), and distinguishes it from sibling tools that add cards or create decks.
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 pagination use but provides no explicit guidance on when to use this tool vs alternatives or when not to use it.
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.
addBasicCardaddCardsBatchaddClozeCardcreateDeckgetReviewQueuelistDecksScored across 6 tools
Tools are mostly distinct: addBasicCard, addClozeCard, and addCardsBatch target different card types or batch operations; createDeck, listDecks, and getReviewQueue are clearly separate. However, addCardsBatch could overlap with addBasicCard or addClozeCard if used for multiple cards of a specific type.
All tools follow a verb_noun pattern with imperative verbs (add, create, get, list). Minor inconsistencies: 'CardsBatch' uses plural and compound noun, while others use singular (BasicCard, ClozeCard). Capitalization is consistent with CamelCase.
With 6 tools, the server is well-scoped for basic Anki operations: deck creation, card addition (basic, cloze, batch), deck listing, and review queue retrieval. The number is appropriate for a focused subset.
Significant gaps exist: no update or delete operations for cards or decks, no ability to list cards within a deck, and no support for managing models or tags. Agents can create and add but cannot modify or remove content.
Build and study spaced-repetition flashcards with your agent.
Spaced-repetition flashcards your AI writes, quizzes you on by voice, and schedules with FSRS.
AI-powered YouTube to flashcards with spaced repetition and Anki export
List and create Manthan concept-card decks from an AI agent — no AI quota spent for imports.
