de en es ja ko ru zh

Memora MCP

Name: Memora MCP
Author: Servation

by Servation

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Memora MCP

License: MIT MCP Apps TypeScript React

Convierte cualquier conversación en una sesión de estudio interactiva, directamente en Claude Desktop. Pídele a Claude que cree una baraja y generará las tarjetas, para luego mostrarlas como un repaso integrado que puedes recorrer: voltea flashcards, responde cuestionarios de opción múltiple y rellena los huecos cloze. Cada respuesta actualiza un calendario de repetición espaciada, y tus resultados vuelven a Claude para que pueda repasar lo que hayas fallado.

Palabras clave: Model Context Protocol, MCP server, MCP Apps, Claude Desktop, flashcards, quizzes, spaced repetition, SRS, FSRS, alternativa a Anki.

Construido sobre la extensión MCP Apps (SEP-1865): especificación MCP principal 2025-11-25 más la extensión Apps 2026-01-26.

Three ways to study, rendered inline in Claude

Características

Tres formas de estudiar, todas renderizadas integradas y todas evaluadas de la misma manera:

Flashcards: haz clic para voltear y luego evalúa con Lo sabía / No lo sabía.
Cuestionarios de opción múltiple: elige una opción y las respuestas correctas/incorrectas se revelan al instante.
Cloze (rellenar el hueco): el hueco se revela en su sitio para que la frase permanezca intacta. Escribe un hueco como [...] en el anverso de una tarjeta y se convertirá automáticamente en una tarjeta cloze.

Repetición espaciada: cada evaluación actualiza el calendario FSRS de cada tarjeta (mediante ts-fsrs), de modo que las tarjetas débiles reaparecen antes y las tarjetas pendientes salen primero. Pregunta "¿qué hay pendiente hoy?" para obtener un resumen de todas tus barajas.

Organiza con categorías: nombra las barajas con :: para anidarlas (p. ej. LLM::Attention). Navega por el árbol de categorías, o por el mismo árbol como mapa mental interactivo, y estudia una rama entera en una única sesión combinada. Las barajas de cuestionarios se marcan con una insignia.

Gestiona tus barajas: crea, añade, edita, renombra y elimina barajas y tarjetas sin salir del chat. Pasa reverse al crear una baraja para practicar también cada tarjeta al revés (muy útil para vocabulario).

Solo JSON: las barajas viven en data/decks.json y se leen en vivo en cada llamada. Edítalas a mano o deja que Claude las cree. Sin base de datos, sin servicios externos.

Browse decks as a category tree or a mind map

Related MCP server: EduChain MCP Server

Las herramientas

Solo review_deck y study abren la interfaz integrada de tarjetas; todo lo demás devuelve un resumen de texto, de modo que editar o crear en el chat ya no abre el widget.

Herramienta	Qué hace
`review_deck`	Abre una baraja para repasar (las tarjetas pendientes primero, con un máximo por sesión).
`study`	Repasa un subárbol de categoría completo, combinado en una sola sesión (con un máximo por sesión).
`create_deck`	Genera flashcards o tarjetas cloze; `reverse` también añade tarjetas al revés.
`create_quiz`	Genera preguntas de opción múltiple.
`grade_card`	Registra el resultado de un repaso y actualiza el calendario FSRS de la tarjeta (lo llama la interfaz).
`due_today`	Resume lo que hay pendiente en todas las barajas y marca las tarjetas problemáticas (3 o más fallos).
`edit_card`	Cambia el anverso y/o el reverso de una tarjeta.
`refine_card`	Propone dividir una tarjeta en piezas atómicas, o reescribirla para comprobar la comprensión.
`apply_refinement`	Guarda un refinamiento después de que el usuario apruebe las tarjetas propuestas.
`capture`	Convierte en tarjetas en borrador algo que acaba de hacerte fallar (un error, una pregunta fallada).
`apply_capture`	Guarda las tarjetas capturadas después de que el usuario las apruebe.
`rename_deck`	Renombra una baraja (también la mueve en el árbol de categorías).
`delete_card`	Elimina una sola tarjeta.
`delete_deck`	Elimina una baraja entera.

La generación de tarjetas sigue las reglas de calidad de Memora (tarjetas atómicas de un solo concepto, respuestas de 1 a 5 palabras, recuerdo activo, sin ambigüedades, sin desvelar la respuesta, aplicación frente a definición), basadas en las 20 reglas para formular conocimiento de Wozniak. Las tarjetas nuevas se revisan al guardarlas y se marcan (nunca se bloquean) para que Claude pueda corregirlas.

Cómo funciona (MCP Apps)

Una herramienta declara un recurso ui://. Cuando Claude llama a la herramienta, el host (Claude Desktop) obtiene ese recurso, renderiza su HTML en un iframe aislado, pasa el resultado de la herramienta a la interfaz, y la interfaz se comunica con el host mediante JSON-RPC (para evaluar tarjetas e informar del progreso al modelo).

The MCP Apps round trip

Inicio rápido

Requisitos previos

Node.js 20.11+

Conectar con Claude Desktop

Abre Settings > Developer > Edit Config y añade Memora en mcpServers:

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

A continuación, cierra Claude Desktop por completo (desde la bandeja del sistema) y vuelve a abrirlo. memora aparece en Settings > Developer, precargado con algunas barajas de ejemplo.

Tus barajas se guardan en ~/.memora/decks.json (puedes sobrescribir la ruta con la variable de entorno MEMORA_DECKS). Edita ese archivo a mano o deja que Claude lo gestione.

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

Apunta la configuración a la entrada compilada con una ruta absoluta (las barajas viven entonces en data/decks.json del repositorio):

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

Pruébalo (en un chat de Claude Desktop)

review my World Capitals deck
make me a deck of 10 Spanish travel phrases
make a reversible deck of 10 Spanish words (practica en ambas direcciones)
make a fill-in-the-blank deck about the water cycle (tarjetas cloze)
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?

Pila tecnológica

Servidor: TypeScript, @modelcontextprotocol/sdk más @modelcontextprotocol/ext-apps, transporte stdio (también disponible Streamable HTTP).
Interfaz: React con Vite, empaquetado en un único archivo HTML incrustado mediante vite-plugin-singlefile.
Programación: ts-fsrs (FSRS).
El tiempo de ejecución es node puro una vez compilado (no se necesitan bun ni tsx).

Formato de baraja

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

Se guarda en ~/.memora/decks.json cuando está instalado (o data/decks.json desde el código fuente); se puede sobrescribir con MEMORA_DECKS.
Se lee en vivo (con caché por mtime). create_deck, create_quiz y grade_card escriben aquí de forma atómica.
Una tarjeta de cuestionario añade "options": ["...", "..."]; su back es la opción correcta.
Una tarjeta cloze escribe el hueco como [...] en el anverso, con el término oculto como back.
Las tarjetas reciben una fecha due y un bloque srs de FSRS a medida que las repasas; las tarjetas sin ellos se tratan como nuevas.
Mantenlo como JSON válido, o el servidor recurrirá a una baraja predeterminada integrada.

Estructura del proyecto

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

Desarrollo

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

Para iterar rápido en local, también puedes ejecutar la aplicación contra el host de referencia de MCP Apps (basic-host) del repositorio ext-apps.

Hoja de ruta

Consulta TODO.md para ver el trabajo pendiente: publicación en npm + MCP Registry, alojamiento entre clientes (Streamable HTTP), pruebas en torno al análisis y la planificación, y un GIF real de demostración con captura de pantalla.

Licencia

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

ActivitySlowing

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
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
2613
EngrAmoOAuth
app.engramo
Create and study EngrAmo spaced-repetition flashcards from your AI client.
Education & Learning Tools Note Taking
12

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 5 months ago (2026-05-28 09:00 UTC)
14
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 10 days ago (2026-10-08 03:13 UTC)
4
6 npm
90 PyPI
MIT