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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

collection.sync

collection_sync
Destructive

Run one coordinated Anki GUI/background sync, optionally including media, while preventing a second concurrent sync and surfacing full-sync choices that require user action.

Instructions

Run one coordinated GUI/background sync.

Full sync choices are waitingForUser; never launch a second sync. includeMedia is intersected with profile media-sync settings.

Anki-Connect method collection.sync. Scope: collection. Effect: lifecycle. Completion: operation. Undo: none.

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

Possible errors: authenticationRequired, busy, cancelled, collectionUnavailable, editorConflict, internalError, invalidParams, ioError, staleSession.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "collection_sync"
  }
}

Input Schema

NameRequiredDescriptionDefault
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.
includeMediaNoAlso sync media (further limited by the profile's media-sync setting). Default true.
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
Behavior4/5

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

Beyond the annotations (readOnly=false, destructiveHint=true), the description discloses that no undo exists, that a full sync can require user interaction, that the call is long-running with server-side wait/timeout semantics where a timeout does not cancel the work, and it enumerates failure modes including busy/editorConflict/staleSession. This is meaningful added context; the templated 'Scope/Effect/Completion/Undo' line is boilerplate but the surrounding sentences earn the score.

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?

Constraints and the concurrency warning are front-loaded before the method metadata and error list, and each sentence carries operational information. The one-line 'Scope/Effect/Completion/Undo' metadata block is formulaic and could be trimmed, which keeps this off 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?

For a destructive, long-running, no-output-schema operation, the description covers the essentials: waiting behavior, non-cancelling timeouts, absence of undo, and the error surface. It does not explain what a completed full sync does to existing data or how to retrieve a pending result afterwards (operations_get is only implied), leaving a small gap.

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, but the description adds real meaning: includeMedia is 'intersected with profile media-sync settings' (a constraint not in the schema) and the waitForCompletion/timeoutSeconds pairing is explained in terms of the operation lifecycle rather than just parameter definitions.

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?

The opening line 'Run one coordinated GUI/background sync' states a specific verb (sync) and resource (the collection), and the 'Anki-Connect method `collection.sync` / Scope: collection' line pins it down further. No sibling in the list performs collection sync, so the agent can identify it unambiguously.

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?

It gives a concrete usage constraint — 'never launch a second sync' and 'Full sync choices are waitingForUser' — which tells the agent both how to behave and that the call may block on a human decision. It stops short of naming an alternative tool or explicitly stating when-not-to-use (e.g. vs. collection_refresh), so it is not a full 5.

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