Which integrations are available for this server?

Provides tools for managing Anki flashcard decks, cards, and notes, including creating, updating, deleting, searching, and retrieving statistics.

How do I use mcp-server-anki?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-anki Show me the learning progress for my 'English Vocabulary' deck" 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.

mcp-server-anki

by here-tunan

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

MCP Server Anki

MCP TypeScript AnkiConnect

中文文档 | English

A Model Context Protocol (MCP) server that bridges Anki with AI tools, enabling intelligent flashcard management and learning assistance.

💡 Compatibility: This server works with any MCP-compatible AI tool including Claude Code, Cline, Zed AI, and more. We use Claude Code as an example in this documentation, but the setup process is similar for other tools.

🌟 Features

📚 Deck Management: Get deck lists, view deck statistics
🔍 Card Search: Search cards using Anki's advanced query syntax
➕ Smart Creation: Create and manage Anki cards with AI assistance
✏️ Card Editing: Update existing card fields and content
🗑️ Card Deletion: Delete unwanted cards and notes
📊 Data Analysis: Get learning statistics and progress information
🔧 Template Management: View and use different note types

Related MCP server: Anki MCP Server

📋 Prerequisites

Anki Desktop - Download Anki
AnkiConnect Plugin - Install in Anki (Code: 2055492159)
Node.js - Version 16 or higher
MCP-compatible AI Tool - Such as:
- Claude Code
- Cline
- Zed AI
- Any other tool supporting MCP

🚀 Quick Start

1. Install AnkiConnect

In Anki:

Tools → Add-ons → Get Add-ons
Enter code: 2055492159
Restart Anki

2. Configure Your MCP Client

The following examples use Claude Code, but the configuration is similar for other MCP-compatible tools.

Option A: Using Command Line

# For Claude Code
claude mcp add anki -- npx mcp-server-anki

# For other tools, consult their documentation for the equivalent command

Option B: Manual Configuration

Add the server to your MCP client's configuration file:

{
  "mcp": {
    "servers": {
      "anki": {
        "command": "npx",
        "args": ["mcp-server-anki"]
      }
    }
  }
}

📖 Usage Guide

Basic Workflow

Start Anki - Ensure Anki is running with AnkiConnect enabled
Start MCP Server - Automatically started by Claude Code
Use AI Tools - Interact with Anki through Claude Code

Example Conversations

User: Show me the learning progress for my "English Vocabulary" deck

Claude: I'll check the statistics for your "English Vocabulary" deck...
[Calls get_deck_stats tool]

User: Create a new English word card for "ephemeral"

Claude: I'll create this word card for you...
[Calls add_note tool]

🛠️ Available Tools

Tool Name	Description	Parameters
`get_deck_names`	Get all deck names	None
`get_cards_in_deck`	Get cards from a specific deck	`deckName`
`get_deck_stats`	Get deck statistics	`deckName`
`search_cards`	Search cards	`query`
`add_note`	Add new note	`deckName`, `modelName`, `fields`, `tags`
`update_note`	Update existing note fields	`noteId`, `fields`
`get_note_info`	Get detailed note information	`noteId`
`delete_notes`	Delete one or more notes	`noteIds`
`get_models`	Get all note types	None
`get_model_fields`	Get note type fields	`modelName`

🏗️ Project Structure

mcp-server-anki/
├── src/
│   ├── index.ts           # MCP server entry point
│   ├── ankiConnect.ts      # AnkiConnect API client
│   └── tools/              # MCP tool definitions
│       ├── deckTools.ts    # Deck-related tools
│       ├── cardTools.ts    # Card-related tools
│       └── noteTools.ts    # Note-related tools
├── dist/                   # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.md

🔧 Development

Build Commands

# Development mode (watch for changes)
npm run dev

# Production build
npm run build

Architecture

Claude Code (MCP Client) ←→ Anki MCP Server ←→ AnkiConnect ←→ Anki Desktop

