Provides access to AnkiWeb's shared deck catalogue and your synced Anki decks. Enables searching and reading shared deck listings (descriptions, tags, sample notes, reviews), downloading shared decks as .apkg files, converting decks to Flashcard Markdown, listing decks synced to your account with due counts, and publishing one of your decks to the shared catalogue after a preview and explicit confirmation.
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-web-mcp search AnkiWeb for Japanese vocabulary 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.
Search, download and share AnkiWeb decks from your assistant, on your own session.
Install • Sign in • Tools • How it works • Docs
anki-web-mcp is an MCP server for AnkiWeb. It gives an assistant such as Claude the shared-deck catalogue and the decks synced to your account.
Search shared decks and read a listing: description, sample notes, reviews.
Download a shared deck's .apkg to disk, and convert it to Markdown the assistant can read.
List the decks synced to your account.
Share one of your decks publicly, only after you have seen a preview and said yes.
Reuse the AnkiWeb session already signed in to Chrome, Brave, Edge and other Chromium browsers.
It is not affiliated with AnkiWeb or Ankitects. AnkiWeb's terms do not allow third-party clients, and say it can suspend access at its discretion; docs/ankiweb.md quotes the clause. AnkiWeb licenses shared decks for personal use only.
Add the server to your MCP client's configuration:
{
"mcpServers": {
"anki-web": {
"command": "npx",
"args": ["anki-web-mcp@latest"]
}
}
}Node.js 24 or newer is required. Then download the Chromium build the server drives:
npx anki-web-mcp@latest --install-browserSearching and downloading shared decks work at this point, with no account.
Related MCP server: NotebookLM MCP Server
Listing your decks and sharing one need an AnkiWeb session. The first call that needs one looks for it in a local Chromium-family browser where you are signed in to AnkiWeb: Chrome, Chromium, Brave, Edge, Vivaldi and Opera on Linux and macOS, plus Arc and Helium on macOS. On macOS that shows one keychain prompt per browser it tries.
If no browser has a session, sign in once in a window the server opens:
npx anki-web-mcp@latest --loginYou type your password into AnkiWeb's own page, so it never passes through the server.
The server keeps the session in ~/.anki-web-mcp/, created 0700, and writes the cookie export 0600.
--logout deletes it.
tool | does |
| searches the shared catalogue, with sorting and paging |
| one listing: description, tags, sample notes, reviews |
| saves a shared deck's |
| turns a local |
| the decks synced to your account, with due counts |
| publishes one of your decks to the shared catalogue |
| version, data directory, and whether the session is valid |
| closes the headless browser until the next call needs it |
share_deck publishes publicly under your account.
Without confirm: true it only returns a preview, and the tool description tells the assistant to show you that preview and wait for your go-ahead.
Calling it with confirm: true also makes AnkiWeb's declaration that you own the material or have a license to share it.
flag | does |
| signs in to AnkiWeb in a visible browser window |
| deletes the stored session, keeping downloads |
| imports the session from a local browser now |
| never looks in local browsers on its own |
| downloads Playwright's Chromium |
| drives an installed browser, such as |
| keeps the session elsewhere; also |
| lists these flags |
Without --login, --logout, --import-from-browser or --install-browser, it serves MCP over stdio. A flag it does not know, or a missing value, prints one line and exits with status 2.
AnkiWeb is a single-page app whose data comes from protobuf endpoints under /svc/.
The server calls those endpoints directly and renders no pages.
flowchart LR
A[MCP client] -- stdio --> S[anki-web-mcp]
S -- "fetch, no cookies" --> P["/svc/shared/*<br>search, listings, downloads"]
S -- "headless Chromium,<br>signed-in cookie jar" --> U["/svc/decks/*<br>your decks, sharing"]
B[Local browser profile] -. "session import" .-> SShared-deck reads go out without cookies, and the server caches each answer for as long as AnkiWeb allows, ten minutes.
After a few anonymous downloads AnkiWeb asks for a login, and the server retries the download with your session.
Calls on your account go through one headless browser, one at a time, which closes after five idle minutes.
The server spaces requests at least a second apart. AnkiWeb answers 429 after about four searches a minute.
docs/ankiweb.md: every AnkiWeb endpoint used, as observed
docs/session.md: the data directory, signing in, browser import
docs/shared-decks.md: search, details, downloads and conversion to Markdown
docs/sharing.md: the share flow and its confirmation
docs/errors.md: what a failing tool returns, and request pacing
CONTRIBUTING.md: setup, gates, and what to update when AnkiWeb changes
NOTICE: the browser import is ported from linkedin-mcp-server
Close the server's headless browser to free its memory, once any call in progress has finished. The AnkiWeb session stays stored, and the next call that needs the browser starts it again. The browser also closes by itself after five idle minutes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| closed | Yes | false when no browser was open. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that the AnkiWeb session persists, that the next browser-needing call restarts it, and that an idle timeout closes it automatically. This is exactly the kind of side-effect and lifecycle context the readOnlyHint/idempotentHint flags cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and purpose, then the state-persistence and auto-close caveats. Every sentence adds a distinct, useful fact 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?
For a no-arg lifecycle tool with annotations and an output schema, the description covers the essentials an agent needs: what it does, what survives, and that it self-restarts and self-closes. Nothing material 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?
The tool takes zero parameters, so there is nothing for the description to clarify and no schema gap to compensate for. Baseline 4 applies; no parameter behavior is misstated.
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 (Close) and resource (the server's headless browser) plus the motivation (free memory), which no sibling tool covers. An agent can immediately distinguish this lifecycle tool from the deck/session tools listed as siblings.
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 a clear timing condition ('once any call in progress has finished') and an implicit reason to call it (free memory). It also warns that the browser auto-closes after five idle minutes, which effectively tells the agent the call is often optional, but it never explicitly states when not to call or names an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a local .apkg, such as one download_shared_deck saved, to a Flashcard Markdown file the assistant can read. It goes in a new folder named after the package, with the images its cards use under .images/; nothing existing is replaced. Only basic front-and-back notes convert: cloze and other note types are counted in diagnostics, and review history is not kept.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | An absolute path to the .apkg. | |
| title | No | The deck's title. Defaults to the filename, with underscores as spaces. | |
| directory | No | An absolute path to an existing directory to create the deck's folder in. Defaults to the .apkg's own directory. |
| Name | Required | Description |
|---|---|---|
| cards | Yes | |
| title | Yes | |
| directory | Yes | |
| mediaFiles | Yes | |
| diagnostics | Yes | |
| markdownPath | Yes | |
| diagnosticCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (non-destructive, non-idempotent, closed-world), and the description adds substantial behavior beyond them: a new folder named after the package, images under .images/, nothing existing replaced, cloze/other note types only counted in diagnostics, and review history dropped. This is exactly the extra context an agent needs.
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 carrying distinct information: what it produces, where it lands, and what is dropped. No filler, and the primary purpose is 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?
For a conversion tool with an output schema, the description covers the essentials an agent cannot get elsewhere: destination layout, non-replacement guarantee, and conversion fidelity limits. Nothing material 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%, so path, title, and directory are already fully documented, including defaults. The description adds no per-parameter syntax or format detail beyond the schema, so the 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?
States a specific verb and resource (convert a local .apkg to a Flashcard Markdown file) and names the sibling that produces the input (download_shared_deck). The output shape and location are specified, so an agent can distinguish it from every sibling tool without opening a 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?
The description anchors usage to a local file, explicitly tying it to download_shared_deck's output, and notes the scope limit that only basic front-and-back notes convert. It gives clear context for when the tool applies but stops short of an explicit when-not/alternative rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the decks synced to the signed-in AnkiWeb account, parents before their subdecks, with due counts and card totals. Needs an AnkiWeb session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| decks | Yes | |
| currentDeckId | Yes | |
| mediaSizeBytes | Yes | |
| collectionSizeBytes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds real behavioral detail beyond them: the auth requirement (AnkiWeb session), the ordering guarantee (parents before subdecks), and the return contents (due counts and card totals).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the resource and scope lead, followed by the ordering/return detail and the auth requirement. Every clause 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?
Given an output schema exists, the description needn't detail return shape, yet it usefully summarizes it; with no parameters and annotations covering safety, the definition is complete for correct 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?
There are zero input parameters, so the baseline is 4; no parameter meaning needs to be added or is missing.
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 (List) and resource (decks synced to the signed-in AnkiWeb account), and scopes it as the user's own decks, which cleanly separates it from the shared-deck siblings (search_shared_decks, get_shared_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?
The 'signed-in AnkiWeb account' scoping implies this is for the user's own synced decks rather than shared decks, and 'Needs an AnkiWeb session' gives a precondition. It stops short of explicitly naming when to prefer a sibling, so it isn't a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the server version, the data directory, and whether an AnkiWeb session is stored. With validate, also ask AnkiWeb whether that session is still signed in.
| Name | Required | Description | Default |
|---|---|---|---|
| validate | No | Check the session against AnkiWeb. Starts a headless browser only when the stored cookie is missing or turned down. |
| Name | Required | Description |
|---|---|---|
| dataDir | Yes | |
| version | Yes | |
| authenticated | No | |
| lastValidated | No | |
| sessionStored | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint; the description adds the meaningful behavioral detail that `validate` performs an external AnkiWeb check on the stored session, which explains the open-world trait. It does not contradict the annotations, though it adds little about failure modes or latency.
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 tightly written sentences with the core output described first and the conditional enhancement second. No filler, no restating of the name, and the `validate` behavior is front-loaded where it matters.
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 not be spelled out, and the readOnly/openWorld annotations carry the safety profile. Combined with a fully documented single parameter, an agent has everything required to call this 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema's terse 'Check the session against AnkiWeb' by clarifying the check answers whether the session is still signed in. The conditional 'also' framing makes the parameter's effect on output concrete.
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 ('Report') and enumerates the exact resources returned: server version, data directory, and stored AnkiWeb session state. This is unmistakably a diagnostics/status tool and trivially distinguishable from the deck-oriented siblings (list_my_decks, download_shared_deck, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives a clear conditional trigger: pass `validate` when you also want AnkiWeb to confirm the session is still signed in. There are no explicit exclusions or named alternatives, but for a status tool none are really needed, so this is clear context without exclusions.
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.0.2close_sessionconvert_deck_to_markdowndownload_shared_deckget_shared_decklist_my_deckssearch_shared_decksserver_statusshare_deckScored across 8 tools
Most tools target a distinct action on a distinct resource: search_shared_decks vs get_shared_deck (finding vs. reading details), download vs. convert, list_my_decks vs. share_deck. The only mild overlap is between server_status (which can validate a session) and close_session, both housekeeping tools, but their purposes remain clear.
All names use snake_case and follow a verb_noun pattern (list_my_decks, search_shared_decks, get_shared_deck, download_shared_deck, convert_deck_to_markdown, share_deck, close_session). The single deviation is server_status, a noun_noun state-report name, but it is still readable and conventional.
Eight tools is well within the ideal 3-15 range and each one covers a distinct step of the AnkiWeb workflow (status, list, search, inspect, download, convert, publish, cleanup). No tool feels redundant or filler.
The surface covers a full read/download/convert/publish lifecycle plus session management. Minor gaps remain: there is no way to unshare or delete a published deck, and no operation to update an existing share, though these may be outside AnkiWeb's API reach.
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…