This MCP server enables LLMs to control a local Anki instance via AnkiConnect, providing comprehensive deck and note management with safety-first design.
Health & Connectivity
ping: Check if the MCP server is running
check_anki_connection: Verify AnkiConnect/Anki is reachable
Deck Management
list_decks: Retrieve all available decks
create_deck: Create new decks, including hierarchical ones using :: syntax (e.g., Parent::Child)
Note Model Inspection
list_note_models: List all available note/card types
get_note_model_fields: Get field names for a specific note model
Note Operations
add_note: Add a single flashcard with fields and optional tags
add_notes: Batch-add multiple flashcards (supports dryRun preview)
search_notes: Search notes using Anki's native query syntax
get_notes_info: Retrieve detailed info about specific notes by ID
update_note_fields: Modify fields of an existing note
delete_notes: Delete notes by ID or search query (requires confirm="DELETE_NOTES")
Tag Management
add_tags / remove_tags: Add or remove tags from notes individually or by search query (both default to dry-run)
Sync
sync_anki: Trigger AnkiCloud synchronization (requires confirm="SYNC_ANKI")
Safety Features
All mutation operations default to dryRun=true, allowing changes to be previewed before being applied
Destructive operations require explicit confirmation strings
Duplicate prevention enabled by default
Localhost-only communication — no external data exposure or direct database access
Allows managing Anki decks and notes via AnkiConnect, including adding, updating, searching notes, and deck management.
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., "@@lifeng688/anki-mcp list all my decks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP stdio server for controlling local Anki via AnkiConnect. Enables LLMs (Claude, Cursor, Cline) to manage Anki decks and notes through a standardized tool interface.
v0.2.0 — Controlled write operations with safe defaults (dryRun), tag management, and explicit sync confirmation.
npm install @lifeng688/anki-mcpOr try it instantly:
npx @lifeng688/anki-mcpRelated MCP server: TalkToAnki
Anki desktop installed
AnkiConnect add-on (code 2055492159) — install via Tools → Add-ons → Get Add-ons
Node.js >= 18.0.0
Verify AnkiConnect is running:
curl -X POST http://127.0.0.1:8765 \
-H "Content-Type: application/json" \
-d '{"action":"version","version":6}'
# Expected: {"result":6,"error":null}Deck management — List and create decks (including hierarchical :: decks)
Note operations — Add, search, update, delete, and inspect notes
Tag management — Add and remove tags on notes by ID or search query
Batch operations — Add multiple notes with per-item result tracking
Safe note deletion — Delete notes with dryRun preview and explicit confirmation
Explicit sync — Trigger AnkiCloud sync with confirmation guard
Controlled writes — All mutation tools default to dryRun=true
Safety first — dryRun support for batch writes, duplicate prevention, field validation
Unified responses — Consistent success/error envelope across all tools
Security-focused — Localhost only, no DB access, no card content logging
Tool | Description | Side Effects |
| Server health check | None |
| Verify AnkiConnect reachable | None |
| List all decks | None |
| Create a new deck | Creates deck |
| List note models | None |
| Get model fields | None |
| Add single note | Creates note |
| Batch add notes | Creates notes |
| Search notes | None |
| Get note details | None |
| Update note fields | Modifies note |
| Delete notes by ID or query | Deletes notes (requires confirm) |
| Add tags to notes | Modifies note tags |
| Remove tags from notes | Modifies note tags |
| Trigger AnkiCloud sync | Triggers network sync (requires confirm) |
See Tool Schema Reference for full input/output specs.
Add to claude_desktop_config.json:
{
"mcpServers": {
"anki": {
"command": "node",
"args": ["$(npm root)/@lifeng688/anki-mcp/dist/index.js"]
}
}
}With environment variables:
{
"mcpServers": {
"anki": {
"command": "node",
"args": ["$(npm root)/@lifeng688/anki-mcp/dist/index.js"],
"env": {
"ANKI_CONNECT_URL": "http://127.0.0.1:8765",
"ANKI_CONNECT_VERSION": "6",
"ANKI_DEFAULT_DECK": "Default::MCP",
"ANKI_DEFAULT_MODEL": "Basic",
"ANKI_LOG_LEVEL": "warn"
}
}
}
}Note: Replace
$(npm root)/@lifeng688/anki-mcp/dist/index.jswith the actual resolved path. You can find it with:npm root -g # or npm root
Same JSON format — add to your MCP server configuration. Point args to the installed dist/index.js inside the @lifeng688/anki-mcp package directory.
npm install -g @lifeng688/anki-mcpThen configure your client to point to:
<global-npm-root>/@lifeng688/anki-mcp/dist/index.jsVariable | Default | Description |
| (none) | Full AnkiConnect HTTP endpoint (highest priority). Overrides HOST:PORT. |
|
| Host part, used when |
|
| Port part, used when |
|
| AnkiConnect API version |
| (empty) | AnkiConnect API key (if configured) |
|
| Default deck for note operations |
|
| Default note model |
|
| HTTP request timeout in milliseconds |
|
| Log verbosity: |
URL Resolution Priority:
ANKI_CONNECT_URL — if set, used as-is (must point to localhost)
ANKI_CONNECT_HOST + ANKI_CONNECT_PORT — composed as http://{HOST}:{PORT}
http://127.0.0.1:8765 — hardcoded default
This server only connects to http://127.0.0.1:8765 (localhost)
It does not read/write Anki SQLite databases directly
It does not upload any data externally
ANKI_CONNECT_KEY is never logged
delete_notes defaults to dryRun=true; real deletion requires confirm="DELETE_NOTES"
sync_anki defaults to dryRun=true; real sync requires confirm="SYNC_ANKI"
add_tags / remove_tags default to dryRun=true
import/export are not in v0.2.0
Create a Test::MCP deck before making real changes
Run ping and check_anki_connection to verify connectivity
Use add_notes with dryRun: true to preview before writing
Before deleting notes, always run delete_notes with dryRun: true first
Before batch tag operations, run add_tags / remove_tags with dryRun: true first
sync_anki requires explicit confirm="SYNC_ANKI" for real sync
Never expose port 8765 to the network
Installation & Configuration — Full setup guide
Tool Schema Reference — All tools: input/output/examples/errors
Roadmap — Feature progression plan (v0.1 → v0.6)
Security Guide — Boundaries, risks, safety policies
Conversation Quality Guide — How LLMs should create cards
Testing Guide — How to run the test suite
MIT — See LICENSE for details.
Add a single note (flashcard) to Anki.
| Name | Required | Description | Default |
|---|---|---|---|
| deckName | Yes | Target deck name. | |
| modelName | Yes | Note model name. | |
| fields | Yes | Field values as key-value pairs. | |
| tags | No | Tags to assign to the note. | |
| allowDuplicate | No | Whether to allow duplicates. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'add' (mutation) but lacks details on permissions, side effects, or what happens on duplicate—even though an 'allowDuplicate' parameter exists. The description does not compensate for the missing annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. Every word earns its place by stating the action, object, and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter schema is complete, but there is no output schema and the description lacks behavioral context (e.g., duplicate handling, error scenarios). For a mutation tool, this is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% parameter description coverage, so the baseline is 3. The description adds no extra meaning beyond the tool's purpose; all parameter semantics are already covered in 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?
The description clearly states the verb 'Add', the resource 'single note (flashcard)', and the destination 'Anki'. It distinctly separates from sibling add_notes (plural) and update_note_fields.
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 use for a single note, but provides no explicit guidance on when to use this tool versus alternatives like add_notes or when duplicates are allowed. No context about prerequisites or excluded use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch add multiple notes to Anki. Supports dryRun for preview.
| Name | Required | Description | Default |
|---|---|---|---|
| deckName | Yes | Target deck name. | |
| modelName | Yes | Note model name. | |
| notes | Yes | Array of note objects with fields and optional tags. | |
| allowDuplicate | No | Whether to allow duplicates. Default false. | |
| dryRun | No | If true, only validate and preview without writing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions dryRun for preview, but fails to disclose behavioral traits like side effects (creation), error handling, or performance implications for batch operations.
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 core purpose. However, it could be slightly longer to include essential usage guidance without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch operation with 5 parameters and no output schema, the description is insufficient. It omits details on return values, error behavior, and performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it merely restates 'dryRun' which is already described in 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?
The description clearly states the tool's purpose: batch adding multiple notes to Anki. The verb 'add' and resource 'notes' are specific, and it distinguishes from the sibling 'add_note' by indicating batch operation.
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 guidelines are provided. The description does not specify when to use this tool versus alternatives (like 'add_note' for single notes) or any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if AnkiConnect is reachable and return the connection status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It states it checks reachability and returns status, which is adequate for a simple read operation. However, it does not specify the format of the status (e.g., boolean or JSON) or potential errors, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the core action and is extremely 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 tool with no parameters and no output schema, the description is mostly adequate but falls short on explaining the return value in detail. 'Connection status' is vague; the agent might need to know if it returns a boolean, string, or structured object.
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?
There are no parameters, so schema coverage is 100%. According to the guidelines, the baseline for zero parameters is 4. The description does not add parameter-specific meaning, which is acceptable.
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 specific resource 'AnkiConnect', and mentions the return value 'connection status'. It is precise and distinguishes from sibling tools like 'ping' by naming the service.
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 vs alternatives (e.g., 'ping' or other connectivity checks). It lacks any context about prerequisites or ideal scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Anki deck. Supports hierarchical decks using :: separator.
| Name | Required | Description | Default |
|---|---|---|---|
| deckName | Yes | Name of the deck to create. Supports hierarchy with ::. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions creation and hierarchy but does not disclose behavior if deck already exists, error handling, or mutation details. Insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded 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?
Simple tool with one parameter and no output schema; description covers basic purpose and hierarchy but omits return value or error conditions. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description already explaining hierarchy. Tool description adds 'new' and 'Anki' but not substantial extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and resource 'Anki deck', and distinguishes from sibling tools like list_decks or add_note. It also mentions hierarchical support via '::'.
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 other tools. No mention of prerequisites or context. The description is self-evident for a creation tool but lacks explicit alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the field names for a specific note model.
| Name | Required | Description | Default |
|---|---|---|---|
| modelName | Yes | Name of the note model (e.g. "Basic"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It implies a read-only operation but does not specify what happens if the model does not exist, error handling, or output format.
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 efficient sentence with no unnecessary words. However, it could include more useful detail without becoming verbose.
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 tool with one parameter and no output schema, the description is adequate but lacks details on return values or error cases. It is minimally 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 a clear description for the parameter 'modelName'. The tool description adds no extra meaning beyond the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'field names for a specific note model'. It is specific and distinguishes from sibling tools like 'add_note' or 'get_notes_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?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about specific notes by their IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| noteIds | Yes | Array of positive integer note IDs to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions 'detailed information' but does not specify what fields or structure are returned, nor does it discuss authorization, rate limits, or side effects (likely a read operation). This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that conveys the core function without any redundant or extraneous information. Highly efficient.
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 tool with one required parameter and no output schema, the description is nearly complete. However, it lacks any hint about the return format (e.g., fields, objects), which would enhance completeness. Still, it adequately covers the tool's purpose and input.
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%; the schema's description already explains the 'noteIds' parameter clearly. The tool description adds no semantic depth beyond the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'notes', and the method 'by their IDs'. It effectively distinguishes from sibling tools like 'search_notes' (which searches across notes) and 'add_note' (which creates notes). No 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?
No guidance is provided on when to use this tool versus alternatives. The sibling 'search_notes' exists for broader queries, but the description does not mention this distinction or any prerequisites. A score of 2 reflects minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Anki decks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly identifies a read-only operation, but does not disclose potential issues like performance with many decks, authentication requirements, or error handling. The description is minimal but not misleading.
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: a single sentence of 5 words. No unnecessary information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no nested objects), the description fully covers what the agent needs to know. It states the scope ('all available decks') adequately.
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%. The description does not need to add parameter details. Per guidelines, 0 parameters yields 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 clearly states that the tool lists all available Anki decks, using a specific verb ('list') and resource ('decks'). It is unambiguous and immediately understandable.
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. There is no mention of when to use this tool versus alternatives like search_notes or create_deck. The agent is given no context about typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available note models (card types).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Adequately states it lists models, but doesn't mention any potential details like return format or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, 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?
While simple, the description lacks details about the output format (e.g., names, IDs). No output schema provided, so more context would help.
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 no additional parameter info needed. Schema coverage is trivially 100%.
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 it lists all available note models (card types), using a specific verb and resource. Distinguishes from siblings like add_note, get_note_model_fields, and search_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Lacks context such as 'use to find model IDs before adding notes' or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check for the MCP server. Returns server metadata without requiring Anki to be running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately discloses that the tool is non-destructive (health check) and returns metadata, implying safe read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, conveying all necessary information efficiently.
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 (no parameters, no output schema), the description is fully complete, covering purpose, scope, and prerequisites (no Anki needed).
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 the description's mention of returning 'server metadata' adds sufficient context beyond the empty schema, meeting the baseline for 0-param tools.
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 the tool performs a 'Health check' on the 'MCP server', clearly distinguishing it from siblings like 'check_anki_connection' by noting it does not require Anki to be running.
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 indicates use for verifying server health independently of Anki, but does not explicitly state when not to use or provide alternatives, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for notes in Anki using Anki search syntax.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Anki search query. | |
| limit | No | Maximum number of results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not state that the tool is read-only, what it returns, or any side effects. The only behavioral clue is 'search' implying no mutation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. Every word adds value, specifying the action, resource, and query syntax.
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?
The tool is a search function with custom syntax. The description mentions 'Anki search syntax' but doesn't explain that syntax or what fields are searchable. Given no output schema, the description could do more to inform about result format.
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 schema already documents both parameters. The description adds no additional meaning beyond what the schema provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and resource 'notes', and specifies the use of 'Anki search syntax', which gives a good sense of the tool's functionality. However, it does not explicitly distinguish it from sibling tools like 'get_notes_info', but the mention of search syntax implies a query-based retrieval.
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?
There is no guidance on when to use this tool versus alternatives such as 'get_notes_info' for fetching by ID or 'add_note' for creation. No when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update specific fields of an existing note. Supports dryRun.
| Name | Required | Description | Default |
|---|---|---|---|
| noteId | Yes | The note ID to update. | |
| fields | Yes | Field name-value pairs to update. | |
| dryRun | No | If true, only preview without writing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions support for dryRun, which is a key behavioral trait (preview without writing). However, it does not disclose other behaviors like error handling, idempotency, or constraints on fields beyond what the schema provides. Since no annotations exist, the description carries the full burden and is only partially 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?
The description is extremely concise with two sentences, front-loading the core action and a key feature (dryRun). 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 tool with 3 parameters and no output schema, the description is minimal. It lacks context such as return value, failure behavior, or prerequisites. While the schema covers parameter definitions, the description does not round out understanding for an AI agent.
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 all parameters documented. The description adds minimal extra meaning beyond 'Supports dryRun', which is already in the schema. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'specific fields of an existing note'. It distinguishes from sibling tools like add_note (create) and get_notes_info (read), though it doesn't explicitly differentiate from potential other update tools (none listed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description only mentions dryRun but does not explain when to use it or exclude other scenarios.
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.1.0add_noteadd_notescheck_anki_connectioncreate_deckget_note_model_fieldsget_notes_infolist_deckslist_note_modelspingsearch_notesupdate_note_fieldsScored across 11 tools
Each tool has a clearly distinct purpose: single vs batch note addition, deck vs model listing, search vs info retrieval, etc. No overlapping responsibilities.
All tools follow a consistent snake_case verb_noun pattern (e.g., add_note, list_decks, search_notes). No deviations or mixed conventions.
11 tools provide a well-scoped set for Anki interaction—covering deck creation, note operations, search, and health checks—without being excessive or insufficient.
The set covers core note and deck operations, but lacks delete functionality (delete_note, delete_deck) and update deck operations, leaving some lifecycle gaps.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Remote MCP server to read and manage your Atako AI agents, messages, files, and integrations.