📝 API Documentation

get_deck_names

Get a list of all deck names.

Returns:

["Default", "English Vocabulary", "Programming"]

search_cards(query)

Search cards using Anki query syntax.

Parameters:

query: Anki query string (e.g., deck:English is:due)

Query Syntax Examples:

deck:DeckName - Specific deck
tag:TagName - By tag
is:due - Due cards
is:new - New cards
added:7 - Cards added in last 7 days

add_note

Add a new note to Anki.

Parameters:

deckName: Target deck name
modelName: Note type (e.g., "Basic", "Cloze")
fields: Field content object
tags: Tag array (optional)

Example:

{
  "deckName": "English Vocabulary",
  "modelName": "Basic",
  "fields": {
    "Front": "ephemeral",
    "Back": "lasting for a very short time"
  },
  "tags": ["vocabulary", "adjective"]
}

update_note

Update fields of an existing note.

Parameters:

noteId: The ID of the note to update
fields: Object with field names and new values

Example:

{
  "noteId": 1234567890,
  "fields": {
    "Back": "lasting for an extremely short time"
  }
}

get_note_info

Get detailed information about a specific note.

Parameters:

noteId: The ID of the note to query

Returns:

{
  "noteId": 1234567890,
  "modelName": "Basic",
  "fields": {
    "Front": "ephemeral",
    "Back": "lasting for a very short time"
  },
  "tags": ["vocabulary", "adjective"]
}

delete_notes

Delete one or more notes.

Parameters:

noteIds: Array of note IDs to delete

Example:

{
  "noteIds": [1234567890, 9876543210]
}

🔧 Building from Source

If you want to contribute or customize the server:

# Clone the repository
git clone https://github.com/here-tunan/mcp-server-anki.git
cd mcp-server-anki

# Install dependencies
npm install

# Build TypeScript
npm run build

To use your local build with Claude Code, configure it with:

{
  "mcp": {
    "servers": {
      "anki": {
        "command": "node",
        "args": ["/path/to/mcp-server-anki/dist/index.js"]
      }
    }
  }
}

🤝 Contributing

Issues and Pull Requests are welcome!

📄 License

Apache License

🔗 Links

❓ FAQ

Q: AnkiConnect connection failed?

A: Ensure Anki is running and AnkiConnect plugin is installed and enabled. Default port is 8765.

Q: How to customize note types?

A: After creating custom note types in Anki, use get_models and get_model_fields tools to view available fields.

Q: Mobile support?

A: Currently only supports desktop Anki due to AnkiConnect dependency.

Made with ❤️ for Anki learners and AI enthusiasts

Available Tools

10 tools

add_noteB

Add a new note (card) to Anki

ParametersJSON Schema

Name	Required	Description	Default
`deckName`	Yes	Name of the deck to add the note to
`modelName`	No	Note type (model) name (default: "Basic")	Basic
`fields`	Yes	Fields content (e.g., {"Front": "Question", "Back": "Answer"})
`tags`	No	Tags to add to the note (optional)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action, omitting details like error handling, duplicate behavior, or required deck/model existence. The schema provides structure but no behavioral context.

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 of 9 words, making it concise. However, it may be too brief to fully inform the agent, but conciseness is appropriately sized for a simple action.

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 no annotations, no output schema, and a nested parameter (fields), the description lacks completeness. It does not mention return values, error conditions, or required existence of deck/model. The schema covers parameters but not context.

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%, so baseline is 3. The description adds minimal value (e.g., 'note (card)' clarification) but does not significantly enhance understanding beyond the schema's parameter descriptions.

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 tool's function: 'Add a new note (card) to Anki'. It uses a specific verb (Add) and resource (note/card), and the context (Anki) distinguishes it from sibling tools like delete_notes or update_note.

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 vs alternatives like update_note or get_note_info. There are no mentions of prerequisites, limitations, or exclusions.

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

