What can you do with this server?

* Review & study: open a single deck (review_deck) or a whole category subtree (study) as an interactive flip-card UI (flashcards, multiple-choice quizzes, cloze blanks), due cards first. * Create content: generate flashcard/cloze decks (create_deck, with optional reverse for back-to-front cards) and multiple-choice quizzes (create_quiz), optionally appending to existing decks. * Grade & schedule: record review results (grade_card) to update each card's FSRS spaced-repetition schedule. * Manage decks/cards: edit card fronts/backs (edit_card), rename decks (rename_deck), delete individual cards (delete_card) or whole decks (delete_deck). * Get summaries: see what's due today across all decks (due_today), including per-deck due/new counts and struggling cards. * Capture & refine: turn recent mistakes into draft cards (capture) and propose/apply card refinements (refine_card, apply_refinement). * Organize: decks are nested with :: into a category tree; study a branch or browse it as a mind map. * Data: decks are stored as plain JSON (read live, atomically written), no database or external service.

How do I use Memora MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Memora MCP create a deck of 10 Spanish verbs" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

Memora MCP

by Servation

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Memora MCP

License: MIT MCP Apps TypeScript React

Turn any conversation into an interactive study session, right inside Claude Desktop. Ask Claude to make a deck and it generates the cards, then renders them as an inline review you can click through: flip flashcards, answer multiple-choice quizzes, and fill in cloze blanks. Every answer updates a spaced-repetition schedule, and your results flow back to Claude so it can drill what you missed.

Keywords: Model Context Protocol, MCP server, MCP Apps, Claude Desktop, flashcards, quizzes, spaced repetition, SRS, FSRS, Anki alternative.

Built on the MCP Apps extension (SEP-1865): core MCP spec 2025-11-25 plus the Apps extension 2026-01-26.

Three ways to study, rendered inline in Claude

Features

Three ways to study, all rendered inline and all graded the same way:

Flashcards: click to flip, then grade Got it / Missed it.
Multiple-choice quizzes: pick an option and the correct/wrong answers reveal instantly.
Cloze (fill-in-the-blank): the blank reveals in place so the sentence stays intact. Write a blank as [...] in a card front and it becomes a cloze card automatically.

Spaced repetition: every grade updates a per-card FSRS schedule (via ts-fsrs), so weak cards resurface sooner and due cards come first. Ask "what's due today?" for a summary across all your decks.

Organize with categories: name decks with :: to nest them (e.g. LLM::Attention). Browse the category tree, or the same tree as an interactive mind map, and study a whole branch in one merged session. Quiz decks are flagged with a badge.

Manage your decks: create, append to, edit, rename, and delete decks and cards without leaving the chat. Pass reverse when creating a deck to also drill each card back-to-front (handy for vocabulary).

Just JSON: decks live in data/decks.json, read live on every call. Hand-edit them or let Claude build them. No database, no external service.

Browse decks as a category tree or a mind map

Related MCP server: EduChain MCP Server

The tools

Only review_deck and study open the inline flip-card UI; everything else returns a text summary, so editing or creating in chat no longer pops the widget.

Tool	What it does
`review_deck`	Open one deck for review (due cards first, capped per session).
`study`	Review a whole category subtree, merged into one session (capped per session).
`create_deck`	Generate flashcards or cloze cards; `reverse` also adds back-to-front cards.
`create_quiz`	Generate multiple-choice questions.
`grade_card`	Record a review result and update the card's FSRS schedule (called by the UI).
`due_today`	Summarize what is due across all decks, and flag struggling cards (3+ lapses).
`edit_card`	Change a card's front and/or back.
`refine_card`	Propose splitting a card into atomic pieces, or rewriting it to test understanding.
`apply_refinement`	Persist a refinement after the user approves the proposed cards.
`capture`	Turn something that just burned you (a bug, a missed question) into draft cards.
`apply_capture`	Persist captured cards after the user approves them.
`rename_deck`	Rename a deck (also moves it in the category tree).
`delete_card`	Remove a single card.
`delete_deck`	Remove a whole deck.

