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

anki-connect-mcp

by SolarianGG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scheduling.reset

scheduling_reset
Destructive

Reset specified Anki cards to new using the native scheduler; optionally restore original new-card positions and clear repetition and lapse counts.

Instructions

Reset cards as new using the native scheduler.

Anki-Connect method scheduling.reset. 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": {
      "cardIds": "<cardIds>"
    },
    "name": "scheduling_reset"
  }
}

Input Schema

NameRequiredDescriptionDefault
logNoAdd a manual entry to review history. Default true.
cardIdsYesCards to reset to new (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.
resetCountsNoAlso reset repetition and lapse counts. Default false.
restorePositionNoRestore the original new-card position where known. Default true.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety floor is covered; the description goes further by disclosing undo granularity ('perItem'), completion semantics, and the enumerated error surface including editorConflict and staleSession. That error list is genuinely useful context an agent cannot get from the annotations alone.

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 definition is compact and front-loaded: the operative sentence comes first, followed by scannable metadata lines. The telegraphic 'Scope/Effect/Completion/Undo' fragments are efficient but slightly jargon-like rather than fully readable prose.

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 five-parameter destructive mutation with no output schema and full schema coverage, the description supplies the missing behavioral layer: scope, undo model, and error modes. Only the absence of alternative-tool routing keeps it from being fully complete.

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%, with each of the five parameters (log, cardIds, session, resetCounts, restorePosition) documented inline including defaults. The description adds nothing about parameter behavior or interactions, so the baseline 3 applies.

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 first sentence names a specific verb and resource ('Reset cards as new using the native scheduler') and the Anki-Connect method name pins the exact operation. It is clearly distinct from scheduling_setDueDate, scheduling_answer, or cards_setSuspended, though it never explicitly contrasts itself with them.

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?

Scope ('collection'), effect ('write'), and undo granularity ('perItem') imply the context of use, but there is no statement of when to prefer this over scheduler alternatives such as scheduling_setDueDate or cards_setSuspended, and no stated prerequisites (e.g., card must exist, scheduler state).

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