delete_notesC

Delete one or more notes by their IDs

ParametersJSON Schema

Name	Required	Description	Default
`noteIds`	Yes	Array of note IDs to delete

TDQS

C2.9/5.0

Behavior1/5

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

With no annotations provided, the description must disclose behavioral traits. It only states 'Delete', but fails to mention if deletions are permanent, soft-deletes, or what side effects occur (e.g., cascading deletions). This is a significant gap for a destructive 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 a single, clear sentence. It is concise but could include more useful information without being 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?

Given the tool is destructive, lacks annotations and output schema, the description should provide more context on consequences, reversibility, and prerequisites. It feels incomplete.

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 is 100%, so the parameter 'noteIds' is already documented. The description adds no extra meaning beyond 'by their IDs', providing minimal added value. 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?

The description clearly states the verb 'Delete' and the resource 'notes', and specifies the mechanism 'by their IDs'. It is distinct from siblings like add_note and update_note.

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. For example, it does not mention that deleting notes may affect associated cards or that it is irreversible.

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

get_cards_in_deckC

Get cards from a specific deck

ParametersJSON Schema

Name	Required	Description	Default
`deck`	Yes	Name of the deck
`limit`	No	Maximum number of cards to return (default: 10)

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states 'Get cards' without mentioning read-only nature, pagination, or any side effects. The limit parameter is not described in terms of its impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, but it is too minimal. It could include more detail 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?

Given the tool's simplicity (2 parameters, no output schema), the description should explain what 'cards' means (e.g., card fields, order) and the effect of the limit parameter. It leaves significant gaps.

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%, so the schema already explains both parameters (deck and limit) clearly. The description adds no additional semantic value beyond the schema.

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 (Get) and resource (cards from a specific deck). It is unambiguous but does not differentiate from siblings like search_cards, which also returns cards.

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 such as search_cards or get_deck_stats. It fails to mention that it retrieves all cards from a given deck without filtering.

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

get_deck_namesA

Get all deck names from Anki

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states a read operation but lacks details on return order, completeness, or error cases. Minimal transparency.

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?

One short, front-loaded sentence with no extraneous words. Every word is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no params, no output schema, and simple retrieval, description is adequate. Could mention return type (e.g., array of strings) but not critical for understanding.

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

Parameters4/5

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

No parameters, so schema coverage is 100%. Baseline for 0 params is 4; description adds no parameter info but it's unnecessary.

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 'Get all deck names from Anki' clearly states the verb (Get), resource (deck names), and scope (all). It distinguishes from siblings like get_deck_stats which provides stats.

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 or alternatives. For a simple retrieval, usage is implied, but lacking explicit when-not or comparison to siblings like get_deck_stats for detailed info.

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

get_deck_statsB

Get statistics for a specific deck

ParametersJSON Schema

Name	Required	Description	Default
`deck`	Yes	Name of the deck

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided. The description merely states it 'gets statistics' without disclosing whether the operation is read-only, what side effects exist, or what the intended behavior is. For a tool without annotations, more behavioral context is expected.

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 with no extraneous words. It is front-loaded and efficient, though it could be slightly more informative without losing conciseness.

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 absence of an output schema, the description should at least hint at the kind of statistics returned (e.g., counts, dates). It fails to do so, leaving the agent without enough context to assess the tool's return value.

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 input schema has 100% description coverage for the single parameter 'deck', so the description adds no additional meaning. Baseline score of 3 is appropriate as the schema already provides the necessary semantics.

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 tool retrieves statistics for a specific deck. It uses a specific verb and resource, and it is distinct from siblings like get_deck_names (which returns names only) and get_cards_in_deck (which returns cards).

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 such as get_deck_names or get_cards_in_deck. The description does not mention any prerequisites or context for use.

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

get_model_fieldsB

Get field names for a specific note type

ParametersJSON Schema

Name	Required	Description	Default
`modelName`	Yes	Name of the note type (model)