Card generation follows Memora's quality rules (atomic single-concept cards, 1-5 word answers, active recall, unambiguous, no answer leakage, application over definition), based on Wozniak's 20 Rules of Formulating Knowledge. New cards are linted on write and flagged (never blocked) so Claude can revise them.

How it works (MCP Apps)

A tool declares a ui:// resource. When Claude calls the tool, the host (Claude Desktop) fetches that resource, renders its HTML in a sandboxed iframe, passes the tool result to the UI, and the UI talks back to the host over JSON-RPC (to grade cards and report progress to the model).

The MCP Apps round trip

Quick start

Prerequisites

Node.js 20.11+

Connect to Claude Desktop

Open Settings > Developer > Edit Config and add Memora under mcpServers:

{
  "mcpServers": {
    "memora": {
      "command": "npx",
      "args": ["-y", "@servation/memora-mcp", "--stdio"]
    }
  }
}

Then fully quit Claude Desktop (from the system tray) and relaunch. memora appears under Settings > Developer, pre-loaded with a few sample decks.

Your decks are stored in ~/.memora/decks.json (override the path with the MEMORA_DECKS environment variable). Hand-edit that file or let Claude manage it.

git clone https://github.com/Servation/memora-mcp.git
cd memora-mcp
npm install
npm run build

Point the config at the built entry with an absolute path (decks then live in the repo's data/decks.json):

{
  "mcpServers": {
    "memora": {
      "command": "node",
      "args": ["C:\\path\\to\\memora-mcp\\dist\\main.js", "--stdio"]
    }
  }
}

Try it (in a Claude Desktop chat)

review my World Capitals deck
make me a deck of 10 Spanish travel phrases
make a reversible deck of 10 Spanish words (drills both directions)
make a fill-in-the-blank deck about the water cycle (cloze cards)
quiz me with 10 multiple-choice questions on the solar system
turn what we just discussed into a deck called "Photosynthesis"
study my LLM category
what's due today?

Tech stack

Server: TypeScript, @modelcontextprotocol/sdk plus @modelcontextprotocol/ext-apps, stdio transport (Streamable HTTP also available).
UI: React plus Vite, bundled to a single inlined HTML file via vite-plugin-singlefile.
Scheduling: ts-fsrs (FSRS).
Runtime is plain node once built (no bun or tsx needed).

Deck format

{
  "Deck Name": [
    { "front": "Capital of France?", "back": "Paris" }
  ]
}

Stored in ~/.memora/decks.json when installed (or data/decks.json from source); override with MEMORA_DECKS.
Read live (mtime-cached). create_deck, create_quiz, and grade_card write here atomically.
A quiz card adds "options": ["...", "..."]; its back is the correct option.
A cloze card writes the blank as [...] in the front, with the hidden term as the back.
Cards gain a due date and an FSRS srs block as you review them; cards without them are treated as new.
Keep it valid JSON, or the server falls back to a built-in default deck.

Project structure

memora-mcp/
├── server.ts            # MCP tools + the ui:// resource
├── decks.ts             # data model, decks.json storage, result builder
├── scheduling.ts        # FSRS scheduling + review ordering
├── main.ts              # entry: stdio (Claude Desktop) or Streamable HTTP
├── mcp-app.html         # UI entry HTML (bundled by Vite)
├── src/
│   ├── mcp-app.tsx      # review orchestrator (flip / quiz / cloze, grade -> model)
│   ├── deck-lib.tsx     # tree, mind map, card list, quiz/cloze views, helpers
│   ├── mcp-app.module.css
│   └── global.css       # host theme variable fallbacks (light/dark)
├── data/decks.json      # editable decks, read live
├── media/               # README images
├── vite.config.ts       # single-file bundle config
└── tsconfig*.json

Development

npm run dev        # vite watch (UI) plus tsx server on http://localhost:3001/mcp
npm run typecheck  # tsc --noEmit

For fast local iteration you can also run the app against the MCP Apps reference host (basic-host) from the ext-apps repo.

Roadmap

See TODO.md for the backlog: npm + MCP Registry publishing, cross-client hosting (Streamable HTTP), tests around parsing and scheduling, and a real screen-capture demo GIF.

License

MIT

Available Tools

10 tools

create_deckCreate DeckA

Create (or extend) a flashcard deck from cards you generate based on the user's request or the current conversation, then display it for 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:

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.
Concise answers: the back is ideally 1-5 words (a name, date, term, or single concept), never a sentence or paragraph.
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").
Unambiguous: each front must point to exactly one correct answer.

Set reverse=true to also add the back->front version of each non-cloze card (useful for vocabulary or term/definition pairs that should be drilled both ways).

ParametersJSON Schema

Name	Required	Description
`cards`	Yes	Flashcards generated from the user's request or the conversation.
`append`	No	If true and the deck already exists, append to it; otherwise replace/create.
`reverse`	No	If true, also add the reverse (back -> front) of each non-cloze card.
`deck_name`	Yes	Name for the deck to create or add to ("::" nests it).

Output Schema

ParametersJSON Schema

Name	Required	Description
`deck`	Yes
`cards`	Yes
`count`	Yes
`dueCount`	Yes
`newCount`	Yes
`quizDecks`	No
`availableDecks`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully covers behavioral traits: persistence to data/decks.json, card-quality rules, and the effect of append (replace vs. append) and reverse. It also details the nesting behavior with '::'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with front-loaded purpose and detailed rules. It is slightly verbose due to card-quality rules, but every sentence is justified for correct usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity with 4 parameters and custom card-quality rules, the description is complete. It covers creation, extension, nesting, card formatting, and the effect of parameters. The presence of an output schema covers return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining deck_name nesting with '::', detailed card-quality rules (not in schema), and the reverse parameter. It does not add much to append parameter but overall enhances understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates or extends a flashcard deck from cards generated based on user request or conversation. It distinguishes itself from siblings like create_quiz and study by focusing on deck creation and extending.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool: 'from cards you generate based on the user's request or the current conversation.' It also explains the append and reverse parameters for extension. However, it does not explicitly mention when not to use it or alternatives like edit_card.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_quizCreate QuizA

Create (or extend) a multiple-choice quiz deck from questions you generate based on the user's request or the conversation, then display it for review. Use "::" in deck_name to nest under a category. Persists to data/decks.json and is reviewed like flashcards with spaced repetition.

Each question: a clear, specific prompt; 3 to 4 concise options with exactly ONE correct answer and plausible (not obviously wrong) distractors. The answer must match one of the options exactly.

ParametersJSON Schema

Name	Required	Description
`append`	No	If true and the deck exists, append; otherwise replace/create.
`deck_name`	Yes	Name for the quiz deck to create or add to ("::" nests it).
`questions`	Yes	Multiple-choice questions you generate.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deck`	Yes
`cards`	Yes
`count`	Yes
`dueCount`	Yes
`newCount`	Yes
`quizDecks`	No
`availableDecks`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden. It discloses persistence to data/decks.json, display for review, and spaced repetition. However, it does not explain the behavior of the 'append' parameter (whether it replaces or extends) beyond implying both are possible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs; first sentence captures main purpose, second paragraph details question requirements. No unnecessary sentences, efficiently structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers creation, display, persistence, and question requirements. Output schema exists so return values are covered. Missing explicit handling of 'append' behavior, but overall sufficient for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds value by explaining deck_name nesting ('::') and providing detailed formatting rules for questions (clear prompt, 3-4 options, one correct answer, plausible distractors), which goes beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'create (or extend)' and resource 'multiple-choice quiz deck', distinguishing it from sibling tool 'create_deck' by specifying it's for quiz decks with automated question generation based on user request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description indicates when to use (user wants a quiz), how to structure deck names ('::' nesting), and question formatting rules. It does not explicitly exclude alternatives but provides sufficient context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_cardDelete CardA

Delete a single card from a deck, identified by its front text. Refuses to delete a deck's last card (delete the deck instead).

ParametersJSON Schema

Name	Required	Description	Default
`front`	Yes	The card's front text (identifies the card).
`deck_name`	Yes	Deck the card belongs to.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deck`	Yes
`cards`	Yes
`count`	Yes
`dueCount`	Yes
`newCount`	Yes
`quizDecks`	No
`availableDecks`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries full burden. It discloses the refusal to delete the last card, which is a key behavioral trait. However, it does not mention other aspects like permissions or irreversibility, though 'delete' implies destructiveness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no unnecessary words. First sentence states core purpose, second adds critical constraint. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with full schema coverage and an existing output schema, the description is complete. It covers parameters, behavior, and usage limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and description adds no new parameter meaning beyond what the schema already provides. The mention of 'front text' is redundant with schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'delete' and resource 'card' with precise identification by front text. Unambiguous and distinguishes from sibling tools like delete_deck and edit_card.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when not to use (last card) and provides alternative (delete_deck). This is direct usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_deckDelete DeckA

Delete a deck and all its cards. Refuses to delete the only remaining deck.

ParametersJSON Schema

Name	Required	Description	Default
`deck_name`	Yes	Deck to delete.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that deletion affects both deck and cards, and that it refuses to delete the last deck. This adequately conveys destructive behavior and a key exception.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, direct, and front-loaded with the core action and a critical constraint. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the essential functionality (delete deck and cards) and a key constraint (refusing to delete the only deck), making it sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter, 'deck_name,' with schema description 'Deck to delete.' The tool description does not add additional meaning beyond the schema. With 100% schema coverage, baseline score 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes a deck and all its cards, distinguishing it from sibling tools like 'delete_card' (single card) and 'rename_deck' (rename only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear constraint: 'Refuses to delete the only remaining deck,' which guides when not to use it. However, it does not explicitly state when to use this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

due_todayDue TodayA

Summarize what is due to review right now across all decks: per-deck and total due/new counts. Pull-based (call it to see the summary); it does not appear on its own.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`date`	Yes
`decks`	Yes
`totalDue`	Yes
`totalNew`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the tool is pull-based and non-automatic, but does not disclose whether it is a read-only operation or any other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short, front-loaded sentences. Each sentence adds value: the first states the purpose, the second clarifies usage behavior. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema, the description fully covers what the tool does and how it behaves. It is complete for a summary tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the baseline is 4. The description does not add parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Summarize' and the resource 'what is due to review right now across all decks', specifying the output as per-deck and total due/new counts. This distinguishes it from sibling tools like review_deck or create_deck.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes that the tool is pull-based and does not appear on its own, providing clear context for when to call it. However, it does not explicitly compare it to alternatives like review_deck or study, though the distinction is implied by the summary nature.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edit_cardEdit CardA

Edit a card's front and/or back in a deck, identified by its current front text, then re-render the deck. Keep edits within Memora's card-quality rules (atomic, concise 1-5 word answers, unambiguous).

ParametersJSON Schema

Name	Required	Description
`front`	Yes	The card's CURRENT front text (identifies the card to edit).
`new_back`	No	New back text. Omit to keep the current back.
`deck_name`	Yes	Deck the card belongs to.
`new_front`	No	New front text. Omit to keep the current front.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deck`	Yes
`cards`	Yes
`count`	Yes
`dueCount`	Yes
`newCount`	Yes
`quizDecks`	No
`availableDecks`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It mentions re-rendering the deck and identification by current front text, but does not detail side effects, permissions, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences; front-loaded with the action and resource, followed by essential quality constraints. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description lacks information on error handling, mutability, or prerequisites. For a tool with 4 parameters and required fields, it provides minimum viable completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are well-documented. Description adds value by clarifying that the 'front' parameter identifies the card and that edits apply to front and/or back, but does not substantially extend schema meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool edits a card's front and/or back, identified by its current front text, and distinguishes it from sibling tools like delete_card. It uses a specific verb-resource combination.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidelines on card-quality rules but does not explicitly specify when to use this tool vs alternatives (e.g., create_deck, delete_card) or mention exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

grade_cardGrade CardA

Record a spaced-repetition review result for a single card and update its FSRS schedule in data/decks.json. Called by the flip-card UI; not for direct model use.

ParametersJSON Schema

Name	Required	Description
`front`	Yes	The card's front text (identifies the card).
`correct`	Yes	Whether the user got the card right.
`deck_name`	Yes	Deck the card belongs to.

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses file update behavior but lacks details on idempotency, error handling, or what happens if the card doesn't exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded, with no unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage boundary, and key behavior. Lacks mention of preconditions like card existence, but given UI usage and simplicity, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that the result is a spaced-repetition review that updates the FSRS schedule, providing context beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (record review result and update FSRS schedule), the resource (single card, data/decks.json), and distinguishes from sibling tools by specifying it's for a single card and called by the flip-card UI, not for direct model use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates it is called by the flip-card UI and not for direct model use, providing clear context. However, it does not explicitly list alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rename_deckRename DeckA

Rename a deck, preserving its cards and schedules. Use "::" in the new name to move it under a category. Fails if a deck with the new name already exists.

ParametersJSON Schema

Name	Required	Description	Default
`new_name`	Yes	New deck name ("::" nests it under a category).
`deck_name`	Yes	Current deck name.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deck`	Yes
`cards`	Yes
`count`	Yes
`dueCount`	Yes
`newCount`	Yes
`quizDecks`	No
`availableDecks`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses preservation of cards/schedules and failure condition, but does not mention other aspects like authentication, rate limits, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: action+"preservation", formatting tip, failure condition. No fluff, front-loaded key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple rename operation with a description and output schema, it is fairly complete. Could mention return value but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions. The description adds useful context about using '::' for category nesting, which goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it renames a deck, preserving cards and schedules. This is specific and distinct from siblings like create_deck or delete_deck.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context (rename operation) and mentions a failure condition (new name exists). However, it does not explicitly guide when to use this versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

review_deckReview DeckA

Return the flashcards of a single Memora deck and display them as an interactive flip-card review (due cards first). Available decks: "Geography::World Capitals", "Geography::Rivers", "Science::Solar System", "Language::Spanish Basics". 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.

ParametersJSON Schema

Name	Required	Description	Default
`deck_name`	No	Deck to review. Omit or pass an unknown name to get the first available deck.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deck`	Yes
`cards`	Yes
`count`	Yes
`dueCount`	Yes
`newCount`	Yes
`quizDecks`	No
`availableDecks`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the data source ('read live from data/decks.json') and hints at read-only behavior by stating it 'returns' and 'displays' flashcards. No destructive actions are implied, adding needed transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 4 sentences, each adding necessary information: purpose, available decks, comparison to sibling, and data source. No redundant or vague language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 optional parameter, no nested objects, no annotations) and the existence of an output schema, the description covers all needed context: what it does, which decks exist, how to use the parameter, and where data comes from. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds extra value by listing available deck names (making selection easier) and explaining the fallback behavior when the deck name is omitted or invalid, which the schema does not cover.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: returning flashcards of a single deck and displaying them as an interactive review, prioritizing due cards. It lists specific available decks and distinguishes from the sibling 'study' tool by noting that 'study' reviews a whole category, while 'review_deck' is for a single deck.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions an alternative tool ('study' for whole categories) and explains default behavior when the deck name is omitted or unknown. It does not explicitly state when not to use this tool, but the guidance is clear enough for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

studyStudy CategoryA

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.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Category path, e.g. "LLM" or "LLM::Attention". Omit to study all decks.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deck`	Yes
`cards`	Yes
`count`	Yes
`dueCount`	Yes
`newCount`	Yes
`quizDecks`	No
`availableDecks`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden. It discloses merging, shuffling, and attribution behavior. Could explicitly state non-destructive nature, but current detail is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded main purpose, efficient. Minor redundancy (e.g., 'merged and shuffled' could be assumed from 'study'). Still well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given single optional parameter, output schema exists (reducing need for return value description), and context signals show low complexity. Description covers behavior sufficiently for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and description adds value by explaining path format ('::' nesting) and the effect of omission. Enhances schema meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'study' and resource 'cards under a category node', explains nesting with '::', and distinguishes from siblings like 'review_deck' by focusing on category vs. single deck.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes when to omit path (study all decks) and that studying a node covers all subdecks. Does not explicitly mention when not to use vs. specific sibling tools, but context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv0.1.1Jun 30, 2026
- First observedcreate_deck
- First observedcreate_quiz
- First observeddelete_card
- First observeddelete_deck
- First observeddue_today
- First observededit_card
- First observedgrade_card
- First observedrename_deck
- First observedreview_deck
- First observedstudy

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-06-30 22:30 across 10 tools

Disambiguation5/5

Each tool targets a distinct action: deck/quiz creation, card/deck deletion, editing, renaming, reviewing single decks or categories, grading, and summary. No two tools have overlapping purposes; descriptions clearly differentiate them.

Naming Consistency3/5

Most tools follow a verb_noun pattern (create_deck, delete_card, etc.), but 'due_today' is a noun phrase and 'study' is a bare verb, breaking the consistency. This mix could confuse an agent predicting tool names.

Tool Count5/5

10 tools is well-scoped for a flashcard/quiz application. Each tool serves a necessary function in the creation, management, review, and scheduling lifecycle without being excessive or sparse.

Completeness4/5

The tool set covers CRUD operations, review, and scheduling. However, there is no tool to list all decks or view cards without triggering a review session, which is a minor gap that could hinder agent workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Flashcards Open Source AppOAuth
com.flashcards-open-source-app
Read, write, and conversationally review open-source flashcards through split read/write MCP tools.
Education & Learning Tools Note Taking
229
NibomoOAuth
com.nibomo
Read, write, and conversationally review open-source flashcards through split read/write MCP tools.
Education & Learning Tools Note Taking
129
FlipnemOAuth
com.flipnem
Build and study spaced-repetition flashcards with your agent.
Education & Learning Tools Knowledge & Memory Note Taking
2
Flash AOAuth
com.flashmemorize
Spaced-repetition flashcards your AI writes, quizzes you on by voice, and schedules with FSRS.
Education & Learning Tools Speech Processing
1711

Related MCP Servers

MCP-AnkiConnect
Education & Learning Tools App Automation
samefarrar
A
license
A
quality
C
maintenance
An MCP server that integrates Claude with Anki flashcards, allowing users to review due cards and create new flashcards directly through conversation.
Updated 4 months ago (2026-05-28 09:00 UTC)
14
29 PyPI
13
MIT
EduChain MCP Server
Education & Learning Tools Content Management Systems App Automation
TAKSH-PAL
A
license
A
quality
D
maintenance
Integrates EduChain's educational content generation capabilities with Claude Desktop, enabling creation of multiple-choice questions, comprehensive lesson plans, and flashcards for any educational topic.
Updated a year ago (2025-07-04 11:21 UTC)
3
1
MIT
mcp-ankiconnect
Education & Learning Tools Note Taking
MCP-Mirror
A
license
Not graded
quality
Not graded
maintenance
Connects Claude to Anki flashcard software via AnkiConnect, enabling users to review due cards, create flashcards, and manage spaced repetition learning through natural language conversations.
Updated a year ago (2025-06-25 18:48 UTC)
MIT
Flashcard AI MCP
Education & Learning Tools AI & Machine Learning
CSOAI-ORG
A
license
C
quality
B
maintenance
Flashcard AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 16 days ago (2026-09-04 12:39 UTC)
4
5 npm
60 PyPI
MIT