Skip to main content
Glama
enesjakozh
samefarrar

MCP-AnkiConnect

by samefarrar
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

mcp-ankiconnect MCP server

Connect Claude conversations with AnkiConnect via MCP to make spaced repetition as easy as "Let's go through today's flashcards" or "Make flashcards for this"

Components

Tools

The server implements the following tools:

  • num_cards_due_today: Get the number of cards due today

    • Optional deck argument to filter by specific deck

    • Returns count of due cards across all decks or specified deck

  • get_due_cards: Get cards that are due for review

    • Optional limit argument (default: 5) to control number of cards

    • Optional deck argument to filter by specific deck

    • Optional today_only argument (default: true) to show only today's cards

    • Returns cards in XML format with questions and answers

  • submit_reviews: Submit answers for reviewed cards

    • Takes list of reviews with card_id and rating

    • Ratings: "wrong", "hard", "good", "easy"

    • Returns confirmation of submitted reviews

  • search_notes: Find notes by AnkiConnect query. Returns IDs + a short Front preview by default (cheap); pass return_card_content=true to receive cleaned field content inline.

  • inspect_cards: View per-card state for given card IDs or note IDs. Sparse-fieldset selection via the properties list: any of identity, state, scheduling, timestamps, history, fields, or all (default: ["identity", "state", "scheduling"]). The legacy include_history=true flag is still accepted as an alias.

  • update_note_fields: Modify the text content of one note's fields. Uses the same MathJax/code conversions as add_note.

  • update_note_tags: Add and/or remove tags on one or more notes.

  • set_suspended: Suspend or unsuspend one or more cards.

  • change_deck: Move cards (by card ID) into a different deck.

  • reschedule_cards: Set due date, forget, or relearn one or more cards.

Related MCP server: Anki MCP Server

Configuration

Prerequisites

  • Anki must be running with AnkiConnect plugin installed (plugin id 2055492159) AnkiConnect can be slow on Macs due to the AppSleep feature, so disable it for Anki. To do so run the following in your terminal.

    defaults write net.ankiweb.dtop NSAppSleepDisabled -bool true
defaults write net.ichi2.anki NSAppSleepDisabled -bool true
defaults write org.qt-project.Qt.QtWebEngineCore NSAppSleepDisabled -bool true

Installation

Quickstart

  1. Install the AnkiConnect plugin in Anki:

    • Tools > Add-ons > Get Add-ons...

    • Enter code: 2055492159

    • Restart Anki

  2. Configure Claude Desktop:

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

    Add this configuration:

    {
  "mcpServers": {
    "mcp-ankiconnect": {
      "command": "uv",
      "args": ["run", "--with", "mcp-ankiconnect", "mcp-ankiconnect"]
    }
  }
}

  3. Restart Anki and Claude desktop

Debugging

Since MCP servers run over stdio, debugging can be challenging. For the best debugging experience, we strongly recommend using the MCP Inspector. First, clone the repository and install the dependencies:

git clone https://github.com/samefarrar/mcp-ankiconnect.git
cd mcp-ankiconnect
uv sync

You can launch the MCP Inspector via the mcp CLI:

uv run mcp dev mcp_ankiconnect/server.py

Upon launching, the Inspector will display a URL you can access in your browser to begin debugging.

Available Tools

14 tools
add_noteA

Add a flashcard to Anki. Ensure you have looked at examples before you do this, and that you have got approval from the user to add the flashcard.

For code examples, use <code> tags to format your code.
e.g. <code>def fibonacci(n):
if n <= 1:
    return n
return fibonacci(n-1) + fibonacci(n-2)</code>

For MathJax, use the <math> tag to format your math equations. This will automatically render the math equations in Anki.
# e.g. <math>\frac{d}{dx}[3\sin(5x)] = 15\cos(5x)</math>

To attach images to a card, use the picture parameter. Each picture object must have a filename
and exactly one source (url, data, or path). The fields list specifies which card fields get the <img> tag inserted.

## How to attach images based on the source:

**User provides a URL:**
[{"url": "https://example.com/photo.jpg", "filename": "photo.jpg", "fields": ["Back"]}]

**User provides a local file (e.g. screenshot, downloaded image):**
[{"path": "/absolute/path/to/image.png", "filename": "image.png", "fields": ["Back"]}]

**Base64-encoded data (for small images only):**
[{"data": "iVBORw0KGgo...", "filename": "diagram.png", "fields": ["Back"]}]

IMPORTANT: When a user shares an image file or screenshot, prefer using "path" with the absolute
file path rather than trying to base64-encode the image contents. AnkiConnect reads the file directly
from disk which is faster and more reliable.

Args:
    deckName: str - The target deck name.
    modelName: str - The note type (model) name.
    fields: dict - Dictionary of field names and their string content.
    tags: List[str] - Optional list of tags.
    picture: List[dict] - Optional list of picture attachments. Each dict should have:
        - filename (str): Name for the stored image file.
        - url (str, optional): URL to download the image from.
        - path (str, optional): Absolute file path to a local image. Preferred for user-shared files.
        - data (str, optional): Base64-encoded image data.
        - fields (List[str]): Card field names where the <img> tag will be inserted.
        - skipHash (str, optional): MD5 hash to skip if file matches.
ParametersJSON Schema
NameRequiredDescriptionDefault
deckNameYes
modelNameYes
fieldsYes
tagsNo
pictureNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description compensates by detailing behavior for image attachment (three methods, preferred path), code formatting, and MathJax. It explains the picture parameter structure and important preferences. It does not mention side effects like triggering reviews or potential errors, but the coverage is good.

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 relatively long but well-structured with examples and sections. It front-loads the purpose and then details usage. Some redundancy exists (e.g., repeating the picture structure), but it is organized. It could be more concise without losing clarity.

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 the complexity of the tool (5 parameters, nested objects, no output schema in view), the description is quite complete. It covers all parameters, image handling, formatting, and use conditions. It lacks details on return values, but since an output schema exists (per context), this may be acceptable. Overall, it enables correct usage.

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?

The description explains all parameters: deckName and modelName as strings, fields as a dict, tags as optional list, and picture as a list of dicts with detailed sub-fields (filename, url, path, data, fields, skipHash). This adds significant meaning beyond the sparse input schema, which has 0% description coverage.

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 'Add a flashcard to Anki', which directly conveys the tool's purpose. The verb 'add' and resource 'flashcard' are specific. However, it does not explicitly differentiate from sibling tools like 'update_note_fields' or 'search_notes', though the action is distinct.

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 instructs users to look at examples and get approval before adding a flashcard, providing clear usage conditions. It also includes detailed guidelines for code and MathJax formatting. However, it does not mention when not to use the tool or suggest alternatives like 'update_note_fields' for modifying existing notes.

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

change_deckA

Move cards into a different deck.

Operates on card IDs (AnkiConnect's `changeDeck` is card-scoped). If you only
have note IDs, call `inspect_cards(note_ids=...)` first — a single note's cards
can legitimately live in different decks, so this tool never silently expands
notes into cards.

Args:
    card_ids: Card IDs to move.
    deck: Target deck name (e.g. "Spanish::Verbs").
ParametersJSON Schema
NameRequiredDescriptionDefault
card_idsYes
deckYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

Although no annotations are present, the description discloses a key behavioral trait: the tool is card-scoped and does not silently expand notes into cards. It references the underlying AnkiConnect function. However, it lacks details on side effects like scheduling changes or permissions, which would be needed for full 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?

The description is concise, with a clear purpose sentence followed by a necessary caveat and structured argument list. Every sentence adds value without redundancy.

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?

For a simple two-parameter tool with an output schema presumably handling return values, the description completely covers what the tool does, its scope, and how to prepare inputs. No gaps remain.

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?

With 0% schema description coverage, the description compensates by clearly defining both parameters: card_ids as card IDs to move, and deck with an example hierarchical name. It adds context about card vs note IDs, aiding correct usage.

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 explicitly states it moves cards into a different deck, specifies it operates on card IDs, and contrasts with note-level operations. This clearly distinguishes it from siblings like add_note and inspect_cards.

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

Usage Guidelines5/5

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

It provides explicit guidance: use card IDs, and if only note IDs are available, first call inspect_cards. It explains the rationale (cards from a note can be in different decks) and implicitly warns against misuse. This is excellent usage context.

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

fetch_due_cards_for_reviewA

Fetch cards due for review, formatted for an LLM to present.

Args:
    deck: Optional[str] - Filter by specific deck name.
    limit: int - Maximum number of cards to fetch (default 5).
    today_only: bool - If true, only fetch cards due today. If false, fetch cards due up to MAX_FUTURE_DAYS ahead (currently {MAX_FUTURE_DAYS}).
ParametersJSON Schema
NameRequiredDescriptionDefault
deckNo
limitNoMax cards to fetch.
today_onlyNoTrue=only today's cards, False=cards due up to MAX_FUTURE_DAYS ahead.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

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

No annotations provided, so description bears full burden. It explains the today_only behavior and output formatting, but lacks statements on read-only nature, side effects, rate limits, or authentication needs.

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?

Concise, front-loaded with main purpose, then clear argument list. Every sentence adds value; no fluff. Placeholder for MAX_FUTURE_DAYS is efficient.

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?

Good coverage of parameter details and output format. However, lacks context on when to use relative to siblings and missing behavioral traits like idempotency or data source, given no annotations and output schema not shown.

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?

Schema coverage is 67%, but the description adds detail beyond schema (e.g., deck filter as 'specific deck name', today_only with MAX_FUTURE_DAYS). Only minimal repetition of existing schema 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 name and description clearly state the tool fetches cards due for review, formatted for LLM presentation. It distinguishes from sibling tools like submit_reviews or inspect_cards by specifying its purpose.

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?

Description implies usage for getting cards to review but does not explicitly state when to use versus alternatives, nor does it provide exclusions or prerequisites.

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

get_examplesA

Get example notes from Anki to guide your flashcard making. Limit the number of examples returned and provide a sampling technique:

    - random: Randomly sample notes
    - recent: Notes added in the last week
    - most_reviewed: Notes with more than 10 reviews
    - best_performance: Notes with less than 3 lapses
    - mature: Notes with interval greater than 21 days
    - young: Notes with interval less than 7 days

Args:
    deck: Optional[str] - Filter by specific deck (use exact name).
    limit: int - Maximum number of examples to return (default 5).
    sample: str - Sampling technique (random, recent, most_reviewed, best_performance, mature, young).
ParametersJSON Schema
NameRequiredDescriptionDefault
deckNo
limitNo
sampleNoSampling technique: random, recent (added last 7d), most_reviewed (>10 reps), best_performance (<3 lapses), mature (ivl>=21d), young (ivl<=7d)random

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, but the description clearly indicates a read-only operation (getting examples). It does not disclose permissions or side effects, but for a retrieval tool, this is acceptable.

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 well-organized with a brief intro, a bulleted list of sampling techniques, and an args section. It is efficient but could be slightly more concise by removing redundant wording.

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 the tool's complexity (3 parameters, no annotations, output schema exists), the description adequately covers purpose and parameter details. It does not discuss return format, but the output schema likely handles that.

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?

The description adds significant meaning beyond the schema: it explains the purpose of each parameter (deck as exact name, limit as maximum, sample with detailed technique definitions). Schema coverage is only 33%, so the description fully compensates.

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 'Get example notes from Anki to guide your flashcard making', specifying the action and resource. It distinguishes from sibling tools like search_notes by focusing on high-quality examples.

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 explains parameters and sampling techniques but does not explicitly state when to use this tool versus alternatives like search_notes. Usage context is implied but lacks explicit when-not guidance.

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

inspect_cardsA

Inspect per-card state with sparse fieldset selection.

Provide EXACTLY ONE of `card_ids` or `note_ids`. When `note_ids` is given,
the tool resolves to all cards belonging to those notes via an `nid:` query.

Use `properties` to pick which categories of information to return. The
default keeps responses small; opt into the heavier categories explicitly.

Property categories:
  - `identity` — cardId, noteId, deck, modelName
  - `state` — suspended, queue, queue_label, type
  - `scheduling` — ease, interval, reps, lapses, raw_due
  - `timestamps` — modified_iso, last_review_iso (the latter only with `history`)
  - `history` — full review log (extra AnkiConnect call). Each entry has
    an ISO timestamp, an "again"/"hard"/"good"/"easy" rating, interval in
    days, and time taken in ms.
  - `fields` — cleaned, non-empty note field content (extra `notesInfo`
    round trip). Image Occlusion notes collapse to a single placeholder.
  - `all` — shorthand for every category above.

Default when `properties` is None: `["identity", "state", "scheduling"]`.

`include_history=True` is kept as a soft-deprecated alias — equivalent to
adding `"history"` to `properties`. Prefer the new param going forward.

Args:
    card_ids: List of card IDs to inspect.
    note_ids: List of note IDs; expands to every card on those notes.
    properties: List of property categories to include.
    include_history: Soft-deprecated alias for `properties=["history", ...]`.
ParametersJSON Schema
NameRequiredDescriptionDefault
card_idsNo
note_idsNo
propertiesNo
include_historyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

No annotations provided, so description carries full burden. It details extra API calls for history and fields, soft-deprecated alias behavior, and note collapse for Image Occlusion. It implicitly indicates read-only nature. No contradictions.

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 well-structured with a purpose statement, constraints, and a bulleted list of property categories. It is slightly lengthy but each part serves a purpose. Front-loaded with key constraint. Good balance.

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 4 parameters with 0% schema coverage, 13 sibling tools, and an output schema, the description covers all necessary aspects: parameter constraints, defaults, property explanations, behavior for note_ids, and deprecated alias. It does not need to explain return values due to output schema. Complete.

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 coverage is 0%, so description must compensate. It explains each parameter: exclusive usage of card_ids/note_ids, expansion with note_ids, property categories with explicit list and meanings, and include_history as alias. This adds significant value beyond the bare 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 the tool's purpose: 'Inspect per-card state with sparse fieldset selection.' The verb 'inspect' and resource 'per-card state' are specific. The sibling tools include mutations like add_note and search_notes, making this read-only inspection distinct.

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 clear usage guidelines: 'Provide EXACTLY ONE of card_ids or note_ids' and explains how note_ids resolves to cards. It defaults properties and notes a deprecated alias. However, it lacks explicit exclusion of alternatives (e.g., when to use search_notes instead).

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

list_decks_and_notesC

Get all decks (excluding specified patterns) and note types with their fields.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
Behavior2/5

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

No annotations provided, so description bears full burden. It claims to exclude patterns but no parameters exist, creating ambiguity. No disclosure about potential large data volumes or performance implications.

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?

Very concise single sentence, but the phrase 'excluding specified patterns' adds confusion without corresponding parameters. It could be more accurate.

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?

With zero parameters and an output schema present, the description covers the basics. The only gap is the unclear 'excluding specified patterns' which is not supported by the schema.

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?

No parameters, but description introduces a misleading expectation of pattern exclusion. Schema coverage is trivial, and the description doesn't compensate for the missing parameter behavior.

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 retrieves all decks and note types with fields. It mentions 'excluding specified patterns' which is confusing given no parameters, but overall the purpose is specific and distinct from siblings like search_notes or fetch_due_cards_for_review.

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. Sibling tools exist for searching or filtering, but the description doesn't help an AI agent decide.

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

num_cards_due_todayB

Get the number of cards due exactly today, with an optional deck filter.

ParametersJSON Schema
NameRequiredDescriptionDefault
deckNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/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 carry the full burden. It only states the basic purpose but does not disclose whether the operation is read-only, has side effects, or any performance considerations. The return format is not described, although an output schema exists.

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, concise sentence that front-loads the purpose and includes the key optional filter. No unnecessary words.

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 (1 parameter, count output), the description covers the basic purpose and filter option. However, it lacks behavioral context (e.g., if it returns 0 for none) and does not leverage the output schema to explain return values. The presence of an output schema mitigates but does not fully compensate.

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 only parameter 'deck' has 0% schema description coverage. The description adds that it is an optional filter, but does not specify whether it expects a deck name or ID, or any format details. More information would be beneficial.

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 purpose: 'Get the number of cards due exactly today' with an optional deck filter. It uses a specific verb 'get' and resource 'number of cards due today', and distinguishes from sibling tools like 'fetch_due_cards_for_review' that return full cards.

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 with the optional deck filter, but does not explicitly state when to use this tool versus alternatives like 'fetch_due_cards_for_review' or 'inspect_cards'. No when-not-to-use guidance is provided.

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

reschedule_cardsA

Manipulate the scheduling state of one or more cards.

Modes:
- `set_due`: Set the cards' due date. Requires `due`. Accepts AnkiConnect's
  `setDueDate` spec:
    * "1"   → due 1 day from now
    * "1-7" → randomly due between 1 and 7 days from now
    * "3!"  → due in 3 days AND reset interval to 3
- `forget`: Reset cards to the "new" queue (re-enters the learning pipeline).
- `relearn`: Move cards into the relearning queue.

Args:
    card_ids: Card IDs to reschedule.
    mode: One of "set_due", "forget", "relearn".
    due: Required for `mode="set_due"`; ignored otherwise.
ParametersJSON Schema
NameRequiredDescriptionDefault
card_idsYes
modeYes
dueNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 full burden. It explains the effects of each mode (e.g., forget resets to new queue, relearn moves to relearning queue) but does not mention potential side effects or permissions.

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 concise and well-structured, front-loading the purpose and using clear formatting for modes and args without any unnecessary information.

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?

The description covers all parameters and modes effectively. Given the existence of an output schema, return values need not be explained. However, it could provide more context on when to choose each mode.

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?

Despite 0% schema description coverage, the description explains all three parameters in detail, especially the due format spec, which adds significant meaning beyond the schema's type definitions.

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 manipulates scheduling state of cards, with specific modes (set_due, forget, relearn) that distinguish it from sibling tools like add_note or change_deck.

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 detailed guidance on modes and the due format, but does not explicitly compare to sibling tools or state when not to use it.

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

search_notesA

Search for notes in Anki using the powerful built-in search syntax.

This tool allows you to find existing notes/flashcards using Anki's query language.
Results include note IDs which can be used for follow-up actions.

Tiered access — call this first to narrow by query, then drill in by ID:
- Default (`return_card_content=False`): cheap response with noteId + a
  ~80-char Front preview, so you can pick which IDs matter.
- `return_card_content=True`: full cleaned field content for every match.
- For scheduling/state details (queue, ease, interval, lapses, review
  history) on specific IDs, call `inspect_cards(note_ids=[...])`. Pass
  `properties=["fields"]` there if you also want the cleaned note content
  alongside the per-card stats in one call.

## Common Search Patterns

**Simple text search:**
- `dog` - notes containing "dog" (matches "doggy", "underdog")
- `dog cat` - notes with both "dog" AND "cat"
- `dog or cat` - notes with "dog" OR "cat"
- `-cat` - notes WITHOUT "cat"
- `"a dog"` - exact phrase match
- `w:dog` - whole word match only

**Field-specific search:**
- `front:dog` - Front field exactly equals "dog"
- `front:*dog*` - Front field contains "dog"
- `front:` - Front field is empty
- `front:_*` - Front field is non-empty

**Deck and tag filters:**
- `deck:French` - cards in French deck (including subdecks)
- `deck:French -deck:French::*` - only top-level French deck
- `tag:vocab` - notes with "vocab" tag
- `tag:none` - notes without any tags
- `note:Basic` - notes using "Basic" note type

**Card state:**
- `is:due` - cards due for review
- `is:new` - new cards not yet studied
- `is:learn` - cards in learning phase
- `is:review` - review cards
- `is:suspended` - suspended cards
- `is:buried` - buried cards

**Card properties:**
- `prop:ivl>=10` - interval >= 10 days
- `prop:due=0` - due today
- `prop:due=1` - due tomorrow
- `prop:lapses>3` - lapsed more than 3 times
- `prop:ease<2.5` - easier than default
- `prop:reps<10` - reviewed fewer than 10 times

**Recent activity:**
- `added:7` - added in last 7 days
- `edited:3` - edited in last 3 days
- `rated:1` - answered today
- `rated:7:1` - answered "Again" in last 7 days
- `introduced:30` - first answered in last 30 days

**Combining searches:**
- `deck:Spanish tag:verb is:due` - due Spanish verbs
- `added:7 -is:review` - new cards added this week
- `(dog or cat) deck:Animals` - dog or cat in Animals deck

Args:
    query: The Anki search query string.
    limit: Maximum notes to return (1-100, default 20).
    return_card_content: If True, returns full cleaned field content per
        note. If False (default), returns a short Front preview per note.

Returns:
    JSON object with `query`, `total_found`, `returned`, and `notes`.
    Each note has `noteId`, `modelName`, `tags`, and either `preview`
    (default) or `fields` (when `return_card_content=True`).
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesAnki search query string
limitNoMaximum number of notes to return
return_card_contentNoIf False (default), each result returns noteId/modelName/tags plus a short cleaned preview of the Front field. If True, each result returns cleaned, non-empty field content for the whole note.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

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

The description explains that results include note IDs for follow-up actions, describes the difference between return_card_content=false (preview) and true (full fields), and references inspect_cards for state details. However, it does not mention any potential limitations on query complexity or rate limits, though as a search tool, destructive behavior is not 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 thorough but well-structured with clear sections: an overview, tiered access guidance, and a comprehensive search pattern reference. It is front-loaded with key usage instructions. The length is justified by the complexity of the query syntax, but some redundancy could be trimmed.

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 tool's complexity, the description fully covers input parameters (with examples), output format (referenced to output schema), and usage scenarios. It provides a complete guide for the agent to use the tool effectively, including boundaries for when to switch to sibling tools.

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 coverage is 100% (all parameters documented in schema). The description adds significant meaning: it explains the query parameter with dozens of search pattern examples, clarifies the limit default and range, and elaborates on the return_card_content parameter's effect on output.

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 it's for searching notes in Anki using a built-in search syntax. It specifies the verb 'search' and the resource 'notes', and distinguishes itself from sibling tools like inspect_cards by explaining 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 Guidelines5/5

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

Provides explicit guidance on tiered access: using the tool with default parameters for cheap preview, then drilling into specific IDs, and when to call inspect_cards for scheduling details. Also includes extensive search pattern examples, making it clear when to use different query constructs.

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

set_suspendedA

Suspend or unsuspend one or more cards.

Args:
    card_ids: Card IDs to act on (not note IDs).
    suspended: True to suspend, False to unsuspend.
ParametersJSON Schema
NameRequiredDescriptionDefault
card_idsYes
suspendedYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the burden. It mentions that card_ids are not note IDs, which is a useful behavioral note. However, it does not disclose side effects like whether suspended cards are hidden from reviews or any idempotency guarantees.

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: one sentence stating purpose, followed by a structured Args list. No wasted words.

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?

For a simple tool with 2 parameters and an output schema (not needing return value explanation), the description adequately covers purpose and parameter semantics. Minor omission: no mention of idempotency or what happens after suspension.

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?

The description adds meaning beyond the schema by explaining each parameter's role, including the critical clarification that card_ids refer to card IDs, not note IDs. This helps avoid misuse.

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 action (suspend or unsuspend) and the resource (one or more cards). It distinguishes from sibling tools that perform different actions like adding notes or fetching due 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 explicit guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions. It only implies usage through the action description.

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

store_media_fileA

Store an image or media file in Anki's media folder.

Use this tool to store images that can be referenced in flashcard fields using
HTML img tags: <img src="filename">

This is useful when you need to:
- Store an image before creating a note (e.g. to reference it in multiple notes)
- Add an image to an existing card's field

Provide exactly one of url, data, or path:
- path: Absolute path to a local file. PREFERRED when the user shares an image file or screenshot.
- url: A URL to download the image from (e.g. "https://example.com/photo.jpg")
- data: Base64-encoded file content (for small images only)

IMPORTANT: When a user shares an image file or screenshot, prefer using "path" with the absolute
file path. AnkiConnect reads the file directly from disk, which avoids needing to base64-encode
large image files.

Args:
    filename: str - The filename to store the media as (e.g. "diagram.png").
    url: str - Optional URL to download the image from.
    data: str - Optional base64-encoded image data.
    path: str - Optional absolute path to a local file. Preferred for user-shared files.
ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
urlNo
dataNo
pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description explains the tool reads from disk, downloads from URL, or decodes base64. It specifies exactly one of url/data/path must be provided. It doesn't detail error handling but covers core behavior well.

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 well-structured with bullet points and clear sections, though slightly verbose. It front-loads purpose and usage, then dives into parameter details. Every sentence adds value.

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 4 parameters (1 required) and an output schema, the description covers usage scenarios and parameter selection adequately. Return value is not explained but output schema exists. The description is complete for typical use cases.

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 0%, so the description adds crucial meaning: explains each parameter's role, preferred use cases (path for user files, data for small images), and the constraint of providing exactly one. This fully compensates for the schema's lack of 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 stores an image or media file in Anki's media folder for use in flashcards via HTML img tags. It distinguishes itself from sibling tools like add_note or update_note_fields by focusing on media storage.

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 when to use the tool (before creating a note, adding to existing cards) and detailed guidance on which parameter to use (path preferred for user-shared files, data for small images). It does not explicitly state when not to use it but gives clear context.

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

submit_reviewsA

Submit multiple card reviews to Anki using ratings ('wrong', 'hard', 'good', 'easy').

Args:
    reviews: List of review dictionaries, each with:
        - card_id (int): The ID of the card reviewed.
        - rating (str): 'wrong', 'hard', 'good', or 'easy'.
ParametersJSON Schema
NameRequiredDescriptionDefault
reviewsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It states 'submit' implying mutation, but lacks details on side effects (e.g., scheduling updates, error handling) or prerequisites (e.g., card existence). This is insufficient for safe tool invocation.

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 short and front-loaded with a clear purpose sentence. The args are documented in a structured list. No redundant information, but could be slightly more concise (e.g., inline enum values).

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?

The tool has an output schema which may document return values, but the description does not mention what it returns (e.g., success status, count). Additionally, it lacks context on prerequisites (e.g., Anki must be running, card must exist). Given the complexity, more completeness is warranted.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning by listing each field and its allowed values (card_id integer, rating enum), explaining the ratings. This adds value beyond the raw schema, though further details like required ratings context could improve.

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 verb 'submit' and the resource 'multiple card reviews to Anki' with explicit rating values. This distinguishes it from sibling tools like 'fetch_due_cards_for_review' which is about fetching, not submission.

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 after fetching due cards, but does not explicitly state when to use this tool over alternatives or provide exclusions. No guidance on prerequisites or when not to use.

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

update_note_fieldsB

Update the text content of one or more fields on an existing note.

Only fields you pass in are changed; omitted fields are left alone. MathJax
(`<math>...</math>`) and code blocks/inline code are auto-converted to the
same HTML representations used by `add_note`.

Args:
    note_id: Anki note ID (not a card ID).
    fields: Mapping of field name -> new value.
ParametersJSON Schema
NameRequiredDescriptionDefault
note_idYes
fieldsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries full behavioral burden. It discloses partial update behavior and auto-conversion of content, but omits potential side effects, validation, or error handling. Provides useful context but lacks depth.

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 concise at 5 sentences, with main purpose front-loaded. It efficiently covers partial updates, conversion behavior, and parameter descriptions. Minor redundancy could be removed.

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 output schema exists, return values aren't needed. The description covers core behavior and parameters but lacks information on error conditions (e.g., invalid note_id) or field validation. Adequate but not exhaustive.

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 0%, so description must compensate. It provides basic explanations for both parameters (note_id and fields), including that note_id is not a card ID and fields is a mapping. This adds meaning but is minimal; more detail could be given.

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 updates text content of fields on a note, using specific verb and resource. It mentions 'update' and 'fields on an existing note', which distinguishes it from sibling tools like update_note_tags, though it does not explicitly differentiate.

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 notes that MathJax and code blocks are auto-converted similarly to add_note, implying a use case, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No guidance on when not to use it.

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

update_note_tagsA

Add and/or remove tags on one or more notes.

Tags MUST NOT appear in both `add` and `remove`. At least one of the two lists
must be non-empty.

Args:
    note_ids: Note IDs to modify.
    add: Tags to add (each tag should not contain spaces).
    remove: Tags to remove.
ParametersJSON Schema
NameRequiredDescriptionDefault
note_idsYes
addNo
removeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

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

The description explains the basic behavior (add/remove tags) and constraints, but lacks details on what happens if a tag already exists or doesn't exist, error handling, or idempotency. Without annotations, the description should cover more behavioral aspects.

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 concise with two short paragraphs, front-loaded with the purpose. The arguments section is clear and every sentence serves a purpose without redundancy.

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?

For a simple tool with 3 parameters and an output schema, the description covers constraints and parameter semantics well. Minor gaps include error scenarios and idempotency, but overall it's adequate for an AI agent to use correctly.

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?

The description adds meaning to each parameter: 'note_ids' are IDs to modify, 'add' tags must not contain spaces, and 'remove' tags to remove. Since schema coverage is 0%, this compensates well, though it could mention expected formats.

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 adds and/or removes tags on one or more notes. It specifies the exact action (update tags) and resource (notes), distinguishing it from sibling tools like update_note_fields which handle other fields.

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 clear constraints: tags must not appear in both 'add' and 'remove', and at least one list must be non-empty. It does not explicitly mention when not to use this tool or alternatives, but the context of siblings implies this is the go-to for tag modifications.

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. 7 tool updatesv0.7.0
    • Addedchange_deck
    • Addedinspect_cards
    • Addedreschedule_cards
    • Changedsearch_notes1 field changed
      • addedInput schema / properties / return_card_content
        Added value: +{
+  "default": false,
+  "description": "If False (default), each result returns noteId/modelName/tags plus a short cleaned preview of the Front field. If True, each result returns cleaned, non-empty field content for the whole note.",
+  "title": "Return Card Content",
+  "type": "boolean"
+}
    • Addedset_suspended
    • Addedupdate_note_fields
    • Addedupdate_note_tags
  2. 4 tool updatesv0.6.0
    • Addedadd_note
    • Addedsearch_notes
    • Addedstore_media_file
    • Addedsubmit_reviews
  3. 4 tool updates
    • Removedadd_note
    • Removedsearch_notes
    • Removedstore_media_file
    • Removedsubmit_reviews
  4. 8 tool updatesv0.5.0
    • Changedadd_note2 fields changed
      • addedInput schema / properties / picture
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            }
+          ]
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Picture"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "add_noteOutput",
+  "type": "object"
+}
    • Changedfetch_due_cards_for_review1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "fetch_due_cards_for_reviewOutput",
+  "type": "object"
+}
    • Changedget_examples1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_examplesOutput",
+  "type": "object"
+}
    • Changedlist_decks_and_notes1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "list_decks_and_notesOutput",
+  "type": "object"
+}
    • Changednum_cards_due_today1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "num_cards_due_todayOutput",
+  "type": "object"
+}
    • Changedsearch_notes1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "search_notesOutput",
+  "type": "object"
+}
    • Addedstore_media_file
    • Changedsubmit_reviews1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "submit_reviewsOutput",
+  "type": "object"
+}
  5. 1 tool updatev1.0.0
    • Addedsearch_notes
  6. 6 tool updates
    • First observedadd_note
    • First observedfetch_due_cards_for_review
    • First observedget_examples
    • First observedlist_decks_and_notes
    • First observednum_cards_due_today
    • First observedsubmit_reviews
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct functionality: adding notes, moving decks, fetching reviews, inspecting cards, searching, storing media, etc. There is no overlap or ambiguity between tools.

Naming Consistency4/5

Most tools follow a verb_noun pattern in snake_case (e.g., add_note, search_notes). One tool (num_cards_due_today) uses 'num' as a prefix instead of a verb, and list_decks_and_notes uses 'and', but overall the pattern is consistent.

Tool Count5/5

14 tools is well-scoped for an Anki integration, covering adding, editing, searching, reviewing, scheduling, and media management without being excessive or too sparse.

Completeness3/5

The tools cover core workflows (add, edit, review, search, inspect) but lack deletion operations (no delete_note or delete_card) and deck/note type creation. These gaps limit full lifecycle management.

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

Appeared in Searches

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/samefarrar/mcp-ankiconnect'

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