TDQS

B3.1/5.0

Behavior2/5

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 states it gets field names, with no mention of idempotency, permissions, or potential side effects. This is insufficient for a read operation without annotations.

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, front-loaded sentence that conveys the essential information without any superfluous words. It is appropriately sized for the tool's simplicity.

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 simplicity, the description is adequate but lacks details on expected output format or behavior. Without an output schema, it could mention that it returns a list of field names, but for a basic getter, it meets minimum viability.

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 is 100% and the single parameter 'modelName' is described in the schema. The description does not add any meaning beyond the schema, so the baseline score of 3 is appropriate.

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 it retrieves field names for a specific note type. It uses a specific verb and resource, and while it doesn't explicitly differentiate from sibling tools like 'get_models', the purpose is unambiguous.

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 given on when to use this tool versus alternatives, such as 'get_models' which might return note types but not their fields. The description lacks context for when-not-to-use or prerequisites.

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

get_modelsA

Get all available note types (models)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states it retrieves all note types with no details on ordering, caching, or 'available' meaning. Minimal transparency for a read operation.

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, concise sentence with no unnecessary words. Front-loaded with the verb and resource.

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 0-parameter retrieval tool without output schema, the description is adequate but lacks clarity on return format or what 'models' includes, especially relative to sibling get_model_fields.

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 input schema has no parameters (100% coverage), so the description adds no extra meaning beyond stating 'all available note types', which is sufficient for a parameterless tool.

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 'Get all available note types (models)' clearly states a specific verb ('get') and resource ('note types/models'), distinguishing it from sibling tools like add_note or get_model_fields.

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 for retrieving all models, but provides no explicit guidance on when to use this tool instead of siblings like get_model_fields, nor any when-not-to-use conditions.

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

get_note_infoC

Get detailed information about a specific note

ParametersJSON Schema

Name	Required	Description	Default
`noteId`	Yes	ID of the note to get information about

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and description fails to disclose read-only nature, error handling, or any behavioral details beyond the basic 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?

Single sentence with no fluff, but lacks structure. Could be improved by front-loading key details.

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, yet description does not explain what 'detailed information' includes. Incomplete for a tool with one parameter and no annotation context.

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 is 100% with one parameter well-described. The description adds no extra meaning beyond the schema, so it is adequate but not helpful.

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 uses a specific verb 'get' and resource 'note', but 'detailed information' is vague. It clearly distinguishes from siblings like 'search_cards' or 'delete_notes'.

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 on when to use this tool versus alternatives like 'search_cards' or 'get_deck_stats'. No mention of prerequisites or context.

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

search_cardsC

Search for cards using Anki query syntax

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Anki search query (e.g., "deck:Spanish", "tag:important")
`limit`	No	Maximum number of cards to return (default: 10)

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 bears full responsibility for disclosing behavior. It only states 'search for cards' without explaining what is returned, whether it's read-only, or any limitations. The agent cannot infer safety 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and concise. However, it may be too brief; slightly more detail would improve usability without sacrificing conciseness.

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 complexity (multiple sibling tools for cards) and the lack of an output schema, the description should provide more context, such as what the search results contain or how to use the query syntax. It is incomplete for effective agent decision-making.

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% as both parameters have clear descriptions in the input schema. The tool description adds minimal value beyond restating 'Anki query syntax'. A baseline of 3 is appropriate given the schema already documents the parameters sufficiently.

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 tool's purpose: searching for cards using Anki query syntax. The verb 'search' and the resource 'cards' are specific, and the mention of Anki query syntax hints at the type of query expected. However, it does not explicitly distinguish from sibling tools like 'get_cards_in_deck', which also retrieves cards, making a 4 appropriate.

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 such as 'get_cards_in_deck' or 'get_note_info'. The description lacks any exclusion criteria or context that would help the agent choose appropriately.

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

update_noteC

Update fields of an existing note

