Skip to main content
Glama
anki-connect-mcp
by SolarianGG

cards.setFlags

cards_setFlags

Set or clear the user flag on specified Anki cards by card ID; passing 0 clears the flag while preserving other backend flag bits.

Instructions

Set the user flag through Anki native flag persistence.

Zero clears the user flag; preserve other backend flag bits.

Anki-Connect method cards.setFlags. Scope: collection. Effect: write. Completion: completed. Undo: perItem.

Possible errors: collectionUnavailable, editorConflict, internalError, invalidParams, 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": {
      "ids": "<ids>",
      "flag": "<flag>"
    },
    "name": "cards_setFlags"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsYesCard IDs (decimal string, e.g. "1700000000001").
flagYesFlag: 0 none, 1 red, 2 orange, 3 green, 4 blue, 5 pink, 6 turquoise, 7 purple.
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

A3.7/5.0
Behavior4/5

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

The annotations only declare readOnly=false, destructive=false and closed-world, so the description carries real extra weight: scope, write effect, per-item undo granularity, a bit-preservation guarantee ('preserve other backend flag bits'), and an enumerated error taxonomy including editorConflict and staleSession. It does not describe what the call returns or how failures are surfaced per item, which keeps it out of the 5 band.

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?

The most important facts (what it does, what zero means, bit preservation) are front-loaded, and the scope/effect/undo/error block reads as a compact structured footer rather than prose bloat. The error enumeration is slightly list-heavy for the space it occupies but each entry is actionable.

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 three-parameter write tool with full schema coverage and no output schema, the definition covers scope, mutation semantics, undo granularity and failure modes, which is most of what an agent needs. The one remaining gap is that it never says what a successful call returns, so the agent cannot predict the response shape.

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 coverage is 100% and the schema already spells out the flag enum (0–7) and the ID format, so the baseline of 3 applies. The description does add one genuinely new semantic detail — that flag 0 clears and that other backend bits are preserved — but says nothing additional about the ids array beyond the schema's format rules.

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 opening sentence gives a specific verb and resource ('Set the user flag') and adds the mechanism ('Anki native flag persistence'), which clearly separates it from neighbouring write tools like cards_setSuspended or cards_move. It does not, however, explicitly name a sibling or contrast itself with one, so it stops short of the top band.

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 only implied: the note that 'Zero clears the user flag' tells the agent how to remove a flag rather than which tool to prefer, and there is no statement of when to call this versus cards_setSuspended, advanced_cards_update, or any other card mutator. An agent can infer the purpose but receives no explicit when/when-not guidance.

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