anki-web-mcp

Overview Schema Source Related Servers Discussions Admin

Convert a deck to Markdown

convert_deck_to_markdown

Convert local .apkg Anki decks into Flashcard Markdown files the assistant can read, placing card images under .images/ and leaving existing files untouched.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`cards`	Yes
`title`	Yes
`directory`	Yes
`mediaFiles`	Yes
`diagnostics`	Yes
`markdownPath`	Yes
`diagnosticCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.0.2Oct 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server