ParametersJSON Schema

Name	Required	Description	Default
`noteId`	Yes	ID of the note to update
`fields`	Yes	Fields to update with their new values

TDQS

C2.9/5.0

Behavior2/5

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

The description does not disclose behavior beyond the obvious. Without annotations, it fails to mention whether updates are idempotent, merge or replace fields, or any 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, direct sentence with no wasted 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.

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 and output schema, the description is too minimal. It does not explain partial updates, response behavior, or handle edge cases, making it insufficient for an agent to use correctly.

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 input schema provides 100% coverage of parameters, but the description adds no additional meaning. It does not explain how the 'fields' object is applied (merge vs replace), which would be helpful.

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 (update) and resource (existing note), distinguishing it from related tools like add_note or delete_notes. However, it lacks detail on what specific fields can be updated.

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 on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context for usage.

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.

10 tool updatesv1.0.1May 29, 2026
- First observedadd_note
- First observeddelete_notes
- First observedget_cards_in_deck
- First observedget_deck_names
- First observedget_deck_stats
- First observedget_model_fields
- First observedget_models
- First observedget_note_info
- First observedsearch_cards
- First observedupdate_note

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 2026-05-29 16:35 across 10 tools

Disambiguation5/5

Each tool targets a distinct operation: note creation/deletion/update/retrieval, deck listing/stats, card search, and model fields. No two tools could be confused for the same purpose.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern (e.g., add_note, get_deck_names, search_cards), making the set predictable and easy to navigate.

Tool Count5/5

With 10 tools, the server covers the essential operations for Anki note and deck management without bloat. Each tool serves a clear and necessary role.

Completeness4/5

The set provides full CRUD for notes and query capabilities for decks and models. Missing deck creation or deletion, but these are less critical for typical note management workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

FlipnemOAuth
com.flipnem
Build and study spaced-repetition flashcards with your agent.
Education & Learning Tools Knowledge & Memory Note Taking
2
Acornonaut MCP ServerOAuth
io.github.zerolve-io
AI-powered YouTube to flashcards with spaced repetition and Anki export
Education & Learning Tools AI & Machine Learning
2
Flash AOAuth
com.flashmemorize
Spaced-repetition flashcards your AI writes, quizzes you on by voice, and schedules with FSRS.
Education & Learning Tools Speech Processing
1411
manthanOAuth
tech.sirune
List and create Manthan concept-card decks from an AI agent — no AI quota spent for imports.
Education & Learning Tools Knowledge & Memory
1

Related MCP Servers

Anki MCP Server
Education & Learning Tools Note Taking App Automation
zlatanpham
A
license
B
quality
C
maintenance
Enables AI assistants to manage Anki flashcard decks and cards through natural language, supporting deck creation, card additions (basic and cloze types), and review queue management.
Updated a year ago (2025-08-08 08:26 UTC)
6
6 npm
2
MIT
Anki MCP Server
Education & Learning Tools Note Taking App Automation
loonskai
A
license
Not graded
quality
C
maintenance
Enables interaction with the Anki desktop flashcard application through the Anki-Connect plugin. Supports managing decks, cards, notes, and models, allowing AI assistants to create and query flashcards through natural language.
Updated a year ago (2025-06-21 09:54 UTC)
5 npm
1
ISC
Anki Connect MCP Server
Education & Learning Tools Note Taking
spacholski1225
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Anki flashcard collections through the AnkiConnect add-on, allowing creation, modification, searching, and management of flashcards and decks.
Updated a year ago (2025-07-20 19:14 UTC)
15 npm
24
MIT
anki-mcp
Education & Learning Tools Knowledge & Memory
mybuddymichael
A
license
Not graded
quality
D
maintenance
Enables LLMs to interact with Anki flashcard collections, including deck management, note search, viewing contents, and editing fields.
Updated a year ago (2025-07-31 02:52 UTC)
12 npm
MIT