Skip to main content
Glama
Sign In
anki-connect-mcp

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

media.store

media_store

Store media files in Anki from base64 data, a local file path, or an HTTP(S) URL, with filename normalization and collision handling (rename, replace, or error).

Instructions

Acquire and store media using Anki filename normalization.

Reject traversal and path separators in filename. Validate strict base64 and source types before acquisition. Skip comparison is against incoming bytes and never deletes an existing file. Replacement is explicit and not collection-undoable.

Anki-Connect method media.store. Scope: collection. Effect: media. Completion: operation. Undo: none.

Long-running operation: by default the server waits for the final result (see waitForCompletion / timeoutSeconds).

Possible errors: collectionUnavailable, conflict, internalError, invalidParams, ioError, notFound, staleSession.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filename": "<filename>",
      "source": "<source>"
    },
    "name": "media_store"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceYesBytes to store: {"data": "<base64>"}, {"path": "<file on the machine running Anki>"} or {"url": "<http(s) URL>"}. Max 64 MiB; prefer path for large files.
sessionNoOptional. Collection session ID: the `session` field returned by `collection_get`. Usually omit it — the server then uses the session current at the time of the call. Pass it to make the call fail with `staleSession` instead of acting on a different profile/collection than the one your IDs, cursors and tokens came from.
filenameYesRequested basename, e.g. `cat.jpg`. Anki may normalize or rename it — put the returned filename into note fields (`<img src="...">` or `[sound:...]`).
collisionNoIf the name exists: `rename` (default), `replace` or `error`.rename
skipIfHashNoOptional {algorithm: md5|sha256, digest}: skip storing if the incoming bytes have this hash.
timeoutSecondsNoMCP option (not sent to Anki): how long to wait for completion. A timeout does not cancel the work; the pending record is returned.
waitForCompletionNoMCP option (not sent to Anki): poll operations.get until the operation finishes and return its final record. If false, return the operation handle.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: discloses path-traversal rejection, strict base64/source-type validation, that skip-comparison is against incoming bytes and never deletes, that replacement is explicit and not collection-undoable, the long-running/wait behavior, and a concrete error list. This is exactly the context the annotations don't carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with effect and safety constraints, then structured blocks for method/scope/undo and errors. Some telegraphic phrasing ('Skip comparison is against incoming bytes') and a slightly redundant collision restatement keep it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Handles the complex parts of a 7-param, nested-schema, long-running, no-output-schema tool: errors, undo semantics, wait behavior, and validation. It stops short of describing the returned record (e.g. the normalized filename), which the absent output schema would otherwise require.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns more by explaining that skip comparison is against incoming bytes (clarifying skipIfHash) and that replacement via collision is explicit and undo-exempt, meaning beyond the schema's plain default.

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+resource ('Acquire and store media') plus the distinctive Anki filename-normalization behavior, which separates it from media_get, media_list and media_delete among the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the semantics (store bytes with hashing, collision, long-running wait), but the description never says when to choose this over media_get or media_list, nor when to prefer one source form. No explicit exclusions or alternative routing is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools