Loading ToolBench
Model Context Protocol server for Anki - enables AI assistants to interact with your Anki flashcards
The server provides 10 tools with reasonable coverage for Anki interactions. Tool names follow verb_noun convention (addNote, addNotes, createDeck, etc.), which is correct. Most tools have descriptions ranging from 100-300 characters, which is within the 10-1024 character baseline. However, there are significant gaps in parameter documentation, output schema clarity, and error handling guidance. Input schemas are visible and mostly well-formed with type declarations, but several tools have minimal or missing parameter descriptions. The server implements toolAnnotations (readOnlyHint/destructiveHint), which is a positive signal for protocol readiness. Overall, tools are functional but lack the LLM-optimized descriptions and comprehensive error guidance expected of production-grade tools.
Add a new field to an existing Anki note type (model). The field is appended to the end by default, or inserted at a specific position. Existing notes of this type will have the new field set to empty. Use modelFieldNames to see current fields before adding.
Add a SINGLE note to Anki. To create multiple notes, use the addNotes batch tool instead of calling addNote repeatedly — AnkiConnect processes requests one at a time, so repeated (especially parallel) addNote calls are slower and unnecessary. Use modelNames to see available note types and modelFieldNames to see required fields. Returns the note ID on success. IMPORTANT: Only create notes that were explicitly requested by the user.
Add multiple notes to Anki in a single batch — the preferred way to create more than one note (use this instead of repeated addNote calls). Up to 100 notes sharing the same deck and model. Duplicates are skipped individually; validation errors (empty required fields, bad tags) reject the batch. IMPORTANT: Only create notes that were explicitly requested by the user.
Add tags to specified notes. Tags is a space-separated string (e.g., "tag1 tag2 tag3"). Use getTags first to discover existing tags and prevent duplication.
Check whether cards are suspended, without changing anything. Card IDs (not note IDs) — use get_cards, get_due_cards, or notesInfo to obtain them. The response preserves input order; a card ID that doesn't exist comes back with suspended: null rather than being dropped or throwing, so a single bad ID doesn't fail the whole batch.
Several tools lack descriptive documentation of output schemas. Tools like addNote, addNotes, and createModel do not explicitly describe what fields are returned or how to use the response in downstream calls.
Parameter descriptions are sparse or missing in multiple tools. For example, 'duplicateScope' in addNote and addNotes is described only as 'Scope for duplicate checking' with no explanation of valid enum values or when to use it.
Error handling guidance is absent. Tools like clearUnusedTags and changeDeck lack documentation of failure modes (e.g., 'What if the target deck doesn't exist?') or recovery steps an LLM should take.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 65 | - | v1 |
Move cards to a different deck. Target deck will be created if it doesn't exist.
Remove orphaned tags that are not used by any notes in the collection. CRITICAL: This is destructive and permanent - only run when the user explicitly asks to clean up tags.
Get aggregated statistics across all decks in the collection including card counts, ease factor distribution, and interval distribution. Returns TWO different views, do not mix them up: `counts` and `per_deck` are today's study queue as shown in Anki's deck browser (cards DUE TODAY, capped by each deck's daily new/review limits, suspended/buried excluded); `states` is the true number of cards in each state (new / learning / review / suspended / buried) across the whole collection, ignoring due dates and daily limits. To answer "how many cards do I have" use `states`; to answer "what will I study today" use `counts`. Per-deck counts are rolled up over descendants (a parent deck includes its children); collection-level `counts` sum the ROOT decks only to avoid double-counting children. `states` is collection-wide only (it costs 5 additional Anki searches per call) — call the `deckStats` tool for a single deck's true state counts. For every deck and for the collection: Expect new + learning + review + other ≈ total, but not exact; the scheduler limits daily study to per-deck maximums, which can cause the sum to differ from the actual total, especially when sub-decks are also limited. Ease buckets and interval buckets can be customized to focus on specific ranges.
Create a new empty Anki deck. Use "::" for parent::child structure (max 2 levels, e.g., "Japanese::JLPT N5"). Will not overwrite existing decks.
Create a new note type (model) in Anki with custom fields, card templates, and styling. Useful for creating specialized models like RTL (Right-to-Left) language models for Hebrew, Arabic, etc. Each model defines the structure of notes and how cards are generated from them.
Destructive operations (clearUnusedTags, deleteNotes if present) lack confirmation or dry-run support. The description warns 'CRITICAL: This is destructive' but offers no confirmation pattern or undo mechanism.
Parameter type constraints are not fully documented. 'duplicateScopeOptions' in addNote/addNotes is declared as 'object' with no schema showing what fields it accepts or what values are valid.
Tool naming uses snake_case in one tool (collection_stats) while others use camelCase (addNote, createModel). Inconsistency may confuse LLM tool selection.