Skip to main content
Glama
deenesjakoruzh
nietus

Anki MCP Server

by nietus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

anki-mcp

铁匠徽章

Anki 的 MCP 服务器。该服务器允许通过模型上下文协议 (MCP) 与 Anki 进行交互。它允许用户以编程方式管理抽认卡、卡片组和复习流程。

先决条件

  • 已安装 Node.js 和 npm。

  • AnkiConnect 插件已安装并在 Anki 中运行。

Related MCP server: Anki MCP Server

设置和执行

强烈建议在本地运行，因为 anki connect 只能在本地运行

要在本地运行：

  1. 克隆存储库：

    git clone https://github.com/nietus/anki-mcp

  2. 安装依赖项：

    npm install

  3. 构建项目： package.json中的prepare脚本会在安装后自动运行构建。如果您需要手动构建：

    npm run build

    此命令编译 TypeScript 代码并使客户端脚本可执行。

  4. 与 Windows 的光标设置集成

    "anki": {
      "command": "cmd",
      "args": [
        "/c",
        "node",
        "c:/Users/-/Downloads/anki-mcp/build/client.js"
      ]
    }

可用工具

要调试工具，请使用

npm run inspector

服务器提供以下与 Anki 交互的工具：

  • update_cards ：

    • 描述：在用户回答您向他们提问的卡片后，使用此工具将其标记为已回答并更新其难度。

    • 输入：一个答案数组，每个答案都有cardId （数字）和ease （数字，1-4）。

  • add_card ：

    • 描述：在 Anki 中创建一张新的抽认卡。注意内容使用 HTML 格式。

      • 换行符： <br>

      • 代码： <pre style="background-color: transparent; padding: 10px; border-radius: 5px;">

      • 列表： <ol>和<li>

      • 粗体： <strong>

      • 斜体： <em>

    • 输入：

      • fields ：（对象）一个对象，其中键是字段名称（例如“汉字”，“拼音”），值是其 HTML 内容。

      • modelName ：（字符串）要使用的 Anki 笔记类型（模型）的名称。

      • deckName ：（可选字符串）要添加卡片的牌组名称。默认为当前牌组或“默认”。

      • tags ：（可选字符串数组）要添加到注释的标签列表。

  • get_due_cards ：

    • 描述：返回给定数量的待审查卡片。

    • 输入： num （数字）。

  • get_new_cards ：

    • 描述：返回给定数量的新卡和未见过的卡。

    • 输入： num （数字）。

  • get-deck-names ：

    • 描述：获取所有 Anki 卡片组名称的列表。

    • 输入：无。

  • find-cards ：

    • 描述：使用原始 Anki 搜索查询查找卡片。返回包含字段在内的卡片详细信息。

    • 输入： query （字符串，例如'deck:Default -tag:test'或'"deck:My Deck" tag:important' ）。要过滤空字段，请使用'-FieldName:_*' （例如'-Hanzi:_*' ）。

  • update-note-fields ：

    • 描述：更新给定 Anki 笔记的特定字段。

    • 输入： noteId （数字）， fields （对象，例如， {"Front": "New Q", "Back": "New A"} ）。

  • create_deck ：

    • 描述：创建一个新的 Anki 卡片组。

    • 输入： deckName （字符串）。

  • bulk_update_notes ：

    • 描述：更新多个 Anki 笔记的特定字段。

    • 输入：一个notes数组，其中每个注释都有noteId （数字）和fields （对象）。

  • get_model_names ：

    • 描述：列出所有可用的 Anki 笔记类型/模型名称。

    • 输入：无。

  • get_model_details ：

    • 描述：检索指定注释类型的字段、卡片模板和 CSS 样式。

    • 输入： modelName （字符串）。

  • get_deck_model_info ：

    • 描述：检索指定卡组中所使用的音符类型（模型）的信息。用于判断卡组是否使用了单个、多个模型，或者卡组是否为空或不存在。

    • 输入： deckName （字符串）。

    • 输出：具有deckName 、 status （例如“single_model_found”、“multiple_models_found”、“no_notes_found”、“deck_not_found”）以及条件modelName （字符串）或modelNames （字符串数组）的对象。

  • add_note_type_field ：

    • 描述：向注释类型添加新字段。

    • 输入： modelName （字符串）， fieldName （字符串）。

  • remove_note_type_field ：

    • 描述：从注释类型中删除现有字段。

    • 输入： modelName （字符串）， fieldName （字符串）。

  • rename_note_type_field ：

    • 描述：重命名注释类型中的字段。

    • 输入： modelName （字符串）、 oldFieldName （字符串）、 newFieldName （字符串）。

  • reposition_note_type_field ：

    • 描述：更改注释类型中字段的顺序（索引）。

    • 输入： modelName （字符串）、 fieldName （字符串）、 index （数字）。

  • update_note_type_templates ：

    • 描述：更新笔记类型卡片的 HTML 模板（例如正面和背面）。

    • 输入： modelName （字符串）、 templates （对象，例如， {"Card 1": {"Front": "html", "Back": "html"}} ）。

  • update_note_type_styling ：

    • 描述：更新注释类型的 CSS 样式。

    • 输入： modelName （字符串）， css （字符串）。

  • create_model ：

    • 描述：创建一个新的 Anki 笔记类型（模型）。

    • 输入： modelName （字符串）、 fieldNames （字符串数组）、 cardTemplates （对象数组，每个对象包含Name 、 Front 、 Back HTML 字符串）、 css （可选字符串）、 isCloze （可选布尔值，默认为 false）、 modelType （可选字符串，默认为“标准”）。

  • add_bulk ：

    • 描述：一次性将多张抽认卡添加到 Anki。注释内容使用 HTML 格式。此工具用于一次性添加多张注释（卡片）。

    • 输入：一个notes数组，其中每个注释对象具有：

      • fields ：（对象）一个对象，其中键是字段名称，值是其 HTML 内容。

      • modelName ：（字符串）此注释使用的 Anki 注释类型（模型）的名称。

      • deckName ：（可选字符串）此笔记对应的 deck 名称。默认为“Default”。

      • tags ：（可选字符串数组）此注释的标签列表。

