anki-librarian-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_decksA | List all decks and which of them this server may write to. |
| find_notesA | Search notes with Anki search syntax (e.g. 'deck:Economics tag:Economics::Macro inflation'). Returns note ids, model, decks, tags and field excerpts. |
| get_notesC | Full fields and tags of up to 100 notes. |
| propose_add_notesA | Dry run for adding basic (front/back) notes, one or many. Searches the collection first: exact duplicates are skipped, 'same front, different back' is left for the user, similar fronts are flagged, tags are checked against the taxonomy. Nothing is written: call apply_plan after the user sees it. |
| propose_add_cloze_notesB | Dry run for adding cloze notes (one or many); cloze syntax is validated for the whole batch. |
| propose_update_noteA | Dry run for editing one note's fields and/or replacing its tags. Shows a before/after diff. If the note changes in Anki before apply_plan, the plan is refused (no stale writes). |
| propose_create_deckC | Dry run for creating a deck (only inside the writable decks). |
| propose_delete_notesA | Dry run for deleting notes (and their review history). Off unless the user enabled it in the config; at most 50 ids, no delete-by-query. |
| propose_set_due_dateA | Dry run for rescheduling cards (Anki's set due date, e.g. days='0' or '1-3'). Off unless enabled. |
| propose_flag_cardsA | Dry run for flagging cards with an agent color (default: 4 blue, or 0 to clear one the agent set). Cards carrying a flag the user set are skipped, never overwritten. |
| list_plansC | Plans and their status (pending, approved, applied, rejected, expired, invalid, failed). |
| apply_planA | Write an approved plan to Anki and read it back to confirm. If the plan is still pending, the server asks the user to approve it (the model cannot approve on the user's behalf). |
| reject_planC | Discard a plan the user does not want. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct action and resource: read tools (list_decks, find_notes, get_notes), propose tools for different mutations (add notes, add cloze, update, create deck, delete, set due date, flag), and plan lifecycle tools (list_plans, apply_plan, reject_plan). find_notes (search excerpts) vs get_notes (full fields) are clearly separated, and the propose_* tools differ by object and operation.
Strong, predictable verb_noun pattern throughout, with a consistent propose_* prefix for dry runs and matching apply_plan/reject_plan lifecycle verbs. Minor deviations like singular vs plural (propose_update_note vs propose_add_notes) keep it just short of perfect.
13 tools is well-scoped for the Anki domain. The propose/apply split is intentional and each tool earns its place by covering a specific mutation or query without redundancy.
Covers a full lifecycle: deck/note discovery, note and cloze creation, updates, deletion, scheduling, flagging, and plan management. Minor gaps like moving notes between decks or deleting decks are absent but not blocking for core workflows.