Provides tools for managing Anki collections and cards, including create, read, update, delete operations, as well as synchronization with AnkiWeb or self-hosted sync servers.
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., "@Mousetail Create a card for the definition of photosynthesis"
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.
Mousetail's goal is to be the simplest and most reliable way of connecting Anki to an LLM. It does not require any addons, just have anki installed and an LLM you'd like to connect to your decks.
Running the server is as simple as:
uvx mousetailFor detailed instructions on integrating with Claude Code, Claude Desktop, and other LLM tools:
Minimal - supports core anki operations: create, read, update and delete
Stable - works directly with anki's stable pylib api, no addons or deps
Simple - no configuration required, automatically discovers your Anki collections
Related MCP server: anki-mcp
Selectively commit what you learn in conversation with an LLM to memory
"Create a deck based on our conversation so I don't forget critical details"
Use an LLM to interact with your deck
"Create a card - what is a coeffcient?, create a card - id the first coefficient in this polynomial"
Use an LLM to cleanup a deck
"Check my french vocab deck for correctness and correct any mistakes, typos or errors"
Mousetail supports synchronizing your Anki collection with AnkiWeb or a self-hosted sync server. This allows you to keep your collection in sync across devices.
Sync with AnkiWeb (saves credentials for future syncs):
> "Save my AnkiWeb credentials: username is myuser@example.com and password is mypassword"
> "Sync my collection with AnkiWeb"Mousetail stores credentials securely in your system's credential manager:
macOS: Keychain
Windows: Credential Manager
Linux: Secret Service (GNOME Keyring, KWallet, etc.)
Available credential tools:
save_sync_credentials - Save username/password securely
load_sync_credentials - Load saved credentials
delete_sync_credentials - Remove saved credentials
The sync_collection tool supports:
AnkiWeb sync (default) - Leave endpoint empty
Self-hosted servers - Provide custom endpoint URL (e.g., https://sync.example.com)
Media sync - Enabled by default, includes images and audio files
Collection-only sync - Set sync_media: false to skip media
First-time setup with AnkiWeb:
> "Save my sync credentials for AnkiWeb - username: user@example.com, password: mypass123"
> "Sync my collection"Using a self-hosted server:
> "Save my sync credentials - username: john, password: secret, endpoint: https://sync.myserver.com"
> "Sync my collection"One-time sync without saving credentials:
> "Sync my collection with AnkiWeb using username user@example.com and password mypass123"Collection-only sync (skip media):
> "Sync my collection but don't sync media files"You can set a default sync endpoint in config.json:
{
"sync": {
"endpoint": "https://sync.example.com"
}
}Leave endpoint as null to use AnkiWeb by default.
Close Anki first: Sync will fail if the Anki application is running
Media sync: Media sync is slower and uses more bandwidth but ensures images/audio are synced
Conflicts: If conflicts occur, try syncing from Anki desktop first to resolve them
Security: Credentials are never stored in plain text - they're kept in your system's secure credential storage
To sync with your own server:
Set up an Anki sync server
Configure credentials on the server (using environment variables like SYNC_USER1=user:password)
Save your credentials in Mousetail with the server endpoint
Sync normally
For detailed sync server setup, see the official Anki documentation.
The MCP server finds Anki collections at their standard locations:
macOS: ~/Library/Application Support/Anki2/[Profile]/collection.anki2
Linux: ~/.local/share/Anki2/[Profile]/collection.anki2
Windows: %APPDATA%\Anki2\[Profile]\collection.anki2
You don't need to configure paths - the server automatically discovers available collections, this can be customized using configuration.
The server can be customized through a config.json file. See the Usage Guide for configuration options.
To develop and test Mousetail locally with Claude Code:
Clone the repository:
git clone https://github.com/listfold/mousetail.git
cd mousetailInstall dependencies:
uv syncConfigure Claude Code:
The project includes a .mcp.json file that configures the MCP server for local development:
{
"mcpServers": {
"mousetail": {
"type": "stdio",
"command": "uv",
"args": ["run", "python", "-m", "mousetail.mcp.stdio_server"],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}Restart Claude Code: After the configuration is in place, restart Claude Code to load the MCP server.
Verify the server:
Use /context in Claude Code to see available MCP tools
The mousetail server should appear with all available tools (list_collections, create_note, sync_collection, etc.)
Testing sync functionality:
Close the Anki desktop application before testing
Test credential management: save_sync_credentials, load_sync_credentials, delete_sync_credentials
Test sync: sync_collection with your AnkiWeb credentials or self-hosted server
Mousetail was written because all the existing MCP Anki tools depend on the AnkiConnect addon.
AnkiConnect is a HTTP server for Anki, it was originally created to support connecting browser extensions like yomichan to Anki. For MCP development, it is not necessary and introduces issues:
introduces complexity e.g. a dedicated HTTP server for Anki occupies a port
introduces risk e.g. if the AnkiConnect API changes or has a bug the MCP tool will break
introduces an extra step e.g. all current MCP tools require installing the AnkiConnect addon
Mousetail has a much simpler approach. It integrates directly with Anki's pylib. This is a stable API that's part of Anki's core, it therefore is not subject to arbitrary or frequent change, and does not require any 3rd-party addons.
Because it prioritizes simplicity, mousetail will remain more stable than the alternatives. The tradeoff is that Mousetail will never integrate with the Anki UI. It is also reasonable to assume that Mousetail will only ever work with colocated (same system) LLM tools and Anki decks.
The project uses Sphinx with the Furo theme to generate documentation from Python docstrings.
Install documentation dependencies:
uv pip install ".[docs]"Build the documentation:
uv run python -m sphinx -b html docs docs/_build/htmlView the documentation:
Open docs/_build/html/index.html in your browser.
The documentation is automatically built and deployed to GitHub Pages on every push to the main branch.
MIT License - see LICENSE file for details.
Create a new deck in the collection
| Name | Required | Description | Default |
|---|---|---|---|
| deck_name | Yes | Name of the deck to create | |
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it does not. It fails to mention whether the tool is idempotent, what happens if a deck with the same name exists, 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, clear sentence. It is appropriately concise for a simple creation 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 tool's simplicity and no output schema, the description is incomplete. It lacks information about the return value, error handling, and does not help differentiate from the many sibling tools.
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 the baseline is 3. The description does not add meaning beyond what the schema already provides for the two parameters.
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 'Create a new deck in the collection', specifying the verb (create) and the resource (deck). It distinguishes itself from sibling tools like create_note, which creates a different entity.
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 provides no guidance on when to use this tool versus alternatives such as list_decks or create_note. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new note (flashcard) in Anki. A note generates one or more cards based on the note type template.
| Name | Required | Description | Default |
|---|---|---|---|
| deck_name | Yes | Name of the deck where the note should be added | |
| note_type_name | Yes | Name of the note type (e.g., 'Basic', 'Cloze') | |
| fields | Yes | Field name to value mapping (e.g., {'Front': 'Question', 'Back': 'Answer'}) | |
| tags | No | Optional list of tags | |
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the note generates cards based on template but lacks details on side effects, validation, or prerequisites. Moderate transparency.
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 highly concise, consisting of two sentences with no wasted words. The first sentence front-loads the primary purpose, and the second adds relevant context.
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 tool's complexity (5 parameters, nested objects, no output schema) and lack of annotations, the description is informative but incomplete. It omits return values, error conditions, and prerequisites, making it adequate but not thorough.
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 parameters are fully described in the schema. The description adds no additional meaning beyond the schema, warranting a baseline score of 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 'Create', the resource 'note (flashcard)', and the context 'Anki'. It also explains the effect of generating cards, distinguishing it from sibling tools like create_deck or update_note.
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 creating new notes but does not explicitly provide when-to-use guidance, when-not-to-use conditions, or alternatives. Given sibling tools, the context is implicit but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete saved sync credentials from system keychain
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the action but fails to disclose behavioral traits such as that deletion is destructive, irreversible, or might break sync functionality. The description is too brief to be transparent.
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 efficiently conveys the tool's purpose. Every word is necessary, and there is no extraneous information.
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 zero parameters, no output schema, and no annotations, the description still lacks important context such as side effects (e.g., breaking sync) and return behavior. A delete operation warrants more guidance.
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 input schema has zero parameters and schema_description_coverage is 100%. With no parameters to document, the description adds no additional meaning, but the baseline for 0 parameters is 4.
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 (Delete) and resource (saved sync credentials from system keychain). It distinguishes from siblings like load_sync_credentials and save_sync_credentials by using the verb 'delete', but does not explicitly contrast them.
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 (e.g., load_sync_credentials, save_sync_credentials). No prerequisites or conditions for deletion are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about an Anki collection (name, card count, note count)
| Name | Required | Description | Default |
|---|---|---|---|
| collection_path | No | Path to collection file (optional, uses default if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It states this is a read operation, which is implied by 'Get information'. It does not mention any side effects, but for a simple read, this is adequate. No contradictions.
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 with a clear list of returned fields. No unnecessary words; every part is informative.
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 low complexity (one optional parameter, no output schema), the description sufficiently covers what an agent needs to know: it returns name, card count, and note count for the collection.
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% for the one parameter (collection_path). The tool description does not add any meaning beyond what the schema already provides, so 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 verb 'Get' and the resource 'Anki collection', and lists the specific information returned (name, card count, note count). This distinguishes it from sibling tools like list_collections, which likely just list collection names, and other tools that modify data.
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 versus alternatives such as list_collections. It does not mention prerequisites, or when to use the optional collection_path parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific note by ID
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | ID of the note to retrieve | |
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only says 'get detailed information' without specifying what fields are returned, any side effects (likely none), or the safety profile. This lacks depth.
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 with no wasted words, effectively conveying the core action in a concise and front-loaded manner.
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 no output schema and minimal annotations, the description is too brief. It does not explain return values, pagination, or error conditions, leaving the agent underinformed for a straightforward retrieval tool.
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 input schema covers 100% of parameters with descriptions, so the tool description adds no additional semantic value beyond confirming the use of note_id. 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 tool retrieves detailed information about a specific note by ID, using a specific verb and resource, and it is distinct from sibling tools like create_note or search_notes.
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 when to use (when you have a note ID), but does not explicitly exclude alternative tools or provide when-not guidance, though the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Anki collections on the system
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the action without disclosing read-only nature, side effects, or return behavior. The agent cannot assess safety or impact from this description.
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?
A single sentence of 7 words is maximally concise. Every word is necessary, and no extraneous information is present.
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?
Despite having no parameters, the tool lacks output schema and annotations. The description does not explain what a 'collection' is, the format of results, or whether multiple collections can exist. An agent needs more context to interpret the tool's output correctly.
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, and the schema coverage is 100% (trivially). With no parameters, the description does not need to add parameter meaning. Baseline for 0 params is 4, and there is no missing information.
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 states a specific action ('List') and resource ('Anki collections'), distinguishing it from siblings like 'list_decks'. However, the term 'collections' is not further clarified, which could cause ambiguity for an AI agent unfamiliar with Anki's terminology.
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 'get_collection_info' or other list tools. The description does not mention prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all decks in the collection with their names and IDs
| Name | Required | Description | Default |
|---|---|---|---|
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for disclosure. It only states what the tool does but does not mention side effects, permissions, rate limits, or return structure beyond names and IDs.
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 of 10 words that directly conveys the tool's purpose. No filler or redundant information.
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 list operation with one optional parameter, the description is mostly complete. However, without an output schema, it could specify the format of the returned list (e.g., array of objects). Minor gap.
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% with one parameter described. The description does not add additional meaning beyond the schema; it simply echoes the parameter's purpose.
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 the action (list all decks) and the data returned (names and IDs). It distinguishes itself from sibling tool 'list_collections' by specifying decks rather than collections.
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 or when not to use it. The description is purely functional and lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all note types (card templates) available in the collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose that the operation is read-only, nor any other behavioral traits like performance, permissions, or 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?
Single sentence, no waste. Front-loaded with the action and resource.
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?
Lacks explanation of what 'the collection' refers to, and since there is no output schema, the description should describe the return value but does not. Incomplete for a simple tool.
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 baseline 3 applies. The description adds no extra meaning beyond the schema's parameter description; it does not explain the optional parameter further.
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 'List all note types (card templates)' with a specific verb and resource, and the parenthetical clarification helps. It distinguishes from sibling tools like list_collections and list_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 on when to use this tool versus alternatives, such as when the collection path is needed or not. No context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load saved sync credentials from system keychain
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states the action without disclosing outcomes (e.g., error if no credentials, return format), preconditions (keychain access), or 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?
Single, concise sentence with no fluff. Front-loaded and clear.
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?
Adequate for a zero-parameter tool but lacks context about its role in sync workflow (e.g., pre-condition for sync) and whether it is read-only (safe to call repeatedly).
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?
No parameters exist, and schema coverage is 100%. Description adds no parameter info, which is acceptable given no params.
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 action (Load), resource (sync credentials), and source (system keychain), distinguishing it from siblings save_sync_credentials and delete_sync_credentials.
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 (e.g., before sync) or when to avoid it (e.g., if credentials already loaded). No mention of alternatives within siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save sync credentials securely to system keychain (macOS Keychain, Windows Credential Manager, or Linux Secret Service)
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | AnkiWeb ID or sync server username | |
| password | Yes | Account password | |
| endpoint | No | Sync server URL (optional). Leave empty for AnkiWeb. Example: https://sync.example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It does not disclose critical behavioral traits such as whether the tool overwrites existing credentials, validates the input, or requires specific permissions. This is insufficient for a write operation.
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?
Description is a single concise sentence that communicates the core purpose clearly. It is front-loaded and efficient, though could benefit from breaking down parameter details already in schema.
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 security-sensitive tool with 3 parameters and no output schema, the description is minimal. It does not explain return values, error handling, or side effects (e.g., overwriting). More context is needed for safe 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?
Input schema covers 100% of parameters with descriptions. The description adds no new information beyond what the schema already provides. For high schema coverage, 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?
Description clearly states the verb (save), resource (sync credentials), and storage mechanism (system keychain with platform specifics). It is distinct from sibling tools like load_sync_credentials and delete_sync_credentials, making the tool's purpose unambiguous.
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 storing credentials but does not explicitly state when to use this tool versus alternatives (e.g., load or delete). The sibling tool names provide context, but explicit guidance on when to call this tool is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for notes using Anki search syntax. Examples: 'deck:MyDeck', 'tag:important', 'front:python'
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Anki search query | |
| limit | No | Maximum number of results (optional) | |
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It does not explain output format (e.g., returns note IDs or full notes), pagination, performance implications, or error handling, leaving significant behavioral ambiguity.
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?
Extremely concise: two sentences that immediately state the action, syntax, and examples. No wasted words; information density is high and front-loaded.
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 tool's search complexity and lack of output schema, the description falls short. Missing details on return structure, behavior when syntax is invalid, and how results are ordered. Sibling context hints at other notes-related tools but no cross-referencing.
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. The description adds value by illustrating valid query syntax with examples, but does not clarify the default limit value (100) or usage of collection_path, which the schema already describes.
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 tool searches for notes using Anki search syntax and provides concrete examples (e.g., deck:MyDeck, tag:important, front:*python*), making the purpose unambiguous and distinct from siblings like get_note which retrieves a single known note.
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 get_note or list_notes. The description does not specify prerequisites, limitations, or scenarios where search is preferred over direct navigation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synchronize Anki collection with AnkiWeb or a self-hosted sync server. Uploads local changes and downloads remote changes. By default syncs both collection data and media files.
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | AnkiWeb ID or sync server username (optional if saved) | |
| password | No | Account password (optional if saved) | |
| endpoint | No | Sync server URL (optional). Leave empty for AnkiWeb. Example: https://sync.example.com | |
| sync_media | No | Include media files (images, audio) in sync (default: true) | |
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses two-way sync and media default but omits conflict handling, error scenarios, and safety profile. Adequate but not comprehensive.
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?
Two sentences with no redundancy. First sentence immediately states purpose and scope. Every word earns its place.
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?
Adequate given no output schema: explains sync direction and media. Missing authentication guidance and behavioral details like conflict resolution, but not incomplete.
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 5 parameters with descriptions (100% coverage). Description adds minimal value by restating media default. Baseline score of 3 applies.
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 the verb 'synchronize' and the resource 'Anki collection', specifying both directions (upload/download) and media inclusion. Distinguishes from siblings as the only sync tool.
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?
Implies usage for syncing collection, but lacks explicit when-to-use vs alternatives, prerequisites (e.g., credentials), or exclusions. No sibling differentiation beyond being the only sync tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing note's fields and/or tags
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | ID of the note to update | |
| fields | No | Field name to value mapping for fields to update | |
| tags | No | New list of tags (replaces existing tags) | |
| collection_path | No | Path to collection file (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose whether the note must exist, how errors are handled, or whether fields merge or replace. With no annotations, the description carries the burden but provides minimal behavioral context.
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?
One sentence, efficient and to the point. No wasted words, though it could be slightly improved by front-loading the action.
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 or annotations. The description does not indicate what the tool returns (e.g., updated note or success status). For a mutation tool with no return info, this is insufficient.
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 baseline is 3. The summary 'fields and/or tags' adds minimal value beyond the schema, which already describes each parameter.
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), the resource (existing note), and the scope (fields and/or tags), differentiating it from create_note and get_note.
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 vs alternatives like create_note or when not to use it. No context for prerequisites or conditions.
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.5create_deckcreate_notedelete_sync_credentialsget_collection_infoget_notelist_collectionslist_deckslist_note_typesload_sync_credentialssave_sync_credentialssearch_notessync_collectionupdate_noteEach tool targets a distinct entity or action (deck, note, collection, sync, credentials, note types). No two tools have overlapping purposes; listing tools are clearly differentiated by entity.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., create_deck, get_note, sync_collection. No mixing of styles or ambiguous verbs.
13 tools is well-scoped for Anki management, covering deck, note, collection, sync, and credential operations without unnecessary bloat.
Missing delete operations for notes and decks, and no update_deck. These are significant gaps for a CRUD-oriented flashcard server, potentially causing agent failures when trying to remove content.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI dialogue using various LLM models via AceDataCloud
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/listfold/mousetail'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
