Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mochi-mcp List my recent flashcards"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for Mochi flashcard integration. Create, manage, and review spaced repetition flashcards directly from Claude, ChatGPT, or any LLM that supports MCP.
If you find this MCP server useful, please consider supporting its development!
👉 Click here to support this project
Your support helps maintain and improve this tool for everyone. Thank you! 🙏
📇 Card Management - Create, read, update, delete flashcards
🔍 Search - Find cards by name or content
📚 Deck Organization - Manage decks and organize cards
🔄 Pagination - Handle large card collections efficiently
🧠 Spaced Repetition - Integrate with Mochi's learning algorithm
✨ Markdown Support - Rich formatting for card content
Related MCP server: anki-mcp
Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on Mac or %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"mochi": {
"command": "npx",
"args": ["-y", "@louis030195/mochi-mcp"],
"env": {
"MOCHI_API_KEY": "your-mochi-api-key"
}
}
}
}# Install globally in user scope with API key
claude mcp add -s user mochi npx -e MOCHI_API_KEY=your-mochi-api-key -- -y @louis030195/mochi-mcpGo to Mochi Account Settings
Sign up or log in
Navigate to Settings → Account
Copy your API key
Once configured, you can use natural language to interact with Mochi:
"Create a flashcard about the Krebs cycle"
"Show me my recent flashcards"
"Update the card about Python decorators"
"Delete the card with ID abc123"
"Search for cards about machine learning"
"List all my decks"
"Create a new deck called 'Spanish Vocabulary'"
"Find cards containing 'neural networks'"
"Get the next 20 cards for review"
"Show me cards from the Biology deck"
mochi_list_cardsList all Mochi flashcards with pagination support.
Parameters:
bookmark (string, optional): Pagination bookmark from previous response
limit (number, optional): Maximum number of cards to fetch (default: 100)
Returns: List of cards with content, IDs, deck info, review status, etc.
mochi_get_cardGet a specific Mochi flashcard by ID.
Parameters:
card_id (string, required): The ID of the card to retrieve
Returns: Detailed card data including front, back, deck, review history, etc.
mochi_create_cardCreate a new Mochi flashcard with front/back content.
Parameters:
name (string, required): The front/question of the card
content (string, required): The back/answer of the card (markdown supported)
deck_id (string, optional): Optional deck ID to add the card to
Returns: Created card data with ID
mochi_update_cardUpdate an existing Mochi flashcard.
Parameters:
card_id (string, required): The ID of the card to update
name (string, optional): The front/question of the card
content (string, optional): The back/answer of the card (markdown supported)
Returns: Updated card data
mochi_delete_cardDelete a Mochi flashcard by ID.
Parameters:
card_id (string, required): The ID of the card to delete
Returns: Deletion confirmation
mochi_list_decksList all Mochi decks.
Returns: List of decks with names, IDs, card counts, etc.
mochi_create_deckCreate a new Mochi deck.
Parameters:
name (string, required): The name of the deck
Returns: Created deck data with ID
mochi_search_cardsSearch for Mochi flashcards by name or content.
Parameters:
query (string, required): Search query
bookmark (string, optional): Pagination bookmark from previous response
Returns: List of matching cards
# Clone the repo
git clone https://github.com/louis030195/mochi-mcp.git
cd mochi-mcp
# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test
# Run locally
MOCHI_API_KEY=your-api-key npm startSee Mochi API Docs for full API details.
MIT
Create a new Mochi flashcard with front/back content
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The front/question of the card | |
| content | Yes | The back/answer of the card (markdown supported) | |
| deck_id | No | Optional deck ID to add the card to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on side effects, prerequisites, or limitations (e.g., whether deck_id is required or behavior when omitted).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient and front-loaded, but could add a bit more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not explain return value or error conditions; adequate for a simple create but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions; description adds minimal extra meaning beyond 'front/back'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'create', resource 'flashcard', and distinguishes from list/get/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_card for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Mochi deck
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the deck | |
| parent_id | No | Optional parent deck ID for nesting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Create,' which implies mutation, but fails to disclose what happens if a deck with the same name exists, required permissions, any side effects, or what response is returned. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient and front-loaded. However, it is arguably too concise given the lack of detail in other dimensions. It earns a 4 for being concise but not sacrificing clarity entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (2 parameters, no output schema, no annotations), the description is minimal but covers the primary purpose. It does not mention nesting via parent_id or any return value, which could be important for an agent. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (name and parent_id), achieving 100% coverage. The description adds no extra meaning beyond the schema, so it meets the baseline of 3. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (a new Mochi deck), which is specific and distinct from sibling tools like mochi_list_decks and mochi_create_card. However, it does not provide any additional context beyond the name, making it only slightly above a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives (e.g., mochi_list_decks to check existing decks, or mochi_update_card for modifying a deck). There are no prerequisites or context about when creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Mochi flashcard by ID
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | The ID of the card to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden. It only states the action without disclosing consequences (e.g., permanent deletion, required permissions, error handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with action and resource. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool without output schema, the description is adequate. Could mention irreversibility, but still sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for card_id. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete), resource (Mochi flashcard), and method (by ID). It distinguishes from siblings like mochi_create_card or mochi_update_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool or alternatives. Implies use when a card ID is known, but does not provide context on when to prefer over other delete methods or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific Mochi flashcard by ID
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | The ID of the card to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only indicates a read operation (get) with no disclosure of side effects, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema. Description is minimal but adequate for a basic get-by-ID operation, though lacks details on error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the parameter. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Get), resource (specific Mochi flashcard), and identifier (by ID). Distinguishes from siblings like list, create, update, delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Mochi flashcards with pagination support
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of cards to fetch (default: 100) | |
| bookmark | No | Pagination bookmark from previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions pagination but does not disclose ordering, rate limits, authorization requirements, or whether the operation is read-only. For a list tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, efficiently communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and no output schema, the description covers the basics but lacks usage context and behavioral details, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds 'pagination support' but does not detail how the bookmark parameter works beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Mochi flashcards' with a specific verb and resource, and adds 'pagination support' to distinguish from single-card retrieval tools like mochi_get_card or search tools like mochi_search_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing with pagination but provides no explicit guidance on when to use this tool versus alternatives like mochi_search_cards, and lacks any exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Mochi decks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose behavioral traits such as pagination, ordering, rate limits, or whether it returns all decks at once. For a list operation, these details are important for the agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, front-loading the purpose. However, it could be slightly more informative without adding verbosity, such as mentioning the return format. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should hint at what the response contains (e.g., deck IDs and names). It does not, leaving the agent to infer the return structure. For a zero-parameter tool, this is partially acceptable but not fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The input schema is empty, and the description adds no parameter information, but none is needed. Schema coverage is 100% by default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all Mochi decks' clearly identifies the verb (list) and resource (decks), making the tool's purpose unmistakable. It naturally distinguishes from siblings like mochi_list_cards (lists cards) and mochi_create_deck (creates decks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not explain when to prefer this over mochi_search_cards or how it relates to deck creation. The description solely states what the tool does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Mochi flashcards by name or content
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| bookmark | No | Pagination bookmark from previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks details on pagination, rate limits, or whether search is read-only. Minimal behavioral disclosure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence, no unnecessary words. Could benefit from front-loading key constraints, but structure is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description does not explain return values, pagination behavior, or search algorithm. For a simple tool, more context is needed for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description repeats 'name or content' but adds no new meaning beyond schema descriptions for query and bookmark.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches Mochi flashcards by name or content, distinguishing from list (all cards) and get (single card by ID). However, it could be more specific about search scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. siblings like mochi_list_cards or mochi_get_card. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing Mochi flashcard
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The front/question of the card | |
| card_id | Yes | The ID of the card to update | |
| content | No | The back/answer of the card (markdown supported) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic operation. For a mutation tool, it should indicate if authentication is needed, if it's idempotent, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose. It is front-loaded and efficient, though it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with a well-defined schema, the description is adequate but has gaps. It does not mention that the card must exist, that only provided fields are updated, or what the response format is (no output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description in the schema. The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing Mochi flashcard'), distinguishing from siblings like create or delete. However, it is minimal and could be more specific about which fields can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as mochi_create_card for new cards or mochi_delete_card for removal. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1mochi_create_cardmochi_create_deckmochi_delete_cardmochi_get_cardmochi_list_cardsmochi_list_decksmochi_search_cardsmochi_update_cardEach tool targets a distinct action on a specific resource (cards vs decks), with no overlap. The names and descriptions clearly differentiate between CRUD operations, listing, and searching.
All tool names follow a consistent verb_noun pattern using snake_case and a 'mochi_' prefix, e.g., mochi_list_cards, mochi_create_deck. No deviations or mixed conventions.
8 tools is well-suited for a flashcard application, covering essential operations on cards and decks without being too few or excessive.
Cards have full CRUD plus search and list, but decks lack update, delete, and get operations. This is a minor gap that agents can work around, but the deck surface is incomplete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build and study spaced-repetition flashcards with your agent.
Search, read, cite, create, and safely update a user's private KeepFlash knowledge library.
Voice-led, FSRS-scheduled flashcards from YouTube, PDFs, web, or text. Auto-graded quizzes.
Connect AI to your flomo notes. Search, create, edit notes and manage tags via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/louis030195/mochi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
