Interact with Anki flashcard software via AnkiConnect: manage decks, tags, notes, note types, and sync with AnkiWeb.
Check AnkiConnect connection and API version.
List and create Anki decks.
List tags; add or remove tags on notes.
Create single or batch notes; search, inspect, update, and delete notes.
List note types; inspect note type schemas; create new note types.
Trigger AnkiWeb sync (requires confirmation).
Access resources for all decks, tags, and note types with schemas.
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 "Deploy 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; requires {"confirm": true} because a full sync can merge or overwrite local and remote collections. 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 declare destructiveHint=true and readOnlyHint=false, but the description adds value beyond them by stating the action is irreversible and mandating an explicit user confirmation step. It does not mention the idempotent behavior declared in annotations, but it does not contradict it either.
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 short sentences, each earning its place: purpose, exclusion, and safety. The most important scoping constraint is front-loaded in the first sentence.
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?
An output schema exists so return values need no explanation, annotations cover the safety profile, and the description supplies the irreversibility warning and confirmation requirement. Nothing an agent needs to call this correctly is missing.
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% — both noteId and noteIds are documented, and the oneOf branching is expressed structurally. The description adds no format or constraint detail beyond the schema, so the baseline 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?
States a specific verb and resource ('permanently delete one or more notes') and immediately distinguishes the tool from siblings that inspect, search, or update notes. An agent can tell it apart from anki_update_note or anki_search_notes without opening any schema.
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 gives the when ('user explicitly asks to permanently delete') and the when-not ('only wants to inspect, search, or update'). It also names the safety precondition of confirming before the call, which is actionable routing guidance.
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. Requires {"confirm": true}: without it the call is refused, because a full sync can merge or overwrite local and remote collections. Success means Anki accepted the request, not that AnkiWeb completed it.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be true to perform the sync. Omitted or false returns a refusal without contacting AnkiWeb. |
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the refusal gate, the real risk that a full sync can merge or overwrite local and remote collections, and the crucial caveat that success means Anki accepted the request, not that AnkiWeb finished. None of that is derivable from readOnlyHint/destructiveHint/idempotentHint.
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 tight sentences with no filler, and the precondition ('Requires {"confirm": true}') is front-loaded before the risk and result semantics. Every sentence carries 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?
With an output schema present, the description need not describe return values, yet it still clarifies the meaning of a successful response (accepted, not completed) and the destructive potential of a full sync. Nothing an agent needs before calling is missing.
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% and the single parameter's description already spells out the confirm-true requirement and refusal behavior, so the schema does the heavy lifting. The description restates the same gate without adding format or edge-case detail beyond it.
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?
States a specific verb and resource ('Request AnkiWeb sync') that is unmistakably distinct from the note/deck/tag CRUD siblings. An agent can tell at a glance this is the collection-sync operation, not a content mutation.
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 gives the operative condition for invoking the tool (must pass confirm:true) and what happens otherwise (refusal without contacting AnkiWeb). No alternative tool is named, but no sibling overlaps this operation, so routing is unambiguous.
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 |
|---|---|---|---|
| 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'}. | |
| noteId | Yes | Positive Anki note ID. |
| 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 already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely covered. The description adds actionable behavioral guidance beyond them: confirm with the user before overwriting note content. It does not say whether omitted parameters leave existing values untouched, which is the one behavioral question an agent still has.
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 short sentences, front-loaded with the when-to-use condition, then exclusions, then the safety caveat. Every sentence carries a distinct decision-relevant fact and none is padding.
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?
An output schema exists so return values need no explanation, and annotations cover the destructive/idempotent profile. The description plus schema cover intent routing, tag replacement, field keying, and the confirmation requirement; the only residual gap is partial-update behavior when only one of fields/tags is supplied.
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%, and the schema already spells out the important semantics (empty array clears tags, fields keyed by exact model field names, positive note ID). The description's 'replace the tags' merely restates what the schema documents, so baseline 3 is right.
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?
States a specific verb+resource pair (edit fields / replace tags of an existing note) that an agent can match to a user intent without opening the schema. It also names the sibling tools it is not (anki_get_note_info, anki_delete_note), so it is distinguishable from the other note-level tools.
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?
Gives explicit positive conditions ('user wants to edit the fields or replace the tags') and explicit negative conditions with the correct alternative for each ('only wants to inspect' -> anki_get_note_info, 'delete it' -> anki_delete_note). Routing is unambiguous.
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.
v0.2.0anki_delete_note1 field changedInput schema / oneOfAdded value: +[
+ {
+ "required": [
+ "noteId"
+ ]
+ },
+ {
+ "required": [
+ "noteIds"
+ ]
+ }
+]anki_sync1 field changedInput schema / properties / confirmAdded value: +{
+ "description": "Must be true to perform the sync. Omitted or false returns a refusal without contacting AnkiWeb.",
+ "type": "boolean"
+}anki_update_note3 fields changedInput schema / properties / idRemoved value: -{
- "description": "Positive Anki note ID.",
- "minimum": 1,
- "type": "number"
-}Input schema / properties / noteIdAdded value: +{
+ "description": "Positive Anki note ID.",
+ "minimum": 1,
+ "type": "number"
+}Input schema / requiredPrevious value: -[
- "id"
-]New value: +[
+ "noteId"
+]v0.1.8anki_add_note_tagsanki_batch_create_notesanki_check_connectionanki_create_deckanki_create_noteanki_create_note_typeanki_delete_noteanki_get_note_infoanki_get_note_type_infoanki_list_decksanki_list_note_typesanki_list_tagsanki_remove_note_tagsanki_search_notesanki_syncanki_update_noteScored across 16 tools
Each tool targets a distinct resource+action, and descriptions explicitly say when NOT to use a tool (e.g. update vs inspect vs delete notes), which strongly aids selection. Minor potential confusion exists between anki_create_note/anki_batch_create_notes and anki_list_note_types/anki_get_note_type_info, but the descriptions disambiguate these well.
All 16 tools consistently follow anki_<verb>_<noun> snake_case (get_note_info, list_decks, create_note, add_note_tags, remove_note_tags). The pattern is predictable throughout with no stylistic deviations.
16 tools is at the upper end of the comfortable range but each earns its place across notes, decks, tags, and note types. Slightly heavy, but not excessive for a full collection-management surface.
Strong coverage: notes have create/batch-create/get/update/delete/search, plus deck and tag management, note-type inspection/creation, sync, and connection check. Minor gaps remain (no deck delete/rename, no note-type update/delete, no single-note get by search shortcut), but core workflows are covered.
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.
