Skip to main content
Glama
enesjakozh
scorzeth

Anki MCP Server

by scorzeth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Anki MCP サーバー

ローカルで実行されている Anki に接続し、カードのレビューと作成を提供する MCP サーバー実装。

このサーバーは、Anki デスクトップ アプリおよびAnki-Connectアドオンで動作するように設計されています。

使用する前にアドオンがインストールされていることを確認してください。

リソース

  • アンキ://search/deckcurrent

    • 現在のデッキからすべてのカードを返します

    • Ankiのdeck:currentに相当するもの

  • アンキ://search/isdue

    • 復習と学習を待っているカードを返します

    • Ankiのis:dueに相当するもの

  • アンキ://search/isnew

    • 未表示のカードをすべて返す

    • Ankiのis:newに相当するもの

Related MCP server: Anki MCP Server

ツール

  • アップデートカード

    • 指定されたカード ID のカードを回答済みとしてマークし、1 (再回答) から 4 (簡単) までの容易さスコアを付与します。

    • 入力:

      • answers （配列）： cardId （数値）とease （数値）フィールドを持つオブジェクトの配列

  • カードを追加

    • デフォルトの Anki デッキに新しいカードを作成します

    • 入力:

      • front (文字列): カードの表面

      • back (文字列): カードの裏面

  • 期限切れカードを取得する

    • 現在レビューが必要なカードのn枚数を返します

    • 入力:

      • num (数字): カードの枚数

  • 新しいカードを取得する

    • 新しいカードからn枚のカードを返す

    • 入力:

      • num (数字): カードの枚数

発達

依存関係をインストールします:

npm install

サーバーを構築します。

npm run build

自動リビルドを使用した開発の場合:

npm run watch

構成

Claude Desktop で使用するには、サーバー設定を追加します。

MacOS の場合: ~/Library/Application Support/Claude/claude_desktop_config.json Windows の場合: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "anki-mcp-server": {
      "command": "/path/to/anki-mcp-server/build/index.js"
    }
  }
}

デバッグ

MCPサーバーはstdio経由で通信するため、デバッグが困難になる場合があります。パッケージスクリプトとして提供されているMCP Inspectorの使用をお勧めします。

npm run inspector

インスペクターは、ブラウザでデバッグ ツールにアクセスするための URL を提供します。

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:

    • 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

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool creates a new flashcard (implying mutation) and specifies critical formatting rules, but does not cover other behavioral aspects such as permissions, error handling, or what happens on success/failure. It adds some context but is incomplete for a mutation tool.

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 core purpose, followed by detailed formatting rules in a structured list. It is appropriately sized, but the formatting rules section is somewhat lengthy; every sentence earns its place by clarifying critical constraints, though it could be more streamlined.

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?

Given the tool's complexity (a mutation tool with no annotations and no output schema), the description covers the purpose and formatting rules well but lacks information on behavioral traits like response format, error conditions, or prerequisites. It is adequate but has clear gaps for a creation tool.

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?

The schema description coverage is 100%, so the schema already documents both parameters (front and back) with descriptions. The description adds value by emphasizing HTML formatting rules that apply to these parameters, but does not provide additional semantic details beyond what the schema offers, aligning with the baseline for high coverage.

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 the specific action ('Create a new flashcard in Anki') and identifies the resource ('flashcard'), distinguishing it from sibling tools like get_due_cards, get_new_cards, and update_cards which are retrieval or modification operations rather than creation.

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 by specifying 'for the user' and formatting requirements, but does not explicitly state when to use this tool versus alternatives like update_cards or when not to use it. It provides context but lacks clear exclusions or direct sibling comparisons.

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.

  1. 4 tool updatesv1.0.0
    • Addedadd_card
    • Addedget_due_cards
    • Addedget_new_cards
    • Addedupdate_cards
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

A3.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: add_card creates new flashcards, get_due_cards retrieves cards due for review, get_new_cards fetches unseen cards, and update_cards marks answered cards and updates their ease. The four tools cover different stages of the flashcard lifecycle without any ambiguity.

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 throughout. The naming is predictable and readable, with clear action-object relationships that align with their functions.

Tool Count5/5

With 4 tools, this server is well-scoped for its purpose of managing Anki flashcards. Each tool earns its place by covering essential operations: creation, retrieval of due/new cards, and updating after reviews. The count is neither too sparse nor bloated for the domain.

Completeness4/5

The tool set provides strong coverage of core flashcard workflows: creating cards, retrieving cards for review, and updating them after answers. A minor gap is the lack of tools for deleting or editing existing cards, but agents can still function effectively with the provided operations.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches