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

Превратите любой разговор в интерактивное учебное занятие прямо в Claude Desktop. Попросите Claude создать колоду — и он сгенерирует карточки, затем отобразит их как встроенный обзор, по которому можно кликать: переворачивайте флеш-карточки, отвечайте на вопросы с множественным выбором и заполняйте пропуски в cloze-карточках. Каждый ответ обновляет расписание интервального повторения, а ваши результаты возвращаются к Claude, чтобы он мог отработать то, что вы пропустили.

Ключевые слова: Model Context Protocol, MCP-сервер, MCP Apps, Claude Desktop, флеш-карточки, викторины, интервальное повторение, SRS, FSRS, альтернатива Anki.

Построено на расширении MCP Apps (SEP-1865): базовая спецификация MCP 2025-11-25 плюс расширение Apps 2026-01-26.

Три способа учиться, отображаемые встроенно в Claude

Возможности

Три способа учиться — все отображаются встроенно и оцениваются одинаково:

Флеш-карточки: нажмите, чтобы перевернуть, затем оцените Понял / Не понял.
Викторины с множественным выбором: выберите вариант, и правильный/неправильный ответы раскроются мгновенно.
Cloze (заполнение пропусков): пропуск раскрывается на месте, чтобы предложение оставалось целым. Напишите пропуск как [...] на лицевой стороне карточки, и она автоматически станет cloze-карточкой.

Интервальное повторение: каждая оценка обновляет индивидуальное расписание FSRS для карточки (через ts-fsrs), поэтому слабые карточки всплывают раньше, а просроченные идут первыми. Спросите «что сегодня на повторении?» для сводки по всем вашим колодам.

Организация с категориями: называйте колоды с :: для вложенности (например, LLM::Attention). Просматривайте дерево категорий или то же дерево как интерактивную интеллект-карту и учите целую ветку в одном объединённом сеансе. Колоды-викторины помечаются значком.

Управление колодами: создавайте, дополняйте, редактируйте, переименовывайте и удаляйте колоды и карточки, не выходя из чата. Передайте reverse при создании колоды, чтобы также отрабатывать каждую карточку в обратную сторону (удобно для словарного запаса).

Просто JSON: колоды хранятся в data/decks.json и читаются в реальном времени при каждом вызове. Редактируйте их вручную или позвольте Claude создавать их. Никакой базы данных, никакого внешнего сервиса.

Просмотр колод как дерева категорий или интеллект-карты

Related MCP server: EduChain MCP Server

Инструменты

Только review_deck и study открывают встроенный интерфейс переворачивающихся карточек; всё остальное возвращает текстовую сводку, поэтому редактирование или создание в чате больше не открывает виджет.

Инструмент	Что делает
`review_deck`	Открывает одну колоду для повторения (сначала просроченные, с лимитом на сеанс).
`study`	Повторяет целое поддерево категорий, объединённое в один сеанс (с лимитом на сеанс).
`create_deck`	Генерирует флеш-карточки или cloze-карточки; `reverse` также добавляет обратные карточки.
`create_quiz`	Генерирует вопросы с множественным выбором.
`grade_card`	Записывает результат повторения и обновляет расписание FSRS карточки (вызывается интерфейсом).
`due_today`	Сводка того, что просрочено по всем колодам, и отмечает проблемные карточки (3+ сбоя).
`edit_card`	Изменяет лицевую и/или обратную сторону карточки.
`refine_card`	Предлагает разбить карточку на атомарные части или переписать её для проверки понимания.
`apply_refinement`	Сохраняет уточнение после одобрения пользователем предложенных карточек.
`capture`	Превращает то, что вас только что зацепило (баг, пропущенный вопрос), в черновые карточки.
`apply_capture`	Сохраняет захваченные карточки после одобрения пользователем.
`rename_deck`	Переименовывает колоду (также перемещает её в дереве категорий).
`delete_card`	Удаляет одну карточку.
`delete_deck`	Удаляет целую колоду.

Генерация карточек следует правилам качества Memora (атомарные карточки с одной концепцией, ответы из 1–5 слов, активное припоминание, однозначность, отсутствие утечки ответов, применение вместо определения), основанным на 20 правилах формулирования знаний Возняка. Новые карточки проверяются при записи и помечаются (но никогда не блокируются), чтобы Claude мог их пересмотреть.

Как это работает (MCP Apps)

Инструмент объявляет ресурс ui://. Когда Claude вызывает инструмент, хост (Claude Desktop) загружает этот ресурс, отображает его HTML в песочнице iframe, передаёт результат инструмента в интерфейс, а интерфейс общается с хостом через JSON-RPC (для оценки карточек и отчёта о прогрессе модели).

Круговой цикл MCP Apps

Быстрый старт

Предварительные требования

Node.js 20.11+

Подключение к Claude Desktop

Откройте Настройки > Разработчик > Изменить конфигурацию и добавьте Memora в раздел mcpServers:

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

Затем полностью закройте Claude Desktop (из системного трея) и запустите заново. memora появится в разделе Настройки > Разработчик, предварительно загруженный с несколькими примерами колод.

Ваши колоды хранятся в ~/.memora/decks.json (переопределите путь переменной окружения MEMORA_DECKS). Редактируйте этот файл вручную или позвольте Claude управлять им.

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

Укажите в конфигурации путь к собранной точке входа с абсолютным путём (колоды тогда будут храниться в data/decks.json репозитория):

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

Попробуйте (в чате Claude Desktop)

просмотри мою колоду World Capitals
сделай мне колоду из 10 испанских фраз для путешествий
сделай обратимую колоду из 10 испанских слов (отрабатывает оба направления)
сделай колоду с заполнением пропусков о круговороте воды (cloze-карточки)
проверь меня 10 вопросами с множественным выбором о солнечной системе
преврати то, что мы только что обсудили, в колоду под названием "Фотосинтез"
изучи мою категорию LLM
что сегодня на повторении?

Технологический стек

Сервер: TypeScript, @modelcontextprotocol/sdk плюс @modelcontextprotocol/ext-apps, транспорт stdio (Streamable HTTP также доступен).
Интерфейс: React плюс Vite, собранный в единый встроенный HTML-файл через vite-plugin-singlefile.
Планирование: ts-fsrs (FSRS).
Среда выполнения — обычный node после сборки (bun или tsx не нужны).

Формат колоды

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

Хранится в ~/.memora/decks.json при установке (или data/decks.json из исходного кода); переопределяется через MEMORA_DECKS.
Читается в реальном времени (с кэшированием по mtime). create_deck, create_quiz и grade_card записывают сюда атомарно.
Викторина-карточка добавляет "options": ["...", "..."]; её back — правильный вариант.
Cloze-карточка записывает пропуск как [...] на лицевой стороне, со скрытым термином в back.
Карточки получают дату due и блок FSRS srs по мере повторения; карточки без них считаются новыми.
Поддерживайте корректный JSON, иначе сервер вернётся к встроенной колоде по умолчанию.

Структура проекта

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

Разработка

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

Для быстрой локальной итерации вы также можете запустить приложение против эталонного хоста MCP Apps (basic-host) из репозитория ext-apps.

Дорожная карта

См. TODO.md для бэклога: публикация в npm и MCP Registry, кроссплатформенный хостинг (Streamable HTTP), тесты для парсинга и планирования, а также реальная GIF-демонстрация захвата экрана.

Лицензия

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