Mochi MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MOCHI_API_KEY | Yes | Your Mochi API key (get it from Mochi app: Settings → Account → API Key) | |
| MOCHI_ALLOW_DECK_DELETE | No | Enable deck deletion | false |
| MOCHI_TOKEN_EXPIRY_MINS | No | Preview token validity in minutes | 10 |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_decksB | List all Mochi flashcard decks |
| get_deckC | Get deck details and list of cards |
| get_cardB | Get full content of a single card |
| get_cardsC | Get content of multiple cards (bulk) |
| search_cardsB | Search cards by content, tags, or date. Returns rich results with deckId, createdAt, updatedAt. Includes scannedCount and truncated flags. |
| list_cards_pageA | Fetch a single page of cards with explicit pagination. Use for iterating through large collections. |
| find_deck_by_nameA | Find decks by name (case-insensitive partial match). Useful when you know the deck name but not its ID. |
| add_tags_previewA | Preview adding tags to one or more cards. Returns a token for apply_tags_update. |
| remove_tags_previewA | Preview removing tags from one or more cards. Returns a token for apply_tags_update. |
| apply_tags_updateA | Apply tag changes after user confirms. Use with token from add_tags_preview or remove_tags_preview. |
| create_card_previewA | Preview a new card. IMPORTANT: After calling this, you MUST show the preview to the user and ask for explicit confirmation before calling apply_create_card. Do NOT chain these calls automatically. |
| apply_create_cardB | Execute card creation after user confirms |
| update_card_previewA | Preview changes to a card with diff. IMPORTANT: After calling this, you MUST show the diff to the user and ask "Do you want to apply this change?" WAIT for explicit confirmation before calling apply_update_card. |
| update_card_fields_previewB | Preview changes to specific fields (Question, Answer, Tags). Reconstructs full markdown. |
| update_cards_batch_previewC | Preview updates for multiple cards at once. |
| apply_update_cards_batchC | Apply a batch of card updates. |
| apply_update_cardC | Execute card update after user confirms |
| delete_cardA | Delete a card (soft-delete by default). Requires typed confirmation. |
| create_deckC | Create a new deck |
| delete_deckA | Delete a deck (disabled by default, requires MOCHI_ALLOW_DECK_DELETE=true) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| mochi_guide | Detailed user guide for Mochi MCP tools and workflows |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools have distinct purposes, such as create_card_preview vs. apply_create_card for previewing and confirming card creation, or get_card vs. get_cards for single vs. bulk retrieval. However, there is some overlap between update_card_preview and update_card_fields_preview, both used for previewing card updates, which could cause minor confusion for agents.
Tool names follow a consistent snake_case pattern with clear verb_noun structures, such as create_card_preview, apply_create_card, and list_decks. The naming is predictable and readable throughout the set, with no deviations or mixed conventions.
With 20 tools, the count is slightly high but reasonable for a flashcard management server, covering operations like creation, updates, deletion, searching, and deck management. It includes necessary preview and confirmation steps, though it could be streamlined without losing functionality.
The tool set provides comprehensive coverage for flashcard management, including full CRUD operations for cards and decks (e.g., create, get, update, delete), batch processing, tagging, searching, and pagination. There are no obvious gaps, and agents can handle typical workflows without dead ends.