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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

advanced.cards.update

advanced_cards_update
Destructive

Update validated expert scheduling metadata on a specified Anki card, including interval, ease, repetitions, lapses, remaining steps, FSRS memory, or custom data, and reject inconsistent edits.

Instructions

Edit validated expert scheduling metadata through native card persistence.

No id/noteId/deckId/template/queue/type/due/mod/usn writes. Moves, due changes and transitions use domain commands. Reject inconsistent coupled-state edits instead of inferring omitted state. Capability detection may restrict writable properties.

Anki-Connect method advanced.cards.update. Scope: collection. Effect: advancedWrite. Completion: completed. Undo: single.

Possible errors: collectionUnavailable, editorConflict, internalError, invalidParams, notFound, staleSession, unsupportedCapability, validationFailed.

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": {
      "cardId": "<cardId>",
      "patch": "<patch>"
    },
    "name": "advanced_cards_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
patchYesExpert scheduling fields to set: {intervalDays?, sm2EasePermille?, repetitions?, lapses?, remainingSteps?, fsrsMemory?, customData?}.
cardIdYesCard ID (decimal string, e.g. "1700000000001").
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.

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?

Annotations already declare destructiveHint=true, and the description adds substantial context beyond them: scope (collection), effect (advancedWrite), undo granularity (single), a refusal rule (rejects inconsistent coupled-state edits instead of inferring omitted state), capability-based restriction of writable properties, and a full enumerated error taxonomy including staleSession and editorConflict. This tells an agent both what the call does to state and how it fails.

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?

Front-loaded with purpose, then constraints, then operational metadata and errors in short discrete statements; no sentence is filler. The density is high but every line (undo, scope, error list) carries decision-relevant information for a destructive expert tool.

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, nested-patch mutation with no output schema, the description covers scope, reversibility, failure modes, and refusal semantics, which is close to sufficient. It stops short of describing what a successful response contains or whether the returned card reflects the applied patch, which an agent may need for follow-up reads.

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% and the nested patch object documents each scheduling field, so the baseline is 3. The description earns above baseline by explaining the patch contract itself — coupled fields must be mutually consistent and omitted state is not inferred — which governs how the patch values must be combined rather than merely what they are.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-plus-resource ("Edit validated expert scheduling metadata through native card persistence") and immediately narrows the writable surface by excluding id/noteId/deckId/template/queue/type/due/mod/usn fields. It does not name the sibling tools that should be used instead, referring only generically to "domain commands", so an agent must infer cards_move / scheduling_setDueDate from the roster.

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 clear when-not: moves, due changes and transitions must go through domain commands rather than this tool, and it notes capability detection may restrict which properties are writable. The gap is that alternatives are described by category ("domain commands") rather than by tool name, so the routing is only implied.

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