更多信息可以在这里找到Anki Integration | Smithery

Available Tools

3 tools
anki_add_noteC

Add a flashcard to an Anki deck

ParametersJSON Schema
NameRequiredDescriptionDefault
backYesBack of the flashcard
deckNameYesThe target deck name
frontYesFront of the flashcard

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Add') which implies a write/mutation operation, but doesn't disclose any behavioral traits like whether it requires specific permissions, what happens if the deck doesn't exist, error conditions, or how the system responds to successful addition. The description is minimal and lacks operational context.

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?

The description is extremely concise with a single, clear sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward tool and gets directly to the point with no unnecessary elaboration.

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?

For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after adding the flashcard, potential error conditions, or how to verify success. Given the tool's complexity as a write operation and the lack of structured behavioral information, more context about the operation's behavior and outcomes would be valuable.

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 description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for all three parameters. The baseline score of 3 reflects adequate schema documentation, but the description doesn't provide additional context about parameter relationships, constraints, or usage patterns.

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 the action ('Add') and resource ('flashcard to an Anki deck'), making the purpose immediately understandable. It distinguishes from sibling 'anki_add_notes' by specifying singular 'flashcard' vs. plural 'notes', but doesn't explicitly differentiate from 'anki_create_deck' which creates decks rather than flashcards.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'anki_add_notes' (for single vs. multiple cards) or 'anki_create_deck' (for creating decks before adding cards). No prerequisites or contextual usage information is provided.

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

anki_add_notesC

Add multiple flashcards to an Anki deck

ParametersJSON Schema
NameRequiredDescriptionDefault
cardsYes
deckNameYesThe target deck name

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Add multiple flashcards') but doesn't cover critical aspects like whether this is a write operation (implied but not confirmed), error handling (e.g., if the deck doesn't exist), or response format. This leaves significant gaps for an agent to understand the tool's behavior.

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?

The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded and appropriately sized for the tool's complexity, with no wasted information.

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?

Given the lack of annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It doesn't address key contextual elements like mutation effects, error scenarios, or return values, making it inadequate for safe and effective tool invocation.

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 description mentions 'multiple flashcards' and 'Anki deck', which loosely maps to the 'cards' array and 'deckName' parameters. However, with 50% schema description coverage (only 'deckName' has a description), the description doesn't add meaningful details about parameter formats, constraints, or the structure of card objects (front/back fields). It partially compensates but not fully.

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 the action ('Add multiple flashcards') and resource ('to an Anki deck'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'anki_add_note' (singular vs. plural), which could cause confusion about when to use each.

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?

The description provides no guidance on when to use this tool versus alternatives like 'anki_add_note' (for single cards) or 'anki_create_deck' (for deck creation). There's no mention of prerequisites, such as whether the deck must already exist, or any contextual limitations.

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

anki_create_deckC

Create a new Anki deck

ParametersJSON Schema
NameRequiredDescriptionDefault
deckNameYesThe name of the deck to create

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as error handling (e.g., what happens if the deck already exists), permission requirements, side effects, or response format, which are critical for a creation tool.

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?

The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.

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?

For a creation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavior, error cases, and output, leaving gaps that could hinder an agent's ability to use the tool effectively in complex scenarios.

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 description coverage is 100%, with the parameter 'deckName' clearly documented in the schema. The description doesn't add any meaning beyond the schema, such as naming conventions or constraints, but the schema provides adequate baseline information.

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 the action ('Create') and resource ('new Anki deck'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'anki_add_note' or 'anki_add_notes', which are about adding content rather than creating deck structure.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether the deck must not already exist), constraints, or relationships to sibling tools, leaving the agent to infer usage context.

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. 3 tool updatesv1.0.0
    • First observedanki_add_note
    • First observedanki_add_notes
    • First observedanki_create_deck
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.9/5.0

Scored across 3 tools

Disambiguation3/5

The tools have overlapping purposes, as 'anki_add_note' and 'anki_add_notes' both handle adding flashcards, which could cause confusion for an agent deciding between single vs. batch operations. However, the descriptions clarify the distinction (single vs. multiple), mitigating some ambiguity. The 'anki_create_deck' tool is clearly distinct, focusing on deck management rather than note addition.

Naming Consistency5/5

All tool names follow a consistent 'anki_' prefix and snake_case pattern (e.g., anki_add_note, anki_add_notes, anki_create_deck), with clear verb_noun structures. This predictability makes it easy for agents to understand and navigate the tool set without confusion from mixed conventions.

Tool Count2/5

With only 3 tools, the server feels thin for managing Anki flashcards, a domain that typically involves operations like updating, deleting, reviewing, or searching notes and decks. The count is too low for the apparent scope, lacking essential CRUD lifecycle coverage beyond basic creation, which may limit agent functionality.

Completeness2/5

The tool set is severely incomplete for Anki management, covering only note addition and deck creation. Obvious gaps include updating or deleting notes/decks, listing or searching existing content, and handling reviews or scheduling—core aspects of flashcard workflows. This will likely cause agent failures when trying to perform common tasks beyond initial setup.

Maintenance

ActivitySlowing
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches