Loading ToolBench
Dynamic Anki MCP Server for intelligent flashcard management
Anki Kashikoi MCP has 4 tools with explicit definitions in src/services/anki-mcp-server.ts. Tool names use verb_noun structure (analyze_deck, add_card, get_configured_decks, set_default_deck), which is good for LLM parsing. However, descriptions are extremely brief (11-50 chars), leaving critical context missing. Input schemas are present and properly typed, but parameter descriptions are minimal or absent for complex objects. The server lacks output schema documentation, error guidance, pagination support, and composition patterns. No tool annotations (readOnlyHint/destructiveHint) despite clear WRITE vs READ_ONLY risk classifications. Error handling throws McpError but provides minimal recovery guidance. The add_card tool accepts a generic 'content' object with type 'object' but no documented structure, forcing LLMs to guess field names. Overall definition quality is below community baseline due to insufficient descriptions and schema completeness.
Add a card to Anki using field names directly
Analyze a deck and save its configuration
Get information about configured decks
Set the default deck for adding cards
analyze_deck, add_card, and set_default_deck have descriptions under 50 characters. 'Analyze a deck and save its configuration' (52 chars) barely exceeds minimum; 'Add a card to Anki using field names directly' (47 chars) and 'Set the default deck for adding cards' (37 chars) lack context on WHEN to use them vs alternatives, prerequisites, or state-changing consequences.
add_card tool's 'content' parameter has type 'object' with description 'Card content with field names as keys' but NO schema for that object, no documented field names, types, required fields, or examples. LLMs cannot infer field structure and will hallucinate field names, causing runtime failures.
No output schemas documented for any tool. Tool responses are ToolResponse objects with 'content' array, but LLMs do not know what fields to expect from get_configured_decks, analyze_deck, etc. This prevents chaining and forces LLMs to parse unstructured text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Error handling in add_card catches config load failure but returns generic McpError with no recovery guidance. Example: 'No configuration found. Please run analyze_deck first to configure a deck.' is helpful, but other error branches (line ~142) throw raw errors without actionable next steps.
Tool definitions in ListToolsRequestSchema registration lack annotations for WRITE vs READ_ONLY operations. analyze_deck, add_card, and set_default_deck are destructive/stateful but carry no destructiveHint or idempotentHint metadata. This prevents clients from warning users or implementing confirmation patterns.
get_configured_decks has no pagination or limit parameters despite potentially returning unbounded deck lists. Very large deck counts could exhaust token budgets. No documented result cap or continuation mechanism.