Skip to main content
Glama
htlin222

yanki-mcp-server

by htlin222
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

GitHub stars Last commit License

Yanki MCP Server ( Yet Another Anki MCP Server )

A Model Context Protocol server implementation that connects to a locally running Anki, providing card review and creation. This is a fork of scorzeth/anki-mcp-server with date-based organization features.

Available as an npm package: yanki-mcp-server

This server is designed to work with the Anki desktop app and the Anki-Connect add-on.

Make sure you have the add-on installed before using.

Resources

  • anki://search/deckcurrent

    • Returns all cards from current deck

    • Equivalent of deck:current in Anki

  • anki://search/isdue

    • Returns cards in review and learning waiting to be studied

    • Equivalent of is:due in Anki

  • anki://search/isnew

    • Returns all unseen cards

    • Equivalent of is:new in Anki

Related MCP server: Anki MCP Server

Tools

  • update_cards

    • Marks cards with given card IDs as answered and gives them an ease score between 1 (Again) and 4 (Easy)

    • Inputs:

      • answers (array): Array of objects with cardId (number) and ease (number) fields

  • add_card

    • Creates a new card in a date-structured deck (format: DECK::YYYY::MM::DD)

    • Inputs:

      • front (string): Front of card

      • back (string): Back of card

  • get_due_cards

    • Returns n number of cards currently due for review

    • Inputs:

      • num (number): Number of cards

  • get_new_cards

    • Returns n number of cards from new

    • Inputs:

      • num (number): Number of cards

Installation & Usage

You can use this package without installation via npx:

npx yanki-mcp-server

Or install it globally:

npm install -g yanki-mcp-server
yanki-server

Development

Clone the repository and install dependencies:

git clone https://github.com/htlin222/yanki-mcp-server.git
cd yanki-mcp-server
npm install

Build the server:

npm run build

For development with auto-rebuild:

npm run watch

Run the server directly during development:

npm run dev

Configuration

To use with Claude Desktop, add the server config:

On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json On Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "yanki-mcp-server": {
      "command": "npx",
      "args": ["yanki-mcp-server"],
      "env": {
        "DECK": "Default"
      }
    }
  }
}

Debugging

Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser.

Date-Based Card Organization

This server automatically organizes new cards using a date-based structure instead of traditional topic-based organization. When you create a new card, it's added to a deck with the following format:

DECK::YYYY::MM::DD

Where:

  • DECK is the base deck name (default: "00_Inbox" or configured via environment variable)

  • YYYY is the 4-digit year

  • MM is the 2-digit month

  • DD is the 2-digit day

Benefits of Date-Based Organization

  1. Effortless Organization: Cards are automatically organized by creation date without manual categorization

  2. Temporal Context: Review cards created during specific time periods (e.g., during a course or project)

  3. Natural Spaced Repetition: Cards naturally group by when you learned concepts

  4. Time-Efficient: No need to spend time deciding which category each card belongs to

  5. Historical Record: See your learning journey over time

Configuration

You can customize the base deck name by setting the DECK environment variable in your MCP server configuration:

"env": {
  "DECK": "YourCustomDeckName"
}

If not specified, it defaults to "00_Inbox".

Changelog

1.0.5 (2025-05-31)

  • Completely removed all console output and logging functionality

  • Simplified codebase by eliminating all non-essential output

  • Ensured 100% clean MCP protocol communication with no extraneous output

  • Removed all filesystem operations related to logging

1.0.4 (2025-05-31)

  • Fixed critical issue with logs directory path being created at filesystem root

  • Improved logging system with robust error handling and fallback mechanisms

  • Ensured logs are always created relative to the current working directory

  • Added silent failure for logging to prevent breaking MCP protocol if logging fails

1.0.3 (2025-05-31)

  • Fixed MCP communication protocol issue by redirecting all console output to log files

  • Added file-based logging system that preserves all debug and status information

  • Logs are stored in the logs directory with date-based filenames

  • Ensured clean stdout communication for proper MCP JSON-RPC protocol compliance

Available Tools

4 tools
add_cardA

Create a new flashcard in Anki for the user. Must use HTML formatting only. IMPORTANT FORMATTING RULES:

  1. Must use HTML tags for ALL formatting - NO markdown

  2. Use for ALL line breaks

  3. For code blocks, use with inline CSS styling

  4. Example formatting:

    • Line breaks:

    • Code:

    • Title: to tags

    • Lists: and tags

    • Bold:

    • Italic:

ParametersJSON Schema
NameRequiredDescriptionDefault
frontYesThe front of the card. Must use HTML formatting only.
backYesThe back of the card. Must use HTML formatting only.

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool creates a card and requires HTML formatting, with detailed rules. It does not mention other behavioral traits like side effects or auth, but the core behavior is clear.

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 front-loaded with the main purpose, then provides necessary detailed formatting rules. It is slightly lengthy but justified by the complexity of HTML formatting requirements.

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?

Given the simple two-parameter schema and no output schema, the description covers purpose, usage, and formatting details comprehensively, enabling correct tool invocation.

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

Parameters5/5

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

Schema description coverage is 100%, and the description adds meaning by reinforcing that both parameters must use HTML formatting, along with extensive formatting examples that go beyond the schema.

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 clearly states 'Create a new flashcard in Anki for the user.' with a specific verb and resource, and the sibling tools (get_due_cards, get_new_cards, update_cards) are distinct actions, making it easy to differentiate.

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

Usage Guidelines4/5

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

The description provides explicit formatting rules and states 'Must use HTML formatting only.' It implicitly indicates usage for creation but does not explicitly say when not to use or compare with siblings.

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

get_due_cardsB

Returns a given number (num) of cards due for review.

ParametersJSON Schema
NameRequiredDescriptionDefault
numYesNumber of due cards to get

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided. The description only states the function without disclosing behavioral traits such as order, caching, or side effects. Minimal transparency beyond purpose.

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 a single sentence, concise and direct. However, it could be slightly improved by including additional context without becoming verbose.

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?

No output schema, so the agent lacks information about the return format. The description does not mention ordering, limits, or defaults. For a data-retrieval tool, more completeness is needed.

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?

The schema already describes the parameter 'num' as 'Number of due cards to get'. The tool description does not add any extra meaning, such as constraints, defaults, or edge cases. Schema coverage is 100% but the description adds no value.

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 clearly specifies the tool returns cards due for review, with a parameter for count. It distinguishes from siblings like get_new_cards (new cards) and update_cards (updates), making the purpose unambiguous.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies usage for retrieving due cards but does not mention when not to use or provide comparisons to sibling tools.

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

get_new_cardsB

Returns a given number (num) of new and unseen cards.

ParametersJSON Schema
NameRequiredDescriptionDefault
numYesNumber of new cards to get

TDQS

B3.2/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 the full burden of disclosing behavioral traits. It does not mention side effects (e.g., whether the cards are marked as seen), authentication needs, rate limits, or any other behavioral characteristics beyond the basic return action.

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 a single, concise sentence with no wasted words. It is appropriately front-loaded. However, it could be slightly more informative without sacrificing conciseness.

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 simple tool with one parameter and no output schema, the description is adequate. It explains the core function but lacks context about retrieval behavior (e.g., whether cards are returned in a specific order, what happens when fewer cards are available).

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 for parameter 'num' is 100% (it has a description). The tool description adds minimal meaning beyond the schema, specifying that the parameter controls how many 'new and unseen' cards are returned. However, it does not clarify the selection criteria, ordering, or what 'new' or 'unseen' mean precisely.

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 clearly states that the tool 'returns a given number (num) of new and unseen cards.' The verb 'returns' identifies the action, and the resource 'new and unseen cards' distinguishes it from sibling tools like get_due_cards (due cards) and add_card/update_cards (mutations).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention when the user should prefer get_new_cards over get_due_cards or other siblings, nor does it provide any context about prerequisites or constraints.

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

update_cardsA

After the user answers cards you've quizzed them on, use this tool to mark them answered and update their ease

ParametersJSON Schema
NameRequiredDescriptionDefault
answersNo

TDQS

A3.9/5.0
Behavior3/5

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

No annotations exist, so description bears full burden. It discloses that the tool marks answered and updates ease, but omits details like idempotency, side effects, or required permissions. Minimal but not misleading.

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?

Single sentence, front-loaded with action and condition. No redundant words. Efficiently conveys core functionality.

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?

No output schema, so return value is unstated. The description covers the action but lacks information on result feedback or error conditions. Adequate for simple update but not fully comprehensive.

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?

Input schema already describes both parameters (cardId and ease with ease range). Description adds no additional meaning beyond what schema provides. With high schema coverage, baseline 3 is appropriate.

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?

Description clearly states verb 'mark them answered and update their ease' targeting specific resource 'cards'. Distinguishes from siblings like add_card (add) and get_due_cards/get_new_cards (fetch) by focusing on post-answer update.

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

Usage Guidelines4/5

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

Explicitly states when to use: after user answers cards. Does not list when not to use or alternatives, but context with sibling tools implies purpose is unique. Slightly lacks exclusion guidance.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv1.2.2
    • First observedadd_card
    • First observedget_due_cards
    • First observedget_new_cards
    • First observedupdate_cards
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct operation: adding cards, retrieving due cards, retrieving new cards, and updating card status. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent 'verb_noun' pattern (add_card, get_due_cards, get_new_cards, update_cards) using snake_case, making them predictable and easy to understand.

Tool Count5/5

With 4 tools, the set is appropriately scoped for a flashcard management server, covering essential operations without unnecessary bloat or gaps.

Completeness4/5

The tools cover the core lifecycle of creating, retrieving, and updating flashcards. Missing a delete operation or deck management, but the set is functional for basic use.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Anki MCP Server

    ankimcp
    A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that enables AI assistants to interact with the Anki flashcard application for studying, deck management, and note creation. It supports natural language interaction for reviewing cards, searching content, and managing media files across local and remote environments.
    1,716
    467
    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
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/htlin222/yanki-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server