Loading ToolBench
MCP server for managing Anki flashcard decks and notes via AnkiConnect
clanki demonstrates solid definition quality with well-structured tool schemas, descriptive parameter documentation, and proper error handling patterns. All 10 tools have explicit schemas with type definitions and descriptions. Tool naming is clear and action-oriented (create-, update-, delete-, find-, list-). Descriptions average ~150-200 characters, within production baseline (p10=34, p90=392). However, several gaps prevent a higher score: (1) Output schemas are not documented, callers cannot see what these tools return, forcing LLMs to infer structure. (2) Some parameter descriptions lack range/format constraints (e.g., 'noteId' accepts any number with no bounds). (3) Error responses lack recovery guidance, failures tell what went wrong but not how to proceed. (4) Tool composition could be tighter: update-card and update-cloze-card require noteId but find-cards returns noteIds without summaries of actual cards, forcing extra calls. (5) Bulk operations lack per-item failure reporting, making partial failures opaque.
Create multiple basic notes in a single operation
Create multiple cloze notes in a single operation
Create a new note in a specified deck. Supports HTML formatting in text fields. You can attach multiple images and audio files from URLs - they will be automatically downloaded and embedded in the note.
Create a cloze deletion note in a specified deck. Cloze cards hide specific text segments using {{c1::text}}, {{c2::text}}, etc. syntax.
Create a new Anki deck
Delete notes from the collection. Requires explicit confirmation to prevent accidental deletion.
Search for notes in the collection using Anki query syntax
Output schemas not documented. Tools return responses but no schema documentation tells LLMs what fields to expect. Callers cannot plan downstream tool chains or extract required data (e.g., what fields does find-cards return? does it include noteId, deckName, front, back?). LLMs must infer from context or guess.
Numeric parameters (noteId) lack bounds validation. No min/max documented for noteId in update-card and update-cloze-card. LLMs could pass absurdly large or negative IDs, causing silent failures or unexpected behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all available decks in the Anki collection
Update an existing note's fields and tags
Update an existing cloze note's fields and tags
Error responses lack recovery guidance. Code shows error handling (AnkiConnectError, UnconfirmedWriteError) but tool descriptions do not specify error conditions or suggest next steps. An LLM calling find-cards with an invalid query gets a failure but no hint to try a simpler query or consult syntax docs.
Bulk operations lack per-item failure reporting. bulk-create-cards and bulk-create-cloze-cards validate addability and skip rejected notes, but output does not detail which specific cards failed and why. Partial failures are summarized but not itemized, forcing retry of the whole batch.
Tool composition friction: find-cards returns note IDs but update-card and delete-cards expect noteId. Between find-cards and an update, the agent has IDs but no summaries of the actual card content, making it hard to verify which cards matched before modifying them.
list-decks description is vague: 'List all available decks in the Anki collection' (57 chars). Does not explain what metadata is returned per deck (name? size? creation date?) or when to call it relative to create-deck.