Loading ToolBench
Interactive flashcards, quizzes, and cloze cards with spaced repetition for Claude Desktop, as an MCP App (inline UI).
Memora demonstrates solid tool design with clear naming (verb_noun pattern), comprehensive descriptions (100-300 chars typical), and well-structured schemas using Zod. All 8 tools have input schemas with typed parameters and descriptions. Output schema (DECK_OUTPUT) is documented. However, several tools lack error recovery guidance, and some parameter descriptions could be more prescriptive about constraints. Tool composition is excellent, each tool has a single responsibility and outputs chain correctly (e.g., review_deck returns deck names for follow-up study calls). Security is sound: no secrets in parameters, destructive operations clearly marked. Main gaps: missing enum constraints on some string parameters, limited guidance on when to use similar tools (review_deck vs study), and no explicit confirmation pattern for delete_card.
Create (or extend) a flashcard deck from cards you generate based on the user's request or the current conversation. Returns a text summary; it does not open the flip-card review UI (call review_deck or study when the user wants to review). Use "::" in deck_name to nest under a category (e.g. "LLM::Attention"). The deck persists to data/decks.json. Follow Memora's card-quality rules (based on Wozniak's '20 Rules of Formulating Knowledge'). The front is the prompt/question, the back is the answer: 1. Minimum information (atomic): each card tests exactly one fact or concept. Split complex material into several simple cards; never ask for lists or paragraph answers. 2. Concise answers: the back is ideally 1-5 words (a name, date, term, or single concept), never a sentence or paragraph. 3. Active recall: make the front a specific question (not 'Explain X'), or a cloze deletion: write the blank as "[...]" in the front and the hidden term as the back (e.g. front "The Transformer was introduced in [...].", back "2017"). 4. Unambiguous: each front must point to exactly one correct answer. 5. No answer leakage: the front must not already contain or paraphrase the back's text; if answering the front is possible without recalling anything, rewrite it. 6. Not yes/no: avoid true/false-shaped fronts ("Is X...?", "Does X...?"); ask what/which/why/when instead so the answer can't be guessed at 50/50. 7. Prefer application over definition: where the material supports it, phrase the front as a scenario or problem to solve, not a definition to recall.
Create (or extend) a multiple-choice quiz deck. Each card has a question (front), a correct answer (back), and a list of options (including the correct answer). Options are shuffled per card during review so the correct answer doesn't always land in the same slot. Use "::" in deck_name to nest under a category. The deck persists to data/decks.json. Follow the same card-quality rules as create_deck, plus: - Each front is a question (not a definition or statement). - The back is the correct answer (must be one of the options). - Options should be plausible distractors, not obviously wrong. - Avoid options that are subsets/supersets of each other (e.g. "Paris" vs "Paris, France"). - Aim for 3-4 options per question (not 2, not 5+).
delete_card lacks confirmation or dry-run pattern. Destructive operations should support a confirmation step to prevent accidental data loss.
grade_card description does not explain error recovery. What happens if the deck_name or front text doesn't exist? Should the LLM retry or ask the user?
create_deck and create_quiz accept free-form 'cards' arrays without enum constraints on card structure. Descriptions mention card-quality rules but don't validate them at the API boundary.
review_deck and study descriptions do not clearly distinguish when to use each. Both return cards; the distinction (single deck vs category subtree) is buried in the description.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Delete a card from a deck. The card is identified by its front text (unique within the deck). Persists to data/decks.json.
Edit a card's front and/or back text. The card is identified by its current front text (unique within the deck). Editing preserves the card's FSRS scheduling state (due date, stability, difficulty, etc.) so review history is not lost. Persists to data/decks.json. Follow the same card-quality rules as create_deck when rewriting. If you're splitting a card into multiple simpler ones, use refine_card instead (it handles the scheduling transfer correctly).
Grade a card (correct or incorrect) and update its FSRS spaced-repetition schedule. Called by the flip-card UI after the user marks a card correct or missed. Persists the updated schedule to data/decks.json.
Replace a card with one or more new cards, transferring its FSRS scheduling state correctly. Use this when a card is too complex and should be split into simpler atomic cards, or when a card is a leech (repeatedly forgotten) and needs a complete rewrite. If you're replacing with exactly one card (a rewrite), the new card inherits the original's due date, stability, difficulty, and review history, so the card's learning curve is preserved. If you're splitting into multiple cards (2+), the first new card inherits the original's scheduling state, and the rest start as new, unreviewed cards (since one card's stability estimate doesn't transfer to several). The original card is identified by its front text (unique within the deck). Persists to data/decks.json.
Return the flashcards of a single Memora deck and display them as an interactive flip-card review (due cards first). Available decks: "Countries & Capitals". Deck names use "::" to form a category tree; use the study tool to review a whole category. Decks are read live from data/decks.json. Sessions are capped at 20 cards by default (see limit) so a large deck doesn't dump everything at once; the result reports how many cards remain.
Study every card under a category node of the deck tree. Deck names use "::" to nest (e.g. "LLM::Attention"); studying a node reviews all decks at or under that path, merged and shuffled into one session. Omit path to study all decks. Each card stays attributed to its source deck. Sessions are capped at 20 cards by default (see limit) so a big category doesn't dump everything at once; the result reports how many cards remain.
edit_card and refine_card both modify cards but have different semantics (edit preserves schedule, refine transfers it). The distinction is not obvious from names alone.