Skip to main content
Glama
enesjakozh
scorzeth

Anki MCP Server

by scorzeth
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Servidor MCP de Anki

Una implementación de servidor MCP que se conecta a un Anki que se ejecuta localmente y proporciona revisión y creación de tarjetas.

Este servidor está diseñado para funcionar con la aplicación de escritorio Anki y el complemento Anki-Connect .

Asegúrese de tener el complemento instalado antes de usarlo.

Recursos

  • anki://search/deckcurrent

    • Devuelve todas las cartas del mazo actual

    • Equivalente de deck:current en Anki

  • anki://search/isdue

    • Devuelve tarjetas en revisión y aprendizaje en espera de ser estudiadas

    • Equivalente de is:due en Anki

  • anki://search/isnew

    • Devuelve todas las cartas no vistas

    • Equivalente de is:new en Anki

Related MCP server: Anki MCP Server

Herramientas

  • tarjetas_de_actualización

    • Marca las tarjetas con los identificadores de tarjeta dados como respondidas y les otorga un puntaje de facilidad entre 1 (Nuevamente) y 4 (Fácil)

    • Entradas:

      • answers (matriz): Matriz de objetos con campos cardId (número) y ease (número)

  • agregar_tarjeta

    • Crea una nueva carta en el mazo predeterminado de Anki

    • Entradas:

      • front (cadena): Frente de la tarjeta

      • back (cadena): reverso de la tarjeta

  • obtener_tarjetas_vencidas

    • Devuelve n número de tarjetas que actualmente deben revisarse

    • Entradas:

      • num (número): Número de cartas

  • obtener_nuevas_tarjetas

    • Devuelve n número de tarjetas de nuevo

    • Entradas:

      • num (número): Número de cartas

Desarrollo

Instalar dependencias:

npm install

Construir el servidor:

npm run build

Para desarrollo con reconstrucción automática:

npm run watch

Configuración

Para utilizar con Claude Desktop, agregue la configuración del servidor:

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

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

Depuración

Dado que los servidores MCP se comunican a través de stdio, la depuración puede ser complicada. Recomendamos usar el Inspector MCP , disponible como script de paquete:

npm run inspector

El Inspector proporcionará una URL para acceder a las herramientas de depuración en su navegador.

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