Loading ToolBench
A Model Context Protocol (MCP) server that enables LLMs to interact with Anki flashcard software through AnkiConnect
This MCP server demonstrates solid fundamentals across 16 tools with consistent schema and description coverage. All tools have explicit schemas visible in src/mcpToolSchemas.ts with proper JSON Schema types. Descriptions are present and generally actionable (averaging ~150 chars), following the 50-200 char baseline for LLM optimization. Tool naming is consistently verb-noun (anki_create_note, anki_delete_note, etc.), which aids LLM intent inference. However, several gaps prevent a higher score: (1) parameter descriptions lack detail on constraints (e.g., no regex patterns stated in descriptions despite being present in schemas); (2) no explicit error recovery guidance for failed operations; (3) output schemas are not formally documented in descriptions; (4) batch operations (anki_batch_create_notes) lack clear stopping-on-error semantics in descriptions; (5) some tool descriptions could better explain when to use similar tools (e.g., distinction between anki_add_note_tags vs anki_update_note for tag modification). The server shows strong composition discipline (tools do one thing each, results chain via IDs), but lacks the polish that would elevate it to 80+.
Use when the user wants to add one or more tags to existing notes for organization. Do not use when the user wants to remove tags (use anki_remove_note_tags) or update note content (use anki_update_note). Safety: confirm before adding tags to a large number of notes.
Use when the user wants to create multiple study cards (notes) in one operation. Supports up to 50 notes per request. For single notes, use anki_create_note. Optional stopOnError mode stops processing on first failure (default: creates all possible notes and reports failures). Safety: confirm with the user before batch creating a large number of notes.
Check whether AnkiConnect is reachable and return the API version.
Create an Anki deck by name.
Use when the user wants to create a single new study card (note) in an existing deck. Creates user study content — not a schema change. Do not use when the user only wants to inspect existing notes, decks, tags, or note types. To define a new note structure, use anki_create_note_type instead. Call anki_get_note_type_info first for custom fields. For multiple notes, use anki_batch_create_notes. Safety: confirm with the user before creating notes if intent is unclear.
Parameter constraint descriptions lack verbosity. Schemas contain minLength, pattern, and minimum/maximum constraints, but descriptions do not restate these in human-readable form. LLMs cannot parse JSON Schema patterns, they rely on description text to understand constraints (e.g., 'Tags to add. Use Anki tag names without whitespace.' should explicitly state: 'Tags must contain no spaces (pattern: ^\S+$)').
Output schemas are not formally documented in tool descriptions or code comments. While implementations return structured responses (visible in mcpToolResponses.ts), the schema descriptions do not state what fields will be returned or in what format. This forces LLMs to infer output structure from execution rather than planning ahead.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Create a new custom note type (model) with specified fields and card templates. Call this only when the user wants to define a new schema. Do not use when creating notes with existing types (use anki_create_note instead).
Delete one or more notes permanently from the collection. Safety: confirm with the user before deleting notes, as this action cannot be undone.
Get detailed information about a specific note including fields, tags, and model.
Use when inspecting a note type before creating or updating notes, especially for non-standard models. Returns fields and card templates. Call this before anki_create_note when using a custom note type. Do not use when the user wants to create notes or modify a note type.
List all available Anki decks, optionally with deck IDs.
List all available Anki note types/models.
List all tags currently used in the Anki collection.
Use when the user wants to remove specific tags from one or more existing notes. Do not use when the user wants to add tags (use anki_add_note_tags) or clear all tags (use anki_update_note with an empty tags array). Safety: confirm with the user before removing tags, as this modifies note metadata.
Search for notes using Anki's query syntax. Returns matching note IDs and details with pagination support.
Request AnkiWeb sync. Success means Anki accepted the request, not that AnkiWeb completed it.
Update specific fields and/or tags of an existing note. At least one of fields or tags must be provided. Safety: confirm before updating a large number of notes.
Error handling descriptions are absent. Tools like anki_delete_note (IRREVERSIBLE) and anki_batch_create_notes mention 'confirm before' in descriptions, but provide no guidance on what errors might occur or how to recover. Descriptions lack recovery hints like 'If sync fails, check Anki for pending dialogs' or 'If a note creation fails, check deck exists via anki_list_decks'.
Tool descriptions for tag operations do not clearly distinguish when to use anki_add_note_tags vs anki_update_note (which also accepts tags). The descriptions include 'Do not use when...' statements, but an LLM must read all three to understand the distinction. A cross-reference in each description would clarify composition.
anki_batch_create_notes description states 'Optional stopOnError mode stops processing on first failure (default: creates all possible notes and reports failures)' but does not explain the response structure for partial failures. Will the response include per-item success/failure status, or a blanket error if any item fails?