The Anki MCP Server enables interaction with Anki flashcard software, allowing you to:
List decks: View all available decks
Create decks: Establish new decks by name
Manage notes:
Create individual notes (Basic or Cloze)
Batch create multiple notes
Search notes using Anki query syntax
View detailed note information
Update existing notes (modify tags and fields)
Delete notes
Handle note types:
List available note types
Create custom note types with fields, templates, and CSS
Get detailed structure information
Access resources via endpoints like anki://decks/all and anki://note-types/all
Enables interaction with Anki flashcard software through AnkiConnect, providing tools for managing decks, creating various types of flashcards (Basic and Cloze), searching notes, and manipulating note types.
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., "@Anki MCP Server create a flashcard for the capital of France"
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.
A Model Context Protocol (MCP) server that enables LLMs to interact with Anki flashcard software through AnkiConnect.
anki_check_connection - Check whether AnkiConnect is reachable
anki_list_decks - List all available Anki decks, optionally with deck IDs
anki_create_deck - Create a new Anki deck
anki_list_tags - List all tags currently used in the collection
anki_add_note_tags - Add tags to one or more notes
anki_remove_note_tags - Remove tags from one or more notes
anki_create_note - Create a new note
anki_batch_create_notes - Create multiple notes at once
anki_search_notes - Search for notes using Anki query syntax
anki_get_note_info - Get detailed information about a note
anki_update_note - Update an existing note's fields and/or tags
anki_delete_note - Delete one or multiple notes
anki_list_note_types - List all available note types
anki_create_note_type - Create a new note type
anki_get_note_type_info - Get detailed structure of a note type
anki_sync - Trigger AnkiWeb sync (fire-and-forget; success means Anki accepted the request, not that AnkiWeb received the data; a blocking dialog in Anki can silently keep the sync queued)
Legacy unprefixed tool names such as create_note and list_decks remain callable for existing clients, but new agent integrations should use the anki_* names.
anki://decks/all - Complete list of available decks with deck IDs
anki://tags/all - Complete list of tags
anki://note-types/all - List of all available note types
anki://note-types/all-with-schemas - Detailed structure information for all note types
anki://note-types/{modelName} - Detailed structure information for a specific note type
Related MCP server: Anki MCP Server
Anki installed on your system
AnkiConnect add-on installed in Anki
Node.js 20.11 or newer
This repository supports Anthropic Desktop Extensions (MCPB). The easiest way to use this server in Claude Desktop is by installing the packaged .mcpb bundle.
Generate the .mcpb file locally using the provided script:
npm run mcpbOpen Claude Desktop Settings → Extensions and drag the generated .mcpb file in, then click Install.
This validates manifest.json and outputs a .mcpb archive you can install as above. Learn more about Desktop Extensions in Anthropic's announcement: Desktop Extensions: One-click MCP server installation for Claude Desktop.
Add the server to your claude_desktop_config.json:
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server"]
}
}
}If your AnkiConnect is running on a different port, you can specify it using the --port parameter:
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server", "--port", "8080"]
}
}
}Add the server to your Cline MCP settings file inside VSCode's settings cline_mcp_settings.json
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server"]
}
}
}For Cline, you can also specify a custom port:
{
"mcpServers": {
"anki": {
"command": "npx",
"args": ["--yes", "anki-mcp-server", "--port", "8080"]
}
}
}Install the Anki skill to give Claude Code built-in knowledge of all Anki tools and workflows:
npx skills add nailuoGG/anki-mcp-server@ankiOnce installed, Claude Code will automatically use the skill when you ask it to create flashcards, manage decks, or batch import notes.
Note: Do not use the
.mcpbpackaged version as the MCP server — it outputs Electron metadata to stdout which breaks the MCP stdio protocol. Usenpx -y anki-mcp-serverinstead.
Create a distributable Desktop Extension bundle for Claude Desktop:
npm run mcpbThis will build the project and generate a .mcpb archive from the current repository, validating manifest.json. Test by dragging it into Claude Desktop's Extensions settings. Reference: Desktop Extensions: One-click MCP server installation for Claude Desktop.
This server is automatically published to the MCP Registry when a new version is released. The publishing process includes:
Automated CI/CD: GitHub Actions automatically publishes to both NPM and MCP Registry on successful releases
Schema Validation: The server.json file is validated against the MCP schema before publishing
Version Synchronization: Versions are kept in sync between package.json, manifest.json, and server.json
Comprehensive Testing: Multi-version Node.js testing, linting, and validation before publishing
Beta Support: Automated beta releases for testing new features
You can validate the MCP server configuration locally:
npm run validate-mcpThis will download the latest MCP schema and validate your server.json file.
If you need to publish manually, you can use the MCP Publisher CLI:
# Install MCP Publisher
curl -L "https://github.com/modelcontextprotocol/registry/releases/download/v1.1.0/mcp-publisher_1.1.0_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher
chmod +x mcp-publisher
sudo mv mcp-publisher /usr/local/bin/
# Login to MCP Registry
mcp-publisher login github-oidc
# Publish to MCP Registry
mcp-publisher publishInstall dependencies:
npm installBuild the server:
npm run buildFor development with auto-rebuild:
npm run watchRun the test suite:
npm testThis executes unit tests for MCP tool schemas, structured tool results, note creation, search/update/delete workflows, and error handling. These tests use mocked AnkiConnect clients; use MCP Inspector with a running Anki instance for manual integration checks.
Read-only agent evaluation assets live in evals/. Load the fixture into a disposable Anki profile, then run the XML questions against the MCP server to verify that agents can discover decks, tags, note type schemas, resources, and structured tool results.
Since MCP servers communicate over stdio, we recommend using the MCP Inspector:
npm run inspectorThis provides a browser-based interface for:
Monitoring MCP messages
Testing tool invocations
Viewing server logs
Debugging communication issues
Create a new deck:
Create a new Anki deck called "Programming"Add a basic card:
Create an Anki card in the "Programming" deck with:
Front: What is a closure in JavaScript?
Back: A closure is the combination of a function and the lexical environment within which that function was declared.Add a cloze deletion card:
Create a cloze card in the "Programming" deck with:
Text: In JavaScript, {{c1::const}} declares a block-scoped variable that cannot be {{c2::reassigned}}.Delete a single note:
Delete note ID 1234567890Delete multiple notes at once:
Delete note IDs 1234567890, 9876543210, and 1122334455Add tags to notes:
Add tags "review" and "mcp" to note IDs 1234567890 and 9876543210Fork the repository
Create your feature branch
Run tests: npm test
Submit a pull request
Icon courtesy of macOS Icons
MIT License - see LICENSE file for details
Use when the user wants to add one or more tags to existing notes for organization. Do not use when the user wants to remove tags (use anki_remove_note_tags) or update note content (use anki_update_note). Safety: confirm before adding tags to a large number of notes.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Tags to add. Use Anki tag names without whitespace. | |
| noteId | No | Single note ID to update. | |
| noteIds | No | Multiple note IDs to update. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| noteIds | Yes | |
| success | Yes | |
| operation | Yes | |
| updatedCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and not read-only/not destructive. Description adds safety confirmation guidance, which is useful behavioral context beyond annotations. 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?
Three sentences are efficient: first states purpose, second gives exclusions, third provides safety tip. 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?
Given the tool's simplicity, presence of annotations, and existence of an output schema, the description covers all essential aspects: when to use, alternatives, safety, and parameter usage is handled by schema. No 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 coverage is 100%, so baseline 3. Description does not add any additional semantics beyond what the schema already provides for parameters (tags, noteId, noteIds).
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 tool adds tags to notes, with explicit verb 'add' and resource 'tags to existing notes'. It also distinguishes from siblings by specifying when NOT to use and naming alternatives (anki_remove_note_tags, anki_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?
Explicitly provides when-to-use ('when the user wants to add one or more tags') and when-not-to-use ('Do not use when...'), with named alternative tools. Also includes safety guidance for large batches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to create multiple study cards at once (2–50 notes). Prefer this over repeated anki_create_note calls. Returns per-note success and error details. Safety: ask the user to confirm before creating a large batch of notes.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | Yes | Notes to create. | |
| stopOnError | No | Stop after the first failed note. | |
| allowDuplicate | No | Allow duplicate notes in their target decks. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| failed | Yes | |
| results | Yes | |
| successful | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states that per-note success and error details are returned, and that a confirmation prompt is needed for large batches. Annotations indicate the tool is not read-only, so the description confirms mutation without contradicting annotations.
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 two sentences, front-loaded with the purpose and followed by return details and safety. Every sentence adds value with no redundancy, achieving conciseness without sacrificing clarity.
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 has an output schema, the description does not need to explain return values in detail. It covers the use case, preference over sibling, return type, and safety. It could be slightly more explicit about the confirmation prompt's format, but overall it is 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?
Schema description coverage is 100%, with detailed parameter descriptions (e.g., field maps like {Front: 'question', Back: 'answer'}). The description does not add significant semantics beyond what the schema already provides, so a 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 creates multiple study cards at once (2–50 notes) and explicitly differentiates from the sibling tool anki_create_note by preferring this tool over repeated calls. The verb 'batch create' is specific and matches the tool name.
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 explicit guidance on when to use this tool (batch of 2-50 notes) and when not (prefer over repeated anki_create_note calls). It also includes a safety instruction to ask the user before creating a large batch, covering key context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether AnkiConnect is reachable and return the API version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| version | Yes | |
| connected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal extra behavioral context (returning API version). No contradictions. Adequately complements annotations.
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, front-loaded with action and outcome, no wasted words. Perfectly concise for a no-parameter 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 zero parameters and an output schema, the description fully covers what the tool does. No missing information for an agent to use it 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?
No parameters exist, and schema coverage is 100%. The description adds no parameter info because none are needed. 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 verb 'Check' and the resource 'AnkiConnect' and specifies the outcome 'return the API version'. It distinguishes from siblings like anki_list_decks or anki_sync by focusing on connectivity rather than data manipulation.
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, but the purpose is self-evident as a readiness check before other operations. Implied usage is adequate for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an Anki deck by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Deck name to create. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| deckId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds no extra behavioral context beyond these hints, but it does not contradict them either. For a simple creation tool, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence. It is front-loaded with the verb and resource, containing no unnecessary words. 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?
Given the tool's simplicity and the presence of an output schema, the description sufficiently covers the core functionality. However, it could mention deck naming conventions (e.g., nesting with '::') or uniqueness constraints, though these are not critical.
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% (one parameter with a description). The description says 'by name', which adds little beyond the schema's 'Deck name to create.' Baseline score of 3 is appropriate as the schema already provides the semantics.
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' and the resource 'Anki deck', distinguishing it from other tools like anki_list_decks or anki_create_note. However, it is minimal and does not elaborate on what creation entails (e.g., empty deck).
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 siblings like anki_list_decks or anki_create_note, nor does it mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to create a single new study card (note) in an existing deck. Creates user study content — not a schema change. Do not use when the user only wants to inspect existing notes, decks, tags, or note types. To define a new note structure, use anki_create_note_type instead. Call anki_get_note_type_info first for custom fields. For multiple notes, use anki_batch_create_notes. Safety: confirm with the user before creating notes if intent is unclear.
| Name | Required | Description | Default |
|---|---|---|---|
| deck | Yes | Target deck name. The deck is created if it does not exist. | |
| tags | No | Optional tags for organization. Use strings without spaces for best Anki compatibility. | |
| type | Yes | Note type/model name. Common: Basic, Cloze. | |
| fields | Yes | Note fields keyed by exact model field names. For Basic: {Front: 'question', Back: 'answer'}. | |
| allowDuplicate | No | Allow duplicate notes in the target deck. |
| Name | Required | Description |
|---|---|---|
| deck | Yes | |
| noteId | Yes | |
| modelName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). Description adds that it creates user study content (not a schema change) and includes a safety confirmation requirement. No contradictions with annotations.
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 efficient, with three front-loaded sentences that cover purpose, usage guidance, and safety. No redundant or unnecessary 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 tool's complexity (5 parameters, nested objects, output schema exists), the description adequately covers usage context, safety, and sibling differentiation. It is sufficiently complete for an agent to select and invoke 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?
Schema description coverage is 100% with detailed descriptions for each parameter, including examples. The description does not add additional meaning beyond the schema, so a baseline 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 it is for creating a single study card (note) in an existing deck, using specific verbs and resources. It distinguishes itself from inspecting notes (anki_get_note_info), defining new note structures (anki_create_note_type), and batch creation (anki_batch_create_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?
Explicitly provides when to use (user wants to create a single note), when not to use (inspection, schema changes), and alternatives including anki_get_note_type_info, anki_batch_create_notes, and anki_create_note_type. Also advises confirming with user if intent is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to define a new note schema/model with custom fields and card templates. Modifies the Anki collection structure — not for creating study content. Do not use when the user wants to create notes (use anki_create_note) or inspect an existing note type (use anki_get_note_type_info). Safety: confirm with the user before creating a new note type, as this changes the collection schema.
| Name | Required | Description | Default |
|---|---|---|---|
| css | No | Optional model CSS. | |
| name | Yes | New note type name. | |
| fields | Yes | Field names in order. | |
| templates | Yes | Card templates. |
| Name | Required | Description |
|---|---|---|
| fields | Yes | |
| success | Yes | |
| modelName | Yes | |
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but description adds behavioral context: 'Modifies the Anki collection structure' and 'changes the collection schema.' This goes beyond annotations. Safety note adds transparency. No contradiction.
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 plus a safety note. Front-loaded with main purpose. 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?
Tool is moderately complex (4 params, 3 required) and has output schema (not shown but indicated). Description covers purpose, behavior, and alternative tools. Missing error handling (e.g., duplicate name) but overall 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?
Schema coverage is 100%, so baseline 3. Description mentions 'custom fields and card templates' which maps to parameters, but adds no detail beyond the schema. No extra semantic guidance.
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' and resource 'note type' (note schema/model). It distinguishes from sibling tools: not for creating notes (anki_create_note) or inspecting existing note types (anki_get_note_type_info).
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?
Explicitly states when to use: 'Use when the user wants to define a new note schema/model with custom fields and card templates.' Provides when-not: 'Do not use when the user wants to create notes' or inspect existing note types, with specific alternative tool names. Also includes a safety note to confirm with user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user explicitly asks to permanently delete one or more notes. Do not use when the user only wants to inspect, search, or update notes. Safety: always confirm with the user before deleting any note — this action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | No | Single note ID to delete. | |
| noteIds | No | Multiple note IDs to delete. |
| Name | Required | Description |
|---|---|---|
| noteIds | Yes | |
| success | Yes | |
| deletedCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral context: 'this action is irreversible' and the mandatory confirmation step. This goes beyond what annotations alone convey.
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 with only two sentences, no filler, and front-loads the primary use case. Every sentence adds value.
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 simple parameter set (2 optional parameters, fully described in schema), presence of annotations, and output schema (not shown but known), the description is sufficiently complete. It covers purpose, usage, and safety without 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 coverage is 100%, so the baseline is 3. The description adds no additional parameter details beyond what the schema already provides (e.g., noteId vs noteIds, minimum values).
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's purpose: permanently delete notes. It uses specific verb and resource ('delete one or more notes') and distinguishes from sibling tools by specifying when not to use it (inspect, search, update).
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?
Explicit usage guidance is provided: use when the user explicitly asks to delete, not for inspect/search/update. Also includes a safety guideline to always confirm with the user, which is critical for a destructive action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for one note ID.
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | Yes | Positive Anki note ID. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| fields | Yes | |
| noteId | Yes | |
| modelName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and description does not add behavioral traits beyond stating it gets information. No mention of exceptions 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 with no wasted words, perfectly front-loaded and to the point.
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 presence of an output schema and simple read-only nature, the description is adequate. Could mention what fields are returned, but not necessary for completeness.
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 noteId, and the description merely repeats 'one note ID'. No additional semantic value added 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 'Get detailed information for one note ID' with a specific verb and resource, distinguishing it from sibling tools like anki_search_notes that handle multiple 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?
Implied usage for a single note ID, but no explicit guidance on when to use or when to avoid, nor reference to alternative tools for searching or updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when inspecting a note type before creating or updating notes, especially for non-standard models. Returns fields and card templates. Call this before anki_create_note when using a custom note type. Do not use when the user wants to create notes or modify a note type.
| Name | Required | Description | Default |
|---|---|---|---|
| modelName | Yes | Note type/model name. | |
| includeCss | No | Include CSS styling when true. |
| Name | Required | Description |
|---|---|---|
| css | No | |
| fields | Yes | |
| modelName | Yes | |
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds that it returns fields and templates, giving useful context beyond annotations. 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?
Three sentences, no wasted words, front-loaded with purpose. Efficient 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?
Covers purpose, usage context, return value, and works with output schema. Adequate for a read-only tool with good annotations and 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 both parameters described. Description does not add additional parameter details beyond the schema, so baseline 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 tool inspects a note type, returning fields and card templates. It specifies the verb 'inspecting' and the resource 'note type', and distinguishes from sibling tools like anki_create_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?
Explicitly states when to use: before creating or updating notes, especially for non-standard models. Also gives a do-not-use case: when user wants to create or modify a note type.
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 decks, optionally with deck IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| includeIds | No | Include a deckIds object keyed by deck name when true. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| decks | Yes | |
| deckIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's mention of 'List' is consistent but adds no further behavioral insight (e.g., sorting, performance, or behavior when no decks exist).
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, clear sentence front-loading the action; no unnecessary words or redundancy.
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 tool with one optional boolean parameter and an output schema (indicated), the description fully covers the tool's purpose and option.
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 single parameter; the description reiterates the option ('optionally with deck IDs') but adds no new meaning beyond the schema's description.
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 explicitly states 'List all available Anki decks' with a clear verb and resource, and mentions the optional inclusion of deck IDs, distinguishing it from sibling tools like anki_create_deck or anki_delete_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 such as anki_search_notes or anki_get_note_info; lacks context on prerequisites or limitations.
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 note types/models.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| noteTypes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false, so the description's claim of listing 'all available' note types is consistent and adds no new behavioral context beyond what annotations provide. No additional traits like performance or side effects are disclosed.
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 extraneous words. Every word serves the purpose, making it 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 read-only listing tool with no parameters and an output schema, the description is appropriately minimal. The output schema handles return value details, so the description adequately covers the necessary context.
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 schema coverage is 100%. With no parameters to explain, the description need not add parametric information, earning a baseline score of 4 per guidelines.
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 lists all available Anki note types/models, using a specific verb and resource. It distinguishes itself from sibling tools like anki_list_decks or anki_list_tags, which have different purposes.
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 anki_get_note_type_info for a specific note type. It does not mention prerequisites or typical use cases, 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 tags currently used in the Anki collection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states it lists 'all tags currently used,' which is transparent about scope. Annotations already declare readOnlyHint=true, so the read-only nature is covered. No contradictions. It adds minor context beyond annotations (scope of current usage) but is sufficient.
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 wasted words. Front-loaded with the action and resource. Excellent 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?
Despite simplicity, the description is complete for the tool's purpose. An output schema exists, so return values are documented elsewhere. No additional context is needed for this straightforward list operation.
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%. The description does not need to add parameter info. Baseline score of 3 is appropriate as the schema already fully documents 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?
Description clearly states it lists all tags in the Anki collection. It uses a specific verb ('list') and resource ('tags'). However, it does not differentiate from sibling tools that list other entities like decks or note types, which could cause ambiguity.
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 when an agent needs to see all tags, but it provides no explicit guidance on when to use this tool versus alternatives like anki_add_note_tags or anki_search_notes. For a simple tool, the lack of exclusions is acceptable but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to remove specific tags from one or more existing notes. Do not use when the user wants to add tags (use anki_add_note_tags) or clear all tags (use anki_update_note with an empty tags array). Safety: confirm with the user before removing tags, as this modifies note metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Tags to remove. Use Anki tag names without whitespace. | |
| noteId | No | Single note ID to update. | |
| noteIds | No | Multiple note IDs to update. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| noteIds | Yes | |
| success | Yes | |
| operation | Yes | |
| updatedCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false; the description adds the crucial safety warning to confirm with the user before modifying metadata, providing actionable behavioral guidance beyond the annotations.
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?
Three focused sentences: first defines use, second excludes alternatives, third adds safety. No waste, front-loaded with key 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 tool has an output schema and the description covers usage, exclusions, and safety, it is fully complete for an agent to correctly invoke the 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 is 3. The description does not add extra parameter-level meaning beyond what the schema already provides.
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 tool removes specific tags from notes, uses a specific verb+resource, and distinguishes from siblings by explicitly excluding add and clear-all operations.
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?
Explicitly states when to use (remove specific tags) and when not to use (add tags, clear all tags), with direct references to alternative tools (anki_add_note_tags, anki_update_note). Also includes a safety instruction to confirm with the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search notes with Anki query syntax and return paginated note details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum note details to return. | |
| query | Yes | Anki search query. | |
| offset | No | Zero-based note result offset. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| notes | Yes | |
| query | Yes | |
| total | Yes | |
| offset | Yes | |
| hasMore | Yes | |
| nextOffset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'Search' and 'paginated' adds some context about pagination behavior but does not delve into other traits like rate limits or return format. The description does not contradict annotations.
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, well-structured sentence that front-loads the main action and resource. It is concise with no 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 search tool with a full schema and output schema, the description covers the core concepts: query syntax, pagination, and note details. However, it could briefly mention the query syntax format or that results are paginated note objects to be more 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?
Schema coverage is 100% with descriptions for all three parameters. The description mentions 'paginated' which hints at limit/offset, but adds no additional meaning beyond the schema definitions.
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 'Search', the resource 'notes', and specifies 'Anki query syntax' and 'paginated note details'. It effectively distinguishes from siblings like anki_get_note_info which retrieves a single note by ID.
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 via 'Search notes with Anki query syntax' but does not explicitly state when to use this tool over siblings (e.g., for filtering vs. fetching a known note). No when-not or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request AnkiWeb sync. Success means Anki accepted the request, not that AnkiWeb completed it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that success indicates request acceptance, not completion—a key behavioral trait beyond annotations. No contradictions found.
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 front-loaded sentences with no wasted words; every sentence adds value.
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?
With an output schema present, the description adequately covers the tool's basic behavior. It could mention prerequisites but remains sufficiently complete for a simple sync request.
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, so schema coverage is 100%. Per guidelines, 0 parameters defaults to a baseline of 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 uses a specific verb ('Request sync') and resource ('AnkiWeb'), clearly distinguishing this tool from siblings that perform CRUD operations on cards, decks, notes, etc.
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?
It implies sync is for connecting to AnkiWeb but does not explicitly state when to use it (e.g., after changes) or provide exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants to edit the fields or replace the tags of an existing note. Do not use when the user only wants to inspect note content (use anki_get_note_info) or delete it (use anki_delete_note). Safety: confirm with the user before overwriting note content.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Positive Anki note ID. | |
| tags | No | Replacement tag list. Pass an empty array to clear tags. | |
| fields | No | Note fields keyed by exact model field names. For Basic: {Front: 'question', Back: 'answer'}. |
| Name | Required | Description |
|---|---|---|
| noteId | Yes | |
| success | Yes | |
| updatedTags | Yes | |
| updatedFields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark destructiveHint=true and idempotentHint=true. Description adds 'confirm with the user before overwriting note content.' However, it could further clarify whether tags replace or merge, and the exact impact on existing fields.
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?
Three sentences: first states purpose, second provides exclusions, third adds safety advice. Front-loaded and no unnecessary 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?
Annotations cover safety and idempotency. Output schema exists so return values need no explanation. Description covers usage, alternatives, and parameter details completely.
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 has 100% coverage with detailed descriptions. Description adds value by explaining 'empty array clears tags' and giving an example for field structure (Basic type).
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 tool edits fields or replaces tags of an existing note. It distinguishes from inspection (anki_get_note_info) and deletion (anki_delete_note), providing specific verb+resource.
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?
Explicitly states when to use (edit fields/replace tags), when not to use (inspect or delete), and gives alternative sibling tools. Also includes a safety confirmation guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose, e.g., adding vs removing tags, creating single vs batch notes, and inspecting vs searching notes. Descriptions clearly differentiate them, reducing ambiguity.
All tools use the consistent 'anki_verb_noun' pattern (e.g., anki_list_decks, anki_create_note). No mixing of styles or vague verbs.
16 tools cover the essential Anki operations—notes, decks, note types, tags, sync, and connection check—without being excessive or sparse for the domain.
Core CRUD for notes and decks is present, but missing deck deletion/update and note type update/delete. However, search and batch operations fill many gaps, so agents can mostly complete workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nailuoGG/anki-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
