Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@anki-mcp 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.
An MCP server that exposes your local Anki collection to MCP clients such as Claude Desktop and VS Code, through the AnkiConnect add-on.
Note fields are HTML and are passed through verbatim, so cards can be generated with cloze deletions, bold/italic, and highlight.js-styled code blocks.
Read
anki_check_connection — verify Anki is running and AnkiConnect is reachable
anki_list_decks — every deck (:: denotes nesting)
anki_list_models — every note type
anki_get_model_fields — a note type's field names, in template order
anki_find_notes — note ids matching an Anki search query
anki_get_notes_info — full note details: model, tags, fields, cards
Write
anki_create_deck — create a deck, including missing parents
anki_add_note — add one note (fields are HTML, sent unescaped)
anki_add_notes — add a batch sharing one deck and note type
anki_update_note_fields — overwrite fields of an existing note
anki_sync — sync the collection with AnkiWeb
Related MCP server: mcp-ankiconnect
uv
Anki, running — the server talks to the live application, not the collection file
The AnkiConnect add-on: Anki → Tools → Add-ons → Get Add-ons → code 2055492159, then restart Anki
uv sync
cp .env.example .env.env (all optional — the defaults work for a standard local Anki):
ANKI_CONNECT_URL=http://localhost:8765
ANKI_TIMEOUT=30Run it:
uv run anki-mcpCheck it can reach Anki:
uv run python scripts/smoke_client.pyAdd to claude_desktop_config.json:
{
"mcpServers": {
"anki": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/anki-mcp", "anki-mcp"]
}
}
}No secrets to pass — AnkiConnect is unauthenticated and local.
Set MCP_TRANSPORT=http to serve over streamable-http (endpoint /mcp):
MCP_TRANSPORT=http HOST=0.0.0.0 PORT=8000 uv run anki-mcpThis is of limited use here. AnkiConnect binds to localhost on the machine where Anki runs, so a remotely hosted instance of this server has nothing to connect to — every tool would fail. The transport toggle exists for structural parity with a normal MCP server; making it genuinely useful would need a tunnel back to the desktop (a WebSocket relay or similar), which is out of scope. Run it locally over stdio.
Fields are HTML. Values in fields are sent to Anki byte for byte — no escaping, no sanitizing. "<b>x</b>" renders as a bold x; to show a literal <, send <.
Cloze deletions use {{c1::...}} and require a cloze note type; the syntax is inert on "Basic".
Field names are case- and space-sensitive ("Back Extra"). Check them with anki_get_model_fields before adding notes.
Duplicates: anki_add_note fails on a duplicate first field; anki_add_notes skips the offending note and reports its index. Both accept allow_duplicate=True.
anki_update_note_fields silently does nothing if the note is open in Anki's Browse window — Anki refuses the edit but reports success. Close the browser and retry.
Tool output is Markdown by default; pass response_format="json" for the raw payload (and for untruncated field HTML).
Anki must stay open, and it stops serving requests while a modal dialog is up.
uv sync --extra dev
uv run pytest # tests (HTTP mocked, no network, no real Anki)
uv run ruff check . # lint
uv run ruff check --fix .
uv run fastmcp inspect src/anki_mcp/server.py:mcpAnkiConnect has no authentication: anything that can reach port 8765 can read and modify your collection. That is acceptable because it listens on localhost only — do not expose that port, and do not run this server on an untrusted machine. .env is gitignored, though it holds no secrets by default.
This server can create, overwrite, and sync notes. Back up your collection (Anki → File → Export) before letting an agent make bulk changes.
MIT
Add a single note to a deck.
Field values are HTML and are sent verbatim — do not escape them. Write the markup you want rendered on the card:
fields={
"Text": 'The GIL is released during <b>I/O</b>, so '
'{{c1::threads}} still help for network-bound work.',
"Back Extra": '<pre><code>'
'<span class="hljs-keyword">async def</span> '
'<span class="hljs-title">main</span>(): ...'
'</code></pre>',
}Cloze deletions use {{c1::hidden text}} and require the "Cloze" model
(or another cloze-type note type) — the syntax is inert on "Basic".
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags to attach. Anki tags cannot contain spaces; use `::` to nest, e.g. `"python::asyncio"`. | |
| fields | Yes | Field name -> HTML content. Omitted fields are left empty. | |
| deck_name | Yes | Target deck. It must already exist; create it first with `anki_create_deck`. | |
| model_name | Yes | Note type, e.g. `"Basic"` or `"Cloze"`. Its field names must match `fields` exactly — check with `anki_get_model_fields`. | |
| allow_duplicate | No | By default Anki refuses a note whose first field already exists in the deck. Set True to add it anyway. | |
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate read/write and non-destructive hints, so the description carries the burden of behavioral disclosure. It adds critical context that field values are HTML sent verbatim without escaping, that cloze syntax is inert on 'Basic' notes, and that by default Anki refuses duplicate first fields. This goes well beyond the annotations and discloses non-obvious traits.
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 moderately long but every sentence contributes meaningful guidance. The bold warning about HTML escaping is front-loaded, and the code example effectively illustrates usage, though a shorter example could reduce length. It is well-structured and not redundant.
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 output schema covers return values, the description focuses on the action, prerequisites, and edge cases. It explains the primary functionality, HTML behavior, cloze constraints, and duplicate handling. It does not discuss errors or the response_format parameter, but those are covered by the schema and output schema, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with detailed descriptions, so the baseline is 3. The description adds value by clarifying the verbatim HTML rule and demonstrating proper field formatting with an example, which is not fully captured in the schema's brief 'HTML content' description. It does not repeat the schema's parameter explanations.
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 opens with 'Add a single note to a deck', which is a specific verb and resource. It distinguishes from the sibling 'anki_add_notes' through the word 'single', and provides additional context about HTML verbatim and cloze deletions, making the tool's purpose unmistakable.
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 gives clear prerequisites: the deck must be created first with `anki_create_deck`, field names must match the model checked via `anki_get_model_fields`, and cloze syntax requires a cloze-type model. It does not explicitly mention using `anki_add_notes` for multiple notes, but the singular 'single note' implies the distinction, and the prerequisites serve as strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add several notes at once, sharing one deck and note type.
Field values are HTML and are sent verbatim — do not escape them.
See anki_add_note for the field/cloze conventions; they apply per item.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Default tags, applied to every note that has no own `"tags"`. | |
| notes | Yes | One entry per note, each a dict with: - `"fields"` (required): field name -> HTML content. - `"tags"` (optional): tags for this note, replacing `tags`. | |
| deck_name | Yes | Target deck for every note in the batch. | |
| model_name | Yes | Note type for every note in the batch. | |
| allow_duplicate | No | Allow notes whose first field already exists. | |
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds critical behavioral guidance: field values are HTML and must be sent verbatim without escaping, and all notes share a single deck/type. This provides meaningful context 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?
The description is concise and well-structured: the first sentence states the core purpose, and the second paragraph delivers a crucial HTML warning plus a reference to conventions. Every sentence serves a purpose with no filler.
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 full schema coverage, an output schema, and annotations, the description sufficiently covers batch behavior, shared deck/type constraints, and the HTML verbatim rule. It lacks explicit discussion of partial failure or error handling, but this is not critical for effective selection and invocation.
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% for all 6 parameters, so baseline is 3. The description enhances understanding by warning that field values are HTML and sent verbatim, which is not in the schema, and by pointing to anki_add_note for per-item conventions. This adds practical meaning to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add several notes at once, sharing one deck and note type.' It uses a specific verb and resource, and the emphasis on 'several notes at once' differentiates it from the sibling anki_add_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?
It implies batch usage ('several notes at once') and directs the agent to anki_add_note for field/cloze conventions, which serves as a useful reference. However, it does not explicitly state when to prefer this tool over the single-note sibling or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that Anki is running and AnkiConnect is reachable.
Call this first when any other Anki tool fails — it distinguishes "Anki is closed" from "the request itself was wrong".
Returns the AnkiConnect API version (6) on success.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is known. The description adds the exact return value (API version 6) and the behavioral distinction between two failure modes. This goes beyond annotations with useful 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?
Three short sentences, each with a specific purpose: state the check, give usage guidance, and state the return value. No filler 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 diagnostic tool, this is complete. Annotations cover safety, output schema likely covers return structure, and the description covers when to use and expected success/error distinction. 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?
The single parameter (response_format) is fully documented in the schema, so description need not repeat it. The description adds no param-specific context, but with 100% schema coverage, 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?
The description uses a specific verb ('Check') and resource ('Anki is running and AnkiConnect is reachable'). It clearly distinguishes this diagnostic connection-check tool from sibling Anki tools, which perform actions like syncing, listing, or creating decks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly states when to use: 'Call this first when any other Anki tool fails.' It explains the diagnostic value: distinguishing 'Anki is closed' from 'the request itself was wrong', which is a clear recommendation versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deck, if it does not already exist.
| Name | Required | Description | Default |
|---|---|---|---|
| deck | Yes | Deck name. Use `::` to nest, e.g. `"Python::Asyncio"` — every missing parent in the path is created too. Creating a deck that already exists is a no-op, not an error. | |
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate it is not read-only and not destructive. The description adds the idempotent behavior—'if it does not already exist'—which is a valuable behavioral trait beyond what annotations provide. This explains the no-op case, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. Every word earns its place, with no 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?
The tool is simple, and the schema plus annotations already provide comprehensive details on parameters and safety. The description covers the core function and idempotency, making it complete enough for its complexity. No major gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so both parameters (deck and response_format) are fully documented in the schema. The description adds no additional parameter semantics, 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 a deck, with a crucial qualifier 'if it does not already exist.' This distinguishes it from sibling tools like anki_list_decks (list) and anki_add_note (add note), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deck creation but does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or context about when not to use it. The usage context is clear but not explicitly differentiated from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find note ids matching an Anki search query.
Uses Anki's own search syntax, the same one as the browser's search bar:
deck:Python notes in a deck (and its subdecks)
deck:Python::Asyncio a specific subdeck
tag:python::asyncio by tag ("tag:none" = untagged)
note:Cloze by note type
"front:*GIL*" wildcard match on a named field
added:7 added in the last 7 days
is:due -is:suspended combine terms; "-" negatesQuote any term containing spaces. Returns ids only — pass them to
anki_get_notes_info to see the actual content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search expression. An empty string matches nothing; use `"deck:*"` to match everything. | |
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds value beyond annotations by explicitly stating the output shape ('Returns ids only') and providing search syntax examples, which clarify expected behavior without contradicting 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?
The description is efficiently structured: a one-sentence summary followed by a well-formatted code block of examples. Every line is informative and contributes to understanding the query syntax. There is no redundant or vague wording, making it appropriately sized for the complexity.
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 has an output schema, so return values are already documented. The description covers the tool's purpose, query syntax, and the relationship to `anki_get_notes_info`. It lacks only minor details like error handling or result ordering, but these are not essential given the output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters, so the baseline is 3. The description enriches the `query` parameter by providing numerous examples of Anki search syntax (deck:, tag:, note:, wildcard, etc.), which go beyond the schema's single-line definition. No additional info on `response_format` is needed since the schema already explains 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?
The description opens with 'Find note ids matching an Anki search query', which is a specific verb+resource+query structure. It clearly distinguishes itself from sibling tools by stating 'Returns ids only — pass them to `anki_get_notes_info` to see the actual content', which differentiates it from the note-fetching sibling.
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 clear context on when to use the tool ('Uses Anki's own search syntax, the same one as the browser's search bar') and gives a direct pointer to a sibling tool for the next step ('pass them to `anki_get_notes_info`'). It does not explicitly list when not to use the tool, but the search syntax and workflow make it evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a note type's field names, in template order.
These are the exact keys anki_add_note expects in its fields dict —
they are case-sensitive and space-sensitive ("Back Extra", not
"back_extra").
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | Yes | Note type name, e.g. `"Cloze"`. | |
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, so safety is covered. The description adds valuable behavioral context beyond annotations: field names are case-sensitive and space-sensitive (with a concrete example), and ordering follows template order. This helps the agent use the output correctly.
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: the first states the primary purpose and scope, the second adds crucial formatting details. No unnecessary words or repetition.
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 simple, has a full output schema, and annotations covering its read-only, open-world nature. The description covers the core purpose and the most important behavioral nuance (key format) for downstream use. Nothing essential 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% with both parameters described in detail, including an enum for response_format. The description does not add parameter-specific meaning beyond the schema; the 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 uses the specific verb 'List' with the resource 'a note type's field names' and adds the scope qualifier 'in template order'. This clearly distinguishes it from siblings like anki_list_models (which lists note types themselves).
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 says these are the exact keys anki_add_note expects, giving a concrete use case and context. It does not explicitly name alternatives or exclusion criteria, but the purpose is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details for the given note ids.
Returns each note's model, tags, field contents (as stored — i.e. HTML), and the ids of the cards generated from it. Unknown ids come back as empty entries rather than an error.
Markdown output truncates field values for readability; use
response_format="json" to get the untouched HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | Yes | Note ids, typically from `anki_find_notes`. | |
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true and openWorldHint=true, the description adds meaningful behavior: unknown IDs return empty entries rather than errors, field values are raw HTML, and markdown output truncates values unless response_format='json'. These are concrete details not present in 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 sentences, each with a distinct job: the first states the purpose, the second covers return values and the unknown-ID edge case, and the third explains output truncation. No filler or redundant phrasing.
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 output schema exists and annotations are present, the description fully covers the tool's behavior: it states inputs, outputs, edge cases, and formatting options. There are no significant gaps for an agent to be misled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides — it only references response_format in a context that the schema already covers. No extra meaning is added.
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 opens with 'Fetch full details for the given note ids' — a specific verb and resource — then enumerates exactly what details are returned (model, tags, field contents as HTML, card IDs). This sets it apart from sibling tools like anki_find_notes (which finds IDs) and anki_get_model_fields (which gets a model's 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 makes it clear this is used when you already have note IDs and want their full details, especially given the schema note that IDs 'typically come from anki_find_notes.' However, it does not explicitly name alternative tools or state when NOT to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every deck in the collection.
Nested decks are returned with :: as the separator, e.g.
"Python::Asyncio" is the "Asyncio" subdeck of "Python".
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate that the operation is safe. It adds meaningful behavioral context by explaining how nested decks are returned (using `::` separator) and providing an example, which is valuable 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?
The description is two sentences: a clear statement of purpose followed by a concrete example of nested deck formatting. It is front-loaded with the main verb and resource, and every word contributes to understanding. No redundancy or fluff.
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 simplicity of the tool (1 optional parameter, existing output schema, read-only annotations), the description adequately covers the core behavior and the important detail of nested deck separation. It does not explain return values, but the output schema handles that. The description is complete enough for an agent to use the tool 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% for the single parameter 'response_format', which includes an enum and explanation. The tool description does not add any extra meaning for this parameter, so the baseline of 3 is appropriate—the schema already carries the full semantic load.
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 every deck in the collection' with a specific verb and resource, clearly distinguishing it from sibling tools like anki_create_deck or anki_list_models. The additional detail about nested decks using `::` reinforces the exact scope of the 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?
The description clearly indicates when to use this tool: whenever you need to list all decks. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous and the note about nested deck naming helps the user understand the output format. This aligns with 'clear context, no exclusions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every note type (model) in the collection.
Typical built-ins: "Basic", "Basic (and reversed card)", "Cloze".
Use anki_get_model_fields next to learn a model's field names before
adding a note with it.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by clarifying the scope ('every note type') and providing concrete built-in examples, which helps set expectations about the return values. 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 exactly three sentences, with the core purpose front-loaded in the first sentence. Every sentence earns its place: the second gives examples, the third provides a next-step pointer. 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?
For a simple read-only listing tool with an output schema and clear annotations, the description is complete. It not only states what the tool does but also situates it in a workflow by recommending anki_get_model_fields next, giving the agent enough context to chain tools 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% for the single parameter (response_format), and the schema fully documents its enum values and default. The description adds no parameter-specific details, so the baseline of 3 applies; the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every note type (model) in the collection' with a specific verb and resource scope, and provides examples of typical built-ins. It distinguishes itself from sibling tools like anki_list_decks by explicitly focusing on models/note types rather than decks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: before adding a note, recommending to follow up with anki_get_model_fields to learn field names. It implies the use case (listing available models) without explicit alternatives or exclusions, but the workflow context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync the local collection with AnkiWeb.
Requires AnkiWeb credentials already configured in Anki — this cannot log in for you. The action returns nothing on success; a sync conflict opens a modal dialog in Anki, which blocks AnkiConnect until you resolve it (the call will then time out).
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several important behavioral traits beyond annotations: it cannot log in for the user, returns nothing on success, and on sync conflict it opens a modal dialog in Anki that blocks until resolved, causing the call to time out. This adds substantial context about side effects and failure modes.
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 three sentences, each providing necessary information: purpose, prerequisite, and critical delay/edge-case behavior. There is no filler or redundancy, and the structure is logical and easy to parse.
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 external side effects and potential blocking behavior, the description covers the essential context: prerequisites, success return (nothing), conflict behavior, and timeout implication. Since an output schema exists, return value details need not be explained further.
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 only parameter is response_format, a generic rendering option with full schema coverage. The description adds no parameter-specific information, but that is appropriate since the parameter is not tool-specific and is fully described in the schema. The description's lack of parameter detail is not a gap.
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 function with a specific verb 'Sync' and resource 'local collection with AnkiWeb'. It distinguishes the tool from siblings like anki_create_deck or anki_add_note, which handle different 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?
The description implies when to use the tool: to sync the local collection with AnkiWeb. It also provides a critical prerequisite (credentials must already be configured) and highlights a key behavioral consequence (conflict blocking). It does not explicitly name alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overwrite fields of an existing note.
Field values are HTML and are sent verbatim — do not escape them.
Each named field is replaced wholesale, not merged; fields left out of
fields keep their current content. Fetch the current values with
anki_get_notes_info (response_format="json") before a partial edit.
⚠️ This silently does nothing if the note is open in Anki's Browse window. Anki refuses the edit to avoid clobbering what you are typing, but AnkiConnect still reports success — no error is raised, and the fields are simply unchanged. If an update seems to have no effect, close the Browse window (or click away from that note) and run it again.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Field name -> new HTML content. Names must match the note's model exactly. | |
| note_id | Yes | Id of the note to modify, from `anki_find_notes`. | |
| response_format | No | How a tool should render its result. A `StrEnum` so the members compare equal to the plain strings a client sends over the wire (`"markdown"`, `"json"`). | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as mutating/destructive, but the description adds valuable context: fields are sent verbatim as HTML, replacement is wholesale not merged, and the silent failure when the note is open in Anki's Browse window. The warning about Anki falsely reporting success is especially important and beyond annotation data.
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?
Well-structured with bold warnings and short, information-dense paragraphs. Every sentence earns its place: purpose, HTML semantics, partial-edit guidance, and the silent-failure warning. No redundancy or fluff.
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?
Combined with the output schema (present) and annotations, the description fully covers the tool's usage: destructive nature, field replacement semantics, prerequisite fetch step, and a critical failure mode. Sibling tools are referenced where relevant, making this complete for an 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 already documents all three parameters; the description adds meaningful semantics for `fields` (verbatim HTML, wholesale replacement, omitted fields preserved), which is not evident from the schema alone. It does not further elaborate on `note_id` or `response_format`, but the existing schema coverage is sufficient.
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?
Opens with 'Overwrite fields of an existing note' – a specific verb and resource, clearly distinguishing it from sibling tools like add_note, find_notes, and get_notes_info. The scope is precise: updating, not creating or reading.
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?
Provides explicit guidance to fetch current values with anki_get_notes_info before partial edits, and outlines a recovery path for silent failures. However, it does not explicitly say when to avoid this tool (e.g., use add_note for new notes) or name a non-update alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0anki_add_noteanki_add_notesanki_check_connectionanki_create_deckanki_find_notesanki_get_model_fieldsanki_get_notes_infoanki_list_decksanki_list_modelsanki_syncanki_update_note_fieldsEach tool targets a distinct resource and action, from connection checking to note updates. The only near-overlap is add_note vs add_notes, but their batch semantics are clear from names and descriptions. All other tools are unambiguously separated.
All tools share the 'anki_' prefix and use snake_case with a verb_noun structure (e.g., list_decks, add_note, get_notes_info). The sole deviation is anki_sync, which is a single verb but still follows the same prefix and case convention.
11 tools is a well-scoped set for an Anki MCP server, covering connection health, sync, deck and model introspection, note creation (single and batch), search, retrieval, and field updates. Each tool earns its place without redundancy.
The set covers the core note lifecycle well: create, read, search, and update fields. Minor gaps exist—no delete for notes or decks, and no model creation—but these can be worked around via Anki's GUI, making the surface largely complete for typical flashcard workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Connect AI to your flomo notes. Search, create, edit notes and manage tags via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chadlis/anki-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
