Recall MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RECALL_MCP_DB | No | Path to the local SQLite database file used by the MCP server. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_deckC | Create a new flashcard deck. |
| list_decksB | List all decks with card counts and how many cards are due today. |
| add_cardB | Add a flashcard to a deck. New cards are due immediately. |
| list_cardsC | List cards in a deck. |
| due_cardsA | Get cards due for review today, oldest due first. Omit deck to get due cards across all decks. |
| review_cardA | Record a review of a card and schedule its next appearance with the SM-2 algorithm. Grade 0-5: 5 perfect recall, 3 barely recalled, below 3 forgotten. |
| deck_statsB | Statistics for one deck: total cards, due today, new cards, average ease factor. |
| delete_cardC | Delete a card by id. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools are cleanly separated by resource and action: deck creation/listing, card add/list/delete, due-card retrieval, and review recording each have a distinct purpose. The main soft spot is list_decks vs deck_stats, which both surface counts and due-today numbers, and list_cards vs due_cards, which could be confused at a glance, though the descriptions resolve both.
Seven of eight names follow a predictable verb_noun snake_case pattern (list_decks, create_deck, add_card, list_cards, review_card, delete_card). The two noun-only names, due_cards and deck_stats, deviate from that pattern but remain readable and unambiguous.
Eight tools is well within the ideal range and every one earns its place: deck management, card management, review scheduling, and stats. Nothing feels redundant or missing at the structural level.
The review lifecycle is fully covered (add -> due -> review -> reschedule -> delete), but deck management is incomplete: there is no delete_deck or rename/update_deck, and cards cannot be edited after creation. An agent asked to rename a deck, remove a deck, or fix a typo in a card would hit a